Nginx no longer working

Hi @davidh64,

Please see the sticky post at the top of the forum — PLEASE READ BEFORE POSTING – Updated Jan 2017, and follow the links there to our support documentation and to our official support page. We don’t provide support here at the forums, but we do provide excellent support through our site, which is better equipped to help our plugin users.

If you feel that you do not fully understand the specific reasons, please feel free to submit a support request there, and we will be happy to answer your questions personally, which is how we handle support. Otherwise, these questions are too broad to be properly answered in a forum.

This question has already been answered in depth in our plugin documentation. I don’t think rehashing it is beneficial, but I will touch on some points.

Nginx no longer working

To be clear, it’s not that Nginx is no longer working…the issue is that standalone Nginx was never working. Users just may not have realized it.

Which difference irreversibly breaks compatibility of SpamShield with Nginx?

From version 1.0 on, WP-SpamShield has had requirements that are not met by Nginx. The plugin minimum requirements explain this. We go into further detail in the Known Issues and Plugin Conflicts page.

Many features work, but some key features do not work on standalone Nginx servers. When people had some issues, we added warnings in the admin. Eventually we had to take the step of having the plugin disable itself on standalone Nginx servers in order to prevent problems for users. This is noted in the changelog entry for version 1.9.9.8.2.

Nginx and Apache have some similarities, and some fundamental differences. A standalone Nginx server sacrifices some of the power and flexibility of Apache in order to gain some speed improvements. If configured properly, an Apache/Nginx hybrid setup gives the best of both worlds — you get the power, and the speed.

If you have further questions, please contact us via our support page, and we will be happy to help you out.

— Steven

Thanks for the response. I have already read the minimum requirements and the conflicts page prior to your response, but it is more than vague as to what is broken and especially how it is broken. I still fail to see why it wouldn’t work with nginx or another server for that matter. The only thing that is repeatedly mentioned is the .htaccess file, but from what I have seen, none of the instructions increase compatibility or add functionality(there are no redirects, rewrites or the likes, in there after all).

I agree that some other plugins, that use disk caching and such may require apache due to (dynamic) .htaccess files or so to function properly, but this isn’t the case here.

P.S. Setting up both apache and nginx just adds additional overhead on my machine, which is really short on memory and Apache tends to be on high side for memory consumption.

As a person who promotes more Nginx adaptability, it is sad for me to see that a plugin has dropped support for standalone Nginx server. At the same time, there are numerous plugins available to improve the security or to reduce spam. Personally, I use a plugin to minimise comment spam. All other security and anti-spam measures are done at the server level. If someone has complete control over the server, then it is recommended to do such comment-control measures at the server-level. It isn’t easy or straight-forward. There is a learning curve involved too. However, I am sure it is more efficient than doing it at the WordPress (PHP) level.

If this plugin is too important for someone who prefers to have it supported for standalone Nginx, who stops it from forking it and maintaining it?! When WP core dropped support for Postgresql, it didn’t stop others to fork it and continued to maintain it. Ref: https://github.com/kevinoid/postgresql-for-wordpress (last activity – 4 days ago)

…it is sad for me to see that a plugin has dropped support for standalone Nginx server

To be clear, the plugin has not “dropped support for standalone Nginx server” — it was never there to begin with, due to essential features not being available on standalone Nginx. Saying that we “dropped support” is a misconception.

It’s essential for plugin users to read the documentation and minimum requirements. We try to make things as easy as possible for users, and as already mentioned above, the deactivation was not “dropping support”, but rather a step to help to eliminate confusion.

Our development decisions are based on decades of server management/performance and security expertise. You are welcome to disagree with those decisions, and/or develop your own anti-spam plugin based on your own knowledge/expertise/opinions.

At this point though, this thread is a discussion of a disagreement with our development decisions rather than a support issue.

Again: Aside from .htaccess (which does not contribute to the functionality and ability to block spam), no Apache-specific features are used that would actually require Apache to be used with this plugin. Additionally, the plugin specifically checks if solely nginx is being used instead of checking whether or not Apache is running WordPress. Thus, this plugin should run with any Webserver except nginx, because it has been excluded for some inconceivable reason.

Please stop telling us to read the minimum requirements if they are merely based on the developer’s preferences instead of actual limitations. Instead, you should simply recommend Apache, everything else is untested and may or may not work

Hi @davidh64,

Again: Aside from .htaccess (which does not contribute to the functionality and ability to block spam), no Apache-specific features are used that would actually require Apache to be used with this plugin.

I’m sorry that you feel this way, but that is simply not accurate. I think you might be working with incomplete information.

We’ve made an effort to answer your questions previously and discussed the issue with you at length.

This is a two month old thread. I’m not sure what more can be accomplished here, as you don’t seem to be requesting support. As noted previously:

At this point though, this thread is a discussion of a disagreement with our development decisions rather than a support issue.

If you would like to discuss further, or ask specific questions, please contact us at the plugin’s support page, and we’ll be happy to help.

What am I missing though, what part of Apache is a necessity for this plugin to work? You only say that I am wrong and you certainly do have the big picture, being the developer and all, but it would be nice to prove me wrong as well ??

