quit working after upgrade

This plugin worked well for over a year and several wordpress and plugin updates. However after the last plugin update to version 1.9.9.8.5 it stopped working and says it is incompatible with my nginx server. So I am looking for a replacement plugin now.

Hi @frogola,

I’m sorry that you were frustrated, but the plugin does not deserve a negative review for this.

WP-SpamShield has never been compatible with standalone Nginx servers. This has always been explained in the plugin Minimum Requirements, and in the Known Conflicts page.

The plugin requires use of an .htaccess file, which a standalone Nginx server does not use. Prior to version 1.9.9.8.2, if a site was running on a standalone Nginx server, there was a warning in the plugin’s settings page.

In version 1.9.9.8.2, we added functionality to enforce existing plugin Minimum Requirement #3, “Your server must be configured to allow the use of an .htaccess file.” Accordingly, from version 1.9.9.8.2 onward, if a standalone Nginx server is detected, the plugin will now deactivate. Unfortunately despite the fact that there were warnings in the admin for a long time now (on the plugin’s settings page), not everyone paid attention to these, and it became necessary to add this functionality.

Even though some elements may work on standalone Nginx, not everything will work properly.

It’s not a matter of “adapting the plugin for Nginx”, or not “supporting Nginx”…Nginx just doesn’t have the capability to support all of the plugin’s features. Nginx is not a drop-in replacement for Apache…they have some differing features. Nginx does not have an equivalent to .htaccess. (A directory level configuration file.)

We previous had allowed the plugin to continue to run on standalone Nginx setups with the warning, but it’s become quite a headache because some users won’t read the instructions and then contact us with angry support requests, or leave angry negative reviews. (This review is an example.)

It’s a bit ironic if you think about it, because we are up front and tell users that not everything will work on standalone Nginx, and then some people come back to us angry because not everything works…on standalone Nginx.

So, unfortunately we cannot allow it to run on standalone Nginx servers, since they do not meet the plugin’s minimum requirements. It’s just the cleanest solution, and was implemented in version 1.9.9.8.2.

It is extremely important for plugin users to read the documentation, and at the very least, the Minimum Requirements. If you try to install software on your computer, would you fault the software if it would not activate on an incompatible system?

Additionally, if you had a concern, wouldn’t it have been more appropriate to submit a support request to inquire about the change instead of jumping right to a negative review?

Please ask yourself this…When developers spend so much time developing free plugins for the WordPress community, is it really ok to post a negative review without making any reasonable effort to receive support? That’s simply not the right way to handle things.

If you have an issue with something, submit a support request first, and give the author time to respond. We provide free support for our plugins…all you have to do is submit a support request at the WP-SpamShield Support Page. We provide some of the best support out there.

You might want to take a moment to check out these two posts:

• There’s a wrong way to give plugin feedback on www.ads-software.com
• How to Leave a Good Bad Review

I would ask that you reconsider your rating, as it simply isn’t accurate or fair. (No one is asking for a 5-star review, just a fair review.) If you are so inclined, your can be updated by going to: https://www.ads-software.com/support/plugin/wp-spamshield/reviews/#new-post

Reviews like this simply do not help the global WordPress community.

– Scott

• This reply was modified 7 years, 10 months ago by redsand.
• This reply was modified 7 years, 10 months ago by redsand.

Sorry you’re pissed Scott. If your plugin has never worked properly or supported my configuration [nginx server] then I’m afraid I don’t understand how I can give it a positive, glowing review. I would give it a great review if it worked on my system — according to your own words it does not and has not. So of course I admit it’s my fault for not RTFM. But that doesn’t mean you can weasel a positive review out of me.

Good luck and I’m sure you will have many positive reviews from supported sites.

Hi @frogola,

I’m sorry if you misunderstand my tone. I’m not angry, just pointing out something that doesn’t seem quite right to me. I understand that you were frustrated.

I would like to ask though, how is our fault if you did not read the minimum requirements, and then installed software not compatible with your server?

It’s an end-user’s responsibility to check the requirements before installing. That’s not said to place any kind of blame or to sound rude. Just making an observation.

Like I said in my initial response, “No one is asking for a 5-star review, just a fair review.” I would never ask you give it a 4 or 5 star review if it doesn’t work for you. However, it certainly does not deserve a negative review.

I’m honestly not concerned with “ratings”. I just want to get across accurate information to users. I would ask you to reconsider out of fairness and accuracy. I’m sure if you were in the reverse position, you would request the same consideration.

Take care.

– Scott

• This reply was modified 7 years, 10 months ago by redsand.
• This reply was modified 7 years, 10 months ago by redsand.

I have looked through the .htaccess files that come with the plugin and aside from blocking some files or applying compression, the configuration in .htaccess doesn’t seem to do anything that contributes to the compatibility with either Apache or Nginx. The files it blocks are already in the public (come with the plugin) are noncritical (e.g. translation files) and the php files themselves don’t seem to do anything either (they check for direct access).
Also, it is possible to convert whatever your supplied .htaccess files do to a compatible Nginx configuration. Additionally, deactivating .htaccess within Apache is also possible. You blocking Nginx just for being Nginx makes no sense.

It seems, that you are just pushing Apache for no apparent reason.

What breaks or would break if you ran it on standalone Nginx or another server which does not support .htaccess? What are the benefits of the .htaccess files in the first place?

the configuration in .htaccess doesn’t seem to do anything that contributes to the compatibility with either Apache or Nginx. The files it blocks are already in the public (come with the plugin) are noncritical (e.g. translation files) and the php files themselves don’t seem to do anything either (they check for direct access).

