saintandrews

Thanks, Sanjeev.

I’ve got the plugin pretty much wiped from every option table I could find it in, and, because the recent WordPress core critical protection function automatically blocks me from activating it in order to activate its uninstall option, I believe at this point I’ll just leave well enough alone since I’ve since found an alternative that doesn’t present those problems.

Since I can delete plugins from their folder directly anyway, one might think the WordPress core developers would leave the option to take the risk of activating the plugin if the user wanted to rather than simply paralyzing any use of it.

Thanks, Frank.

I loaded and ran both plugins and each said the test mails were sent without a problem – which then meant something intercepted them and, sure enough, it was my host. So, to answer my initial question: it depends.

BTW, any idea when the MaxMind databases will get updated?

• This reply was modified 2 years, 12 months ago by saintandrews.

The script wasn’t executed. What you see is its content, like a text file. Did you upload it over FTP and give it a .php extension ?

Yes.

I just now downloaded the pastebin version, gave it the .php extension as I did previously, uploaded it to the root as I did previously, and ran the same exercise with the three different email addresses as I did previously.

This time none of the three returned anything in my browser (Firefox), and no email was delivered to any address.

Perhaps I should add that, per security recommendations, my wp-config.php file is not in its default location, although the firewall has never had any problems because of that.

• This reply was modified 2 years, 12 months ago by saintandrews.

I ran the script three times, once with each email address, the first two on my domain, the last on the commercial domain. The respective returns in my browser were:

<?php $recipient = '[email protected]'; require 'wp-config.php'; $subject = 'Email test'; $message = 'This is a test.'; $res = wp_mail( $recipient, $subject, $message ); if ( $res === true ) { echo "Email sent to $recipient."; } else { Echo "Error"; }

<?php $recipient = '[email protected]'; require 'wp-config.php'; $subject = 'Email test'; $message = 'This is a test.'; $res = wp_mail( $recipient, $subject, $message ); if ( $res === true ) { echo "Email sent to $recipient."; } else { Echo "Error"; }

<?php $recipient = '[email protected]'; require 'wp-config.php'; $subject = 'Email test'; $message = 'This is a test.'; $res = wp_mail( $recipient, $subject, $message ); if ( $res === true ) { echo "Email sent to $recipient."; } else { Echo "Error"; }

No actual emails arrived at any of the three destinations.

No, there’s been nothing like that, nor ever any evidence that anything is wrong at all. If I try to bulk edit remove category from one post, everything seems to cycle normally with a final “1 post updated”, except it wasn’t. Two posts, “2 posts updated”, except they weren’t. No other messages or adverse behaviors or any evidence of any sort at all.

Even running WP_DEBUG while trying to bulk edit remove a category the only return I get is

[13-Apr-2021 04:06:49 UTC] PHP Deprecated: WP_Query was called with an argument that is deprecated since version 3.1.0! caller_get_posts is deprecated. Use ignore_sticky_posts instead. in /home/name/example.com/wp-includes/functions.php on line 5145

which seems utterly innocuous.

Yes, I noticed the plugin’s elegance, which is why I was astonished when it didn’t work.

If I may, what was the Jetpack issue? I notice in my logs Jetpack sticking its nose in when I attempt to run your plugin.

Other than that, I’m afraid I’m going to have to continue by trial and error. Even on a shared server I run pretty lean, and I only have two of Jetpack’s modules loaded and activated, so it shouldn’t be a resource problem unless yours is particularly hungry. And I’m afraid I have no test environment access available to grant you.

Thanks for the quick response.

What, exactly, does “hosting related” mean, and why would the host determine whether a WordPress plugin works or not? I’ve of course heard of managed WordPress operations banning certain plugins because of their server load, but that isn’t the case with me. I also checked my site’s host-provided PHP log just to see if there were any clues there, but there wasn’t anything.

Also, what is “a test environment access” and how could I provide one?

Thanks.

For whatever reason, making those changes allowed me to proceed to the main login page using NFW-WP+ with brute force enabled under PHP 8.0. IOW, taking NFW out of the problem as a variable – thus revealing a garden of others not NFW related.

But that resolves this thread. Thanks again.

I tweaked my wp-config file as you suggested and used this option from above

[BEGIN PHP 8.0, NFW-WP+ w/brute force protection active]

https://www.example.com = only blank white space

[END PHP 8.0, NFW-WP+ w/brute force protection active]

attempting to log in to test.

The debug.log implicated another plugin with a specific problem on a specific line. I disabled that plugin entirely, cleared my browser, and attempted to login again. The results were the same – just a blank white page after the initial brute force screen – but there were also no changes in the debug log. I deleted the log, cleared everything again, and repeated the process, but I could never get the debug log to recreate itself.

But it happens that my host runs a standing PP log of their own which dates back years. The most recent entries, repeated since at least early March – that is, predating my attempt to change from PHP 7.4 to 8.0 – include these

[BEGIN]