P.S. this should remain open for anyone to see and not become a personal exchange of emails, as nginx is a common webserver and others might be affected and want to understand as to why explicitly nginx is not supported.

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

@davidh64,

What am I missing though, what part of Apache is a necessity for this plugin to work?

I tried to discuss that with you couple months ago. You did not seem open to hearing any of what I had to say.

P.S. this should remain open for anyone to see and not become a personal exchange of emails, as nginx is a common webserver and others might be affected and want to understand as to why explicitly nginx is not supported.

Please see the support forum guidelines:

…the forums are not the appropriate place for starting topics unrelated to support issues.

This is not a support issue.

Our support page is here if you’d like to discuss further.

I went through the past messages, and – unless I have missed something – you have only mentioned the .htaccess support that nginx lacks. However, judging from the .htaccess files contents, they do not contribute to the functionality of the plugin. They basically only allow or block some content, apply compression for some file types and add headers about caching; all being a “kind of optimizations”, none of which that are required or couldn’t also be setup with nginx.

So in my eyes, this doesn’t really make it incompatible with nginx, unless I have missed another nginx-issue you have mentioned?

…unless I have missed another nginx-issue you have mentioned?

Yes.

Like I said:

This is not a support issue.

Our support page is here if you’d like to discuss further.

Hello,

I would like to know also what exactly is going on the .htaccess, there are some equivalent ways to add it the NGINX way and I can add it manually.

I suppose I can download the plugin and inspect files and run an apache setup to check what rules go in the .htaccess but that would take some extra time and it would be nice if can at least point in the right direction.

If is because of caching problems, that can also be dealt with skips and such to bypass and make it work.

Just wanted to try out the plugin ??

@lutechi

This topic has been beaten to death.

If you need tech support, please see the sticky post at the top of the support forum: PLEASE READ BEFORE POSTING — Updated June 2017, and if you need further help, please visit the plugin’s support URL.

— Steven

@lutechi
The plugin has no statements in .htaccess that are crucial for the plugin to function. It only contains some instructions for caching and compression as well as access denied for files that came with the plugin. All you need to do to make it work is to make sure the plugin skips the pointless apache/nginx server check (see wp-spamshield.php at comment “/* Standalone Nginx */”. either force the if statement to be false (has to be edited on each plugin update!) or try a global hack by skipping the “requirements” check entirely by setting $wpss_requirements_checked to true (not recommended!).

Either way, it is a pain to use this plugin without Apache… I still do not understand why Apache is enforced/standalone-nginx is to be avoided and their tech support also failed to provide an definitive answer to that question.

P.S. Some .htaccess statements may be written dynamically (see ‘/* 5 – Write .htaccess */’ in wp-spamshield.php), but this is just some more optional access management by allowing certain IPs ($admin_ips) access previously forbidden files (mainly the also optional comments log)

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

@davidh64,

The plugin has no statements in .htaccess that are crucial for the plugin to function. It only contains some instructions for caching and compression as well as access denied for files that came with the plugin.

This is simply not accurate. Please do not spread incorrect info about WP-SpamShield.

I still do not understand why Apache is enforced/standalone-nginx is to be avoided and their tech support also failed to provide an definitive answer to that question.

Our tech support provided you with definitive answers, including an entire article about the issues involved. Clearly you’re not familiar enough with the differences between Apache and Nginx, and you’re not familiar with the more advanced features of .htaccess. Unfortunately that isn’t something that tech support can help you with.

I would ask that you not come onto the forums and make unfounded negative remarks about us…that just seems like trolling to me. I’m asking you to stop…you’ve been doing this long enough.

In the last 2 years, the only thing you have have posted about on the WordPress forums is why you are unhappy that standalone Nginx is incompatible with WP-SpamShield.

This particular thread is 4 months old and this is not helpful to anyone.

@ To anyone else reading this:
Please disregard the advice posted by @davidh64 as it simply is not accurate. We don’t advise hacking the plugin, and we don’t provide support for hacked versions of the plugin. It’s one thing to post your opinion on the forums once or twice, but it’s another thing to come on here and troll the forum for months on end. If anyone needs help, we have outstanding support available at the WP-SpamShield Support URL.

• This reply was modified 7 years, 2 months ago by rsm-support.

I’m sorry if I have offended you and by no means did I mean to troll you or anyone else involved.

However, you failed to persuade me or provide examples/proof of how standalone Nginx is not enough to run WordPress and WP-Spamshield flawlessly. You always name the missing .htaccess support as a reason, yet repeatedly fail to name the crucial .htaccess code that, according to you, breaks this plugin for standalone Nginx. As I have stated countless times, the Apache instructions of this plugin don’t contain anything groundbreaking which contributes to the functionality of the plugin, nor are those configurations unportable to Nginx config files.

Also, I am running standalone Nginx, have not ported any .htaccess instructions of this plugin to my nginx config and it is all running without any issues for well over a year now, blocking all that awful spam flawlessly.

Again: .htaccess support is not required by this plugin, only enforced for some weird reason.

This is my last post, as I am also sick and tired of this topic.

P.S. In the end, despite all this nginx-stuff, thank you for the plugin!