Forum Replies Created

Viewing 15 replies - 166 through 180 (of 1,410 total)
  • Hi Hector and Michael,

    I can shed some light on this. After receiving Michael’s support request and debugging info, we identified the issue.

    Right now when WordPress Popular Posts does an AJAX call, it doesn’t identify itself as an AJAX request by using the X-Requested-With: XMLHttpRequest header. That’s the de facto standard for identifying AJAX calls. You might want to check out this thread: http://stackoverflow.com/questions/1885847/jquery-no-x-requested-with-xmlhttprequest-in-ajax-request-header

    Hector:
    In the main file on line 1378 you have:

    
    xhr.setRequestHeader( "Content-type", "application/x-www-form-urlencoded" );
    

    After that, add something similar to this:

    
    xhr.setRequestHeader( "X-Requested-With", "XMLHttpRequest" );
    

    That’s all! *You’ll need to check the specifics, and test appropriately, but that’s the general gist.

    As part of WP-SpamShield’s support for all third party contact form plugins, WP-SpamShield checks the admin-ajax.php POST requests. (We can’t just check the DOING_AJAX constant in WordPress, as other non-AJAX POST requests can come in through that endpoint.)

    Currently (as of the current version 1.9.9.9.5), WPSS ignores all requests coming in through admin-ajax.php (at least for the relevant test that is currently causing the block) that are identified as AJAX with the X-Requested-With: XMLHttpRequest header. We’ll also add specific whitelisting for WPP in the next version, but if you change the params in the future, the XMLHttpRequest will help across the board (likely with other plugins as well that deal with security).

    We also have a guide for other plugin developers, and you can contact us here as well: https://www.redsandmarketing.com/plugins/wp-spamshield/hooks/

    Michael and Hector:
    There is a temporary workaround that can be used: Disable anti-spam for miscellaneous forms. However there are drawbacks, so we don’t recommend it: It will disable anti-spam for any third party forms (other than CF7 and Gravity), as well as protection against many XML-RPC based attacks, such as brute force amplification attacks and Pingback based DDoS attacks, etc. See here for more info.

    Hope this helps. Feel free to contact us for further help/info.

    — Scott

    Plugin Contributor redsand

    (@redsand)

    Hi Gone Fishin,

    It’s definitely not an intended behavior. WP-SpamShield would not want to block AJAX functionality. We never want to interfere with other plugin functionality. The goal is to run quietly in the background without interfering with any other site functionality or user experience.

    AJAX makes POST requests exactly like a form does. It’s likely either #2 or #3 — in either case we’d need to get more info from you through the official support channel. If the plugin does not identify itself properly as an AJAX request (by adding an X-Requested-With: XMLHttpRequest header), it might be #2, but we’d have to test and see. There are possibilities for whitelisting in individual cases, but if plugins are using well-coded AJAX, it usually isn’t necessary.

    So yes, if you want to follow up with a support request, we can likely get the exact issue/conflict figured out quickly.

    Thank you for the plugin, your time, and your impressively fast response. πŸ™‚

    You’re very welcome! We want all of our plugin users to have a flawless experience. When an issue gets discovered, we strive to get a patch released within 24 hours or less.

    – Scott

    Hi Jason,

    No problem! We want things to work flawlessly, and we definitely don’t want to hinder the functionality of other good plugins. πŸ™‚

    Offhand the code you posted looks on-track. The third line:

    
    request.setRequestHeader( "X-Requested-With", "XMLHttpRequest" );
    

    is the most important part. Everything else should be fine. I’d just recommend testing out the code by running some debug code in the admin-ajax.php when your code runs and output/log/vardump the request headers to make sure it’s been added properly. If it has the X-Requested-With: XMLHttpRequest header, you should be good to go.

    Thanks for the awesome review! You guys rock as well. πŸ™‚ Keep up the good work.

    – Scott

    Hi @aadind and @elliekennard,

    If those sites are getting hacked, it’s not because of WP Super Cache. Cybersecurity is one of our core specialties. This is a solid and secure plugin. Feel free to review its security track record. It hasn’t had a security vulnerability in a year and a half, and each time it has had one, it was fixed quickly. On the contrary, W3TC has had a number of recent vulnerabilities.

    It’s far more likely that a site was hacked because of poor user security practices, outdated plugins themes, or any number of other factors.

    I can confidently say that this plugin is safe. Feel free to research the facts for yourself, but they won’t contradict.

    – Scott

    Forum: Plugins
    In reply to: [WP Super Cache] PHP update

    Hi @rcharbonxx,

    First off, I just want to say that I’m not affiliated with WP Super Cache, but have been using it for many years, and am a huge fan of this plugin. (Also, a fellow plugin developer.)

    That’s a false positive. See this thread, as it’s already been reported to the PHP Compatibility Checker plugin devs.

    Unfortunately the PHP Compatibility Checker plugin is not too accurate. It uses a flawed detection method. All it ends up doing is creating a headache for other plugin developers. (We’ve been through this a few times with our plugins getting falsely flagged as well.) If you look at its support threads, you’ll see it’s full of false positive reports. In our tests of over 100+ plugins, it’s had false positives in the range of 30-40% (depending on the version).

    The way to accurately test PHP 7 compatibility is to run plugins on a test site on a PHP 7 system and use WP_DEBUG in logging-only mode. (See instructions in our WordPress Debugging Guide if you need any help with this.)

    I hope this info helps!

    – Scott

    Plugin Contributor redsand

    (@redsand)

    Hi Miguel,

    Thank you so much for taking time to leave us a review and for letting us know how much you like the plugin. That’s excellent…exactly what we like to see, and why we designed the plugin. πŸ™‚

    – Scott

    Plugin Contributor redsand

    (@redsand)

    Hi @rrhode,

    I just wanted to say thank you for the thoughtful review and positive feedback.

    You are very welcome! We’re glad we can help you get rid of spam once and for all. πŸ™‚

    Have a good one!

    – Scott

    Hey Joe,

    WP-SpamShield will take care of the spam for you. You literally don’t need to do anything. Just install it, and activate. It’s invisible, no CAPTCHAs — it just works.

    It supports all 3rd party forms like Ninja Forms.

    Full disclosure: I’m the lead dev, and this is clearly a shameless plug, but every word above is true. πŸ™‚

    – Scott

    MP:

    Just wanted to follow up.

    Thanks for the positive feedback! Glad to help.

    We got the issue figured out, and now spam is being blocked properly on the Beta, as well as the stable. Just to give some feedback: It had to do with the form POST endpoint being changed to admin-post.php in the beta version (which we were not expecting). We haven’t seen that endpoint used commonly and so we weren’t checking it for POST entries. That has been fixed, and now it checks that endpoint as well. I’m actually glad this issue came up, as it gave us a chance to make an improvement that we might not have made otherwise. πŸ™‚

    If you ever need to get in touch with us regarding plugin compatibility, we have a guide for other plugin developers and you can contact us through that page.

    MP + CN: Let us know if we can ever help with anything else. Have a good one!

    – Scott

    Plugin Contributor redsand

    (@redsand)

    @dcgavri,

    BTW I agree about Stackoverflow and xda-developers.

    The WordPress.org was meant for open source development, but it failed to provide the same tools and features as GitHub or GitLab, in order to be easy to collaborate and share knowledge.

    This is not really a “forum” at all, or maybe a “low-functioning forum”. For example there is no way to PM anyone. That is essential. Not really worried about anyone throwing rocks. πŸ™‚ Security is an area of primary focus for us, and forums just aren’t a great way to transmit diagnostic data, logs etc.

    I definitely wanted to pitch in (already did by stating an issue between versions and losing a lot of time debugging the causes of a site functionality crash – so did @terryg-1 ), but there’s no point in doing so, if your reaction is like that, we all have companies or do dev/consulting or whatever, but we try keep a fruitful collaboration while developing open source solutions.

    I’m not sure why you would say that. It seems to me that is an unfounded negative reaction. We love our plugin users, and bend over backwards to help. There is absolutely no reason to spend a lot of time debugging…just let us know you need help, we get some diagnostic data and email back and forth, and boom, we fix it in no time. No reason to argue or be unhappy. πŸ™‚ I’m not sure why that would be so objectionable. Meanwhile other people ARE pitching in, and helping solve the issue…for all users. It took them less time than it took you to write these responses. πŸ™‚

    Real open source development is a lot easier than closed source or β€œopen source” by 2-3 devs, because people collaborate and manage to find solutions faster to existing problems.

    In general, I completely agree…I just don’t think that applies here. That applies more to creating solutions for specific coding applications, but not so much for tech support, and/or diagnosing specific bugs. We already have diagnostic tools in place. If plugin users submit logs, rule out common issues first, we can usually fix the bug in minutes.

    I do appreciate your input though. πŸ™‚

    Just a follow up to anyone reading this thread:

    Thanks to a couple plugin users who reported a similar issue through the plugin’s support page, we were able to locate the issue, and create a fix. Version 1.9.9.9.5 has been released, and will take care of the issue.

    I’m going to mark this thread as resolved, but if anyone has any further issues, please submit a support request at the WP-SpamShield Support Page, and we will be happy to help you out.

    – Scott

    Hi @websiteopzetten and @coolmann,

    Just wanted to give you both a heads up that we just released WP-SpamShield version 1.9.9.9.5 with the fix. Tested and confirmed working with Slimstat. πŸ™‚

    Let us know if you have any further issues.

    – Scott

    Plugin Contributor redsand

    (@redsand)

    No point in continuing a discussion if you are trying to lecture me on how good your dev team is.

    We’re not trying to lecture anyone. Just providing some background, and asking you to be considerate. Open source requires everyone to pitch in…not just the developers. It doesn’t work unless everyone participates. You said that we’re “forcing” people into something that we’re not. That was an unfair statement…am I not allowed to respond to that and clarify?

    Developing open source is easy, supporting it, is the real pain.

    I would definitely not agree about developing open source being easy. Both aspects require a lot of work. We consider support as part of development. Each improvement is part of striving for perfection.

    I appreciate your work and want to thank you again.

    You’re very welcome. πŸ™‚ You have a good day as well.

    Plugin Contributor redsand

    (@redsand)

    Hi @dcgavril,

    PS: forcing people to move the support questions to your site is not the best solution, because it’s not an open forum. – but that’s just my opinion.

    To be clear, we’re not forcing anyone to do anything. What we are doing is offering top notch tech support — for free.

    Plugin developers are not obligated in any way to provide support for plugins — whether in the WordPress directory, or anywhere else. Yes, we choose to provide top notch tech support, for free.

    The forums are provided for developers that don’t have a better support solution or system. We do have a better system.

    For example, we have all the documentation on our site, and it can be translated into many languages. That can’t happen here.

    We have troubleshooting guide and FAQs on our site, but not here. Those alone solve over 90% of people’s issues.

    It’s an inaccurate assumption to think that the issue affecting you is affecting everyone. In most cases it’s not a general issue, but rather a conflict specific to the site or plugins. In those cases, we need debug feedback from the user, and we need to have a back and forth conversations. For security, this can’t be done by forum.

    That’s why all the tech support links in our plugins point to our site, not here.

    An open forum is nice, but it’s not efficient for tech support. It’s also not secure. It’s great for discussing political issues or news, or for voicing consumer complaints that have not been resolved for a long time. We’re not about that. We’re about solving problems. We’d rather our users just have zero issues.

    When users contact us through the plugin’s actual support channel, we can fix issues within a day. That’s simply not possible through the forums either. So, please ask yourself, would you like the issue fixed, or would you like to prolong the issue not being fixed?

    You end up helping all the other plugin users if you follow our support process, because it allows us to diagnose and fix issues quickly, and all the other plugin users can benefit from this. By extension, it ends up hurting all the other plugin users by not following our support process because it prolongs issues getting diagnosed and fixed. It really is that simple.

    Also, please keep in mind that there are almost 200,000 users of the plugin, and we have over a quarter million plugin users for all of our plugins. We provide free support for all of these. There are far more of you all, than there are of us. We need the plugin users to take a few minutes to do some self-diagnosis first, otherwise free support simply is not possible.

    We’re one of the most experienced WordPress development and support teams out there, and we’re known for our expertise in these matters. We’ve done tech support on literally tens of thousands of WordPress sites over more than a decade. This isn’t our first rodeo…we know what we speak of. πŸ™‚

    Thanks for understanding. πŸ™‚

    – Scott

    Plugin Contributor redsand

    (@redsand)

    I posted here (as stated in #1) so that people could find and be made aware of this issue with admin-ajax.php being Forbidden (403) and have a, at least temporary but workable, solution.

    Unfortunately that doesn’t help us fix the issue. πŸ™

    We do want to address the issue, but the forums don’t provide the appropriate resources to solve the issues. Unfortunately, if users don’t want to follow our support process, there is nothing we can do to help.

    Our process is tried and true, and extremely effective, which is why we have such positive feedback and reviews about our support. Our system is setup like it is for many good reasons. When issues are reported to us, we solve them within a day. But it requires back and forth conversation, interaction, and testing/debugging, which simply isn’t possible here.

    I know you feel that you are helping make people aware of the issue, but all that does is actually prolong the issues instead of allowing us to fix it. It’s actually counterproductive. We strive for perfection, and in our perspective, we’d rather have zero issues for our users. We solve issues…that’s what we do. We need users to work with us though for that to happen.

    Hi Jason,

    No problem! πŸ™‚ You guys are very welcome. Keep up the good work.

    – Scott

Viewing 15 replies - 166 through 180 (of 1,410 total)