[31-Mar-2021 04:31:24 America/Los_Angeles] PHP Fatal error: Uncaught Error: Undefined constant “GEOIP_STANDARD” in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php:577
Stack trace:
#0 /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php(285): nfw_is_asn(‘a:39:{i:0;s:7:”…’)
#1 /home/name/example.com/wp-content/nfwlog/ninjafirewall.php(7): include_once(‘/home/name/a…’)
#2 {main}
thrown in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php on line 577
[31-Mar-2021 04:32:23 America/Los_Angeles] PHP Fatal error: Uncaught Error: Undefined constant “GEOIP_STANDARD” in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php:577
Stack trace:
#0 /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php(285): nfw_is_asn(‘a:39:{i:0;s:7:”…’)
#1 /home/name/example.com/wp-content/nfwlog/ninjafirewall.php(7): include_once(‘/home/name/a…’)
#2 {main}
thrown in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php on line 577
[31-Mar-2021 04:32:34 America/Los_Angeles] PHP Fatal error: Uncaught Error: Undefined constant “GEOIP_STANDARD” in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php:577
Stack trace:
#0 /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php(285): nfw_is_asn(‘a:39:{i:0;s:7:”…’)
#1 /home/name/example.com/wp-content/nfwlog/ninjafirewall.php(7): include_once(‘/home/name/a…’)
#2 {main}
thrown in /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php on line 577

[END]

which may or may not have anything to do with anything but which I’m offering just so you’ll know.

At this point I think I’m just going to bide my time and continue with PHP 7.4. My only real reason for upgrading was to see if I could wring out a little more site speed.

This superior firewall plugin continues to perform flawlessly for me under 7.4, the PHP log above notwithstanding, and I may try to repeat the debug process again to see if I can unearth anything else.

Unless you can think of any other reason why NFW-W+ doesn’t or can’t hand off to the login page from its brute force page under PHP 8.0, with or without that reauth query string which has now become a constant, at this point I think I’m best served just making a strategic retreat back into the status quo.

Thanks for your help, and if I turn up the solution, I’ll be sure to update this reply.

Thanks for the quick response. Selective redactions have obviously been made below.

The directive path:

<IfModule mod_env.c>
SetEnv PHPRC /home/name/php/phprc/7.4/phprc
</IfModule>

or

<IfModule mod_env.c>
SetEnv PHPRC /home/name/php/phprc/8.0/phprc
</IfModule>

Various wp-check.php returns:

[BEGIN PHP 7.4, NFW-WP+ w/brute force protection active]

NinjaFirewall (WP edition) troubleshooter
HTTP server : Apache
PHP version : 7.4.15
PHP SAPI : CGI-FCGI

auto_prepend_file : /home/name/example.com/wp-content/nfwlog/ninjafirewall.php
Loader’s path to firewall : /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php
wp-config.php : found in /home/name/wp-config.php

[END PHP 7.4, NFW-WP+ w/brute force protection active]

[BEGIN PHP 8.0, NFW-WP+ w/brute force protection active]

https://www.example.com = only blank white space

[END PHP 8.0, NFW-WP+ w/brute force protection active]

[BEGIN PHP 8.0, with NFW-WP+ entirely disabled]

NinjaFirewall (WP edition) troubleshooter
HTTP server : Apache
PHP version : 8.0.2
PHP SAPI : CGI-FCGI

auto_prepend_file : /home/name/example.com/wp-content/nfwlog/ninjafirewall.php
Loader’s path to firewall : The loader does not exist: /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php
wp-config.php : found in /home/name/wp-config.php

[END PHP 8.0, with NFW-WP+ entirely disabled]

[BEGIN PHP 8.0, with NFW-WP+ itself active but w/brute force only disabled]

When accessing https://www.example.com alone:

“There has been a critical error on this website.

Learn more about troubleshooting WordPress.”

When accessing https://www.example.com/wp-check.php

NinjaFirewall (WP edition) troubleshooter
HTTP server : Apache
PHP version : 8.0.2
PHP SAPI : CGI-FCGI

auto_prepend_file : /home/name/example.com/wp-content/nfwlog/ninjafirewall.php
Loader’s path to firewall : /home/name/example.com/wp-content/plugins/nfwplus/lib/firewall.php
wp-config.php : found in /home/name/wp-config.php

[END PHP 8.0, with NFW-WP+ itself active but w/brute force only disabled]

Yeah, I just found it.

Thanks, Lester, great plugin.

My bad; I should have updated this.

The problem I was describing is actually a function of the WordPress core, not Jetpack: if the discussion option is implemented, any Author is emailed the IP of any commenter on his post, including any other Authors, Editors, Admins, etc. The core option does not segregate Admins from Editors, Authors, etc. when emailing notifications of comments containing post ID data.

I’ve also tested and confirmed this and now implemented a method to stopgap it, at least in my case.

Thanks.

No, I didn’t check, but I will. What about PHP cached as HTML (in a typical WP configuration using a caching plugin)? Will NFW block both? The former, but not the latter?

Oh; I set the permissions myself. Just to check, I ran them from 640 up to 660, to no effect. In any event, were permissions to be the problem none of the other tweaks I’ve made to that file would be readable.

This isn’t on the file anywhere is it?
define( 'EMPTY_TRASH_DAYS', 0)

No.

Beats me also why there isn’t anything else out there I’ve been able to discover on anyone else having this sort of problem.