• Resolved Ben Marshall

    (@bmarshall511)


    I’m reaching out on behalf of our team at Zero Spam. We have recently received requests from our customers who are using the ProfilePress WordPress plugin, expressing the need for compatibility with our plugin, Zero Spam.

    After further investigation, we have identified an issue with the login process implemented by the ProfilePress plugin, which currently conflicts with the functionality provided by Zero Spam. Our customers have reported that enabling Zero Spam prevents the ProfilePress login process from functioning as expected.

    To address this compatibility issue, we would like to request support from the ProfilePress team. We are keen to ensure that our plugins work seamlessly together to enhance the security and user experience of WordPress websites.

    In order to integrate our plugins effectively, we kindly ask if you could provide us with documentation or any available resources that outline the hooks (filters and actions) utilized by ProfilePress for its login and registration processes. This information would greatly assist us in adding support for the ProfilePress plugin within Zero Spam.

    We highly value the collaboration between our two teams and believe that resolving this compatibility issue will benefit our mutual users. By working together, we can ensure a smooth and secure experience for WordPress site owners.

    Thank you in advance for your assistance. We appreciate your prompt attention to this matter. Please don’t hesitate to reach out if you have any questions or require further information. You can contact us directly at [email protected]. We look forward to your response.

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 16 total)
  • Eli

    (@realact)

    @bmarshall511 thanks for your interest on fixing customer issues, going above and beyond. I’ll also be anxiously waiting for ProfilePress’s response on this matter.

    Regards!

    -Eli

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    For login process, use the ppress_login_validation filter. Here’s an example https://github.com/profilepress/library/blob/main/block-login-from-specific-domain.php

    For registration form, use ppress_registration_validation filter. Here’s an example https://github.com/profilepress/library/blob/main/restrict-registration-to-domain.php

    Let us know if you have any more questions.

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky Thanks for the quick response. Are there any hooks to be able to dynamically add form fields to those forms?

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    Yes. Check these:

    https://plugins.trac.ww.wp.xz.cn/browser/wp-user-avatar/trunk/src/ShortcodeParser/RegistrationFormTag.php#L105

    https://plugins.trac.ww.wp.xz.cn/browser/wp-user-avatar/trunk/src/ShortcodeParser/LoginFormTag.php#L99

    For the login form filter above, in your callback, close the form tag and then you can append your own eg input field without the trailing closing angle bracket.

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky

    Thanks for sharing those links! I’ll definitely check them out to understand how the login and registration forms are handled. Appreciate the guidance!

    One last thing, do you happen to know if there’s a specific hook I can target to load some JavaScript when the login or registration form is present on the page? It would be great to have that functionality for a certain feature we’re working on.

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    You can use any of the filters I mentioned in my previous message to load the javascript.

    Alternatively, you can use ppress_registration_form and ppress_login_form filters too.

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky Thanks for that, however I don’t believe you can enqueue scripts via filters. Is there something else I can hook into?

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    If the script can be deferred and loaded in the website footer, you can do something like

    add_filter('filternamehere', function($val) {
    add_action('wp_footer', function() {
    output the script with the script tag here.
    });
    return $val;
    })

    You can even enqueue inside the filter callback so long $in_footer parameter is set to true.

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky

    Thanks for getting back to us. We always strive to follow WordPress best practices, and unfortunately, manually adding a script tag in the footer goes against those guidelines. This approach can hinder optimization, minification, reorganization, and other services that help improve performance.

    We’ve tried various methods, but it doesn’t seem possible to enqueue already registered scripts in a filter function or add inline scripts. We’ve experimented with these options, but without success.

    If there’s another solution or hook that we might have overlooked, please do let us know. We’re open to exploring alternative approaches. Otherwise, we may have to omit one of the methods for detecting spam and malicious users.

    Thanks again for your understanding and assistance. We appreciate your input!

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    Maybe you tell us, where would you ideally want us to add a hook for your usage?

    Note that, our forms are embedded by shortcodes and because shortcodes are rendered as WordPress content, it would be too late to enqueue any script to the website header.

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky

    It seems there may be some confusion regarding the usage of hooks with shortcodes. We have successfully implemented similar integrations in the past, where shortcodes are used.

    In our case, we utilize an action within the add_shortcode function, allowing us to hook into it and enqueue scripts as needed. You can find an example of this approach in action on the WordPress Stack Exchange site: https://wordpress.stackexchange.com/questions/165754/enqueue-scripts-styles-when-shortcode-is-present.

    By utilizing this method, we can ensure that the scripts are properly enqueued even when dealing with shortcodes embedded within WordPress content. This way, we can effectively load our scripts without any issues.

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    So I guess there is nothing we need to do on our end. Correct?

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky

    To ensure a smooth integration and optimal functionality, it would greatly benefit us if an action could be added within your add_shortcode functions. This action would enable us to easily hook into it and enqueue our scripts as needed. If such an action is not already available, we kindly request that you consider adding it. This addition will significantly contribute to the seamless integration of our scripts and enhance the overall user experience.

    Furthermore, it would be highly advantageous to have a dedicated hook that allows us to programmatically add form fields to the login form. Currently, there is a filter placed within the form tag itself, but we have concerns about potential issues with code integrity in future updates. Having a separate hook specifically designed for this purpose would ensure greater flexibility and compatibility moving forward.

    We sincerely appreciate your cooperation and support in making this integration a resounding success. We’ll be launching the initial integration for ProfilePress soon & can see the progress here: https://github.com/Highfivery/zero-spam-for-wordpress/issues/357

    Plugin Author Collins Agbonghama

    (@collizo4sky)

    The following actions were added and would be available in the next plugin updates.

    do_action('ppress_login_form_before');

    do_action('ppress_registration_form_before');

    Thread Starter Ben Marshall

    (@bmarshall511)

    @collizo4sky

    While we understand the intention behind the naming of these actions, we believe it might be more intuitive to have the actions within the form itself, rather than before the form. This would allow us to easily add the necessary fields or customize the form as needed.

    We kindly request considering a slight adjustment in the naming convention to reflect their placement within the form, such as do_action('ppress_login_form_inside'); and do_action('ppress_registration_form_inside');. This adjustment would provide greater clarity and make it easier for developers to understand where to place their customizations.

Viewing 15 replies - 1 through 15 (of 16 total)

The topic ‘Zero Spam Support’ is closed to new replies.