Unfortunately this is not an accurate assessment. Apache and Nginx are not 100% interchangeable. .htaccess provides a lot more power and features than you may realize.

Most of what you’re asking is covered in the plugin documentation. Please read the section on Nginx in the Known Issues and Conflicts page.

Your conflict page does not list anything concrete or evidence that the plugin would break on nginx standalone configurations.

Also, I checked your .htaccess files and as I said previously: All of it could be “translated” to Nginx, as all you do is apply access restrictions (mod_authz_core), compression (mod_deflate) and some headers (mod_headers). None of these things are crucial to make this plugin work. Additionally, these modules are optional and might not even be enabled on some Apache-based servers.

So my previous points are still valid:

• The configuration in .htaccess doesn’t seem to do anything that contributes to the compatibility or functionality of the plugin when used with Apache.
• Blocking Nginx just for being Nginx makes no sense.
• You are pushing Apache for no apparent reason.

• This reply was modified 7 years, 7 months ago by DavidH64.
• This reply was modified 7 years, 7 months ago by DavidH64.

Your conflict page does not list anything concrete or evidence that the plugin would break on nginx standalone configurations.

It does if you read the whole thing and the linked articles. I’m not going to re-hash things that are already explained in the docs, but I’ll be happy to answer questions if you want to submit a support request.

Also, I checked your .htaccess files and as I said previously: All of it could be “translated” to Nginx, as all you do is apply access restrictions (mod_authz_core), compression (mod_deflate) and some headers (mod_headers).

Again, that’s not accurate either…you’re missing some things. Like I said, there is a lot more to it than you may realize.

You blocking Nginx just for being Nginx makes no sense.
You are just pushing Apache for no apparent reason.

It won’t make sense if you aren’t intimately familiar with the nuances of the two servers. That whole argument is an oversimplification and is still not accurate. We’re not “blocking” Nginx. It just doesn’t have the requirements. Simple as that. Apache and Nginx have different benefits and drawbacks, and there multiple ways to employ them.

We are working on creating an anti-spam plugin that is specifically for Nginx, so saying that we “block” Nginx, are “pushing Apache”, or are anti-Nginx, is ridiculous.

I’m not going to argue with you here, but if you have specific questions, we’ll be happy to answer them if you’d like to submit a support request.

Take care.

Uhm… You are specifically checking for nginx in wp-spamshield.php… You don’t check for other common servers or whether apache has .htaccess enabled or not. You only check for Nginx, and if it is Nginx, the plugin gets auto-disabled. That seems pretty anti-nginx to me. Lighttp, IIS and [your underdog server here], will continue to work with the plugin.

However, you are correct: Apache and Nginx are not perfectly interchangeable and there are limitations to both servers.
However, in this case, I do not see why they shouldn’t be interchangeable. The only apache-feature you use are the .htaccess files and the configuration there does not contribute to the functionality of the plugin, it only does:

• Block access to some php files. Not really required, as the files in question do check, whether they were called directly or by wordpress. If its the former, you get an error. This is already sufficient.
• Block access to some translation files. Not required and I don’t see the point of it, as these are freely available to anyone who downloads the public plugin. Though, one could still block these files with nginx as well, if they wanted to.
• Adds some headers to disable caching for txt-files. Not sure what this is for, as there are no .txt files that should be downloaded by a visitor, at least as far as I can see. Are these created dynamically? Not sure, but even if it were required, it could still be done with nginx.
• Enable compression for txt files. As I said previously: Files nobody seems to grab anyway. Also, this is already the default for Nginx from the debian 7+ repository, as far as I know. If not: its still configurable in nginx

So again: No need to distinguish between Nginx or Apache as it doesn’t seem to matter at all.

Please, just remove the apparently pointless Nginx restriction and it should work with both nginx and apache again. Otherwise, please prove me wrong. I obviously only skimmed the files, but I still couldn’t find anything that told me “Gotta use Apache, no matter what”. Well, aside from your nginx check, lol ??

• This reply was modified 7 years, 7 months ago by DavidH64.

Uhm… You are specifically checking for nginx in wp-spamshield.php

Yes, it’s not uncommon for software to check for the minimum requirements and deactivate itself if the requirements are not met.

This is explained in the Changelog entry for Ver 1.9.9.8.2:

Added functionality to enforce existing plugin Minimum Requirement #3, “Your server must be configured to allow the use of an .htaccess file.” Accordingly, if a standalone Nginx server is detected, the plugin will deactivate. Standalone Nginx servers have never been supported by the plugin, and this has always been explained in the plugin Minimum Requirements, but unfortunately despite existing warnings in the admin, not everyone pays attention, and this became necessary.

I do not see why they shouldn’t be interchangeable.

Ok…All that means is that you don’t understand all that goes into the plugin functionality.

Like I said, not going to argue here. If you have questions, and want answers, then use our support page. Otherwise you’re just criticizing and trolling, which isn’t constructive.

I believe this should be an open discussion with the rest of the community instead of a technical support ticket. That way, people running into the same issue can find it.

I’ll open a new thread in the WP support forum of WP-SpamShield instead and copy over my points over there, so that you (or someone else) can answer why the things are the way they are.

This is like arguing about why Apple software doesn’t run on Microsoft, and vice verse. Not exactly constructive, and been done to death already. Not gonna do Nginx vs. Apache arguments. Stackexchange is probably a better place for that.

I continued this discussion over there: https://www.ads-software.com/support/topic/nginx-no-longer-working/

Thanks!