• Resolved Gone Fishin

    (@terryg-1)


    Regarding this topic title, the installation page lists three filters and gives a link to some PHP examples. However, it does not fully explain how the filter (text) and the PHP code is to be used.

    1) Where does the PHP code go?

    2) Where is the filter text used?

Viewing 6 replies - 1 through 6 (of 6 total)
  • Ryan

    (@daobydesign)

    Hi. First, I should note that these are advanced customizations and so some familiarity with theme files/WordPress’ nuts and bolts is recommended.

    The PHP code goes in your theme’s (or child theme’s) functions.php file.

    I’m not sure what you mean in your #2 question. What filter text do you mean?

    Thread Starter Gone Fishin

    (@terryg-1)

    Thank you for such a fast response, Ryan.

    By “filter text”, I mean the text of the filters themselves:
    wpcf7_honeypot_accessibility_message ,
    wpcf7_honeypot_container_css , and
    wpcf7_honeypot_html_output .

    Where are they used? Are they manually placed into the honeypot tag?

    Ryan

    (@daobydesign)

    WordPress filters are used to modify intended output. So in the case of the Honeypot plugin, they allow you to change the accessibility message, the container CSS or the whole shebang. Those initial (default) values are supplied to the filter function via a variable, and that variable can then be modified and returned (see the PHP examples). It’s all handled in the PHP functions, nothing is placed in the honeypot tag.

    Thread Starter Gone Fishin

    (@terryg-1)

    It’s all handled in the PHP functions, nothing is placed in the honeypot tag.

    Okay. So, the filter is triggered simply by including the PHP code of the relevant override function in the theme’s functions.php file. That’s the part I wasn’t getting.

    One, then, needs to include only the code that performs the desired override. And, utilizing the wpcf7_honeypot_accessibility_message function and/or the wpcf7_honeypot_container_css function in conjunction with the wpcf7_honeypot_html_output function would be redundant.

    Thank you for the clarification.

    Ryan

    (@daobydesign)

    Yep, you nailed it.

    Thread Starter Gone Fishin

    (@terryg-1)

    Just FYI for anyone wishing to utilize the my_honeypot_html_override function to modify the entire outputted HTML for the honeypot field, you can get a listing of the array elements supplied to the $args parameter by inserting the following line just prior to the “return $html;” line in the function (only for testing of course):

    echo "<script>console.log( '" . json_encode($args) . "' );</script>";

    If you wish to modify the HTML and also opt to “Move inline CSS”, do not modify the span element’s id attribute as that will cause the field to be displayed and visible.

    @ryan:
    The honeypot might be made more effective by eliminating the “/hp[a-zA-Z0-9]{13}/” signature of the span element’s id attribute. Please allow me to suggest:

    $atts[‘span-id-prefix’] = $tag->get_option( ‘span-id-prefix’, ‘id’, true );
    $unique_id = uniqid($atts[‘span-id-prefix’]);

    Also, the class of the label element, “hp-message”, does not seem to be defined anywhere. I wonder if that honeypot signature also be eliminated. Or, perhaps it could simply be replaced with the same user-custom class that is used for the input element.

    And finally, thank you very much for your time.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Altering the Honeypot Output HTML’ is closed to new replies.