DavidH64

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!

@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.

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?

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.

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

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.

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

Thanks!

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.

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.

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.

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?

I just restarted PHP (php5-fpm to be exact) and that seems to have fixed the issue. Maybe it is related to the php opcode cache? I am using xcache on my server… mhh… next time, in case it does happen again, ill just clean the cache specifically and see if that fixes the problem.

I hope this also solves it for everyone else!

Ran into the same issue and tried to investigate it:

The sharify-style.php is sometimes empty (500 server error). It hangs, more often than not, at line 4: require_once($wp_load);

I am not getting any specific errors aside from the unhelpful 500, even when setting error_reporting(E_ALL) and using try-catch, I get nothing. Even the PHP error logs are clean! It is VERY strange…

Best of all, I have a copy of the blog running on another server and that one seems unaffected by this issue. I am clueless.

P.S. reinstalling did nothing :-/

Just updated the plugin. No more warnings and/or blocked requests. Thanks a lot!

just tested the update and it works again. no more orphaned files. thanks a bunch!