Daily upgrade notification email

[liane]

Quick question: the answer of this request looks a bit strange to me:

https://www.ait-pro.com/vcheck/?bps_version=13.8

it seems to return the version (13.8) and also a full html page just after. There is a good chance that it will confuse the version_compare code in bulletproof-security/includes/functions.php:1833

[AITpro Admin]

There is a delay in receiving the BPS Pro upgrade notifications on the WordPress Plugins page.  That is because WordPress processes calls to their wordpress.org API server first and then BPS Pro can make a call to our ait-pro.com API server.  Unfortunately, that cannot be changed.  Typically just refreshing the WordPress Plugins page 2 or 3 times works.

Hate to sound like a broken record, but keep in mind this problem is only occurring on your website.  I have looked at the BPS Pro upgrade checking functions/code and can’t see anything that could be changed to fix whatever problem is occurring on your specific website.

The vcheck code works perfectly fine for everyone else and there is not a problem with the version_compare code in BPS Pro since that also works perfectly fine for everyone else.

So what I recommend is that you just turn off the additional/extra BPS Pro upgrade check on the S-Monitor page or you can continue to try to figure out the cause of the problem on your specific site by trial and error.  ie enable standard WP Crons and see if things work correctly.  Deactivate any plugins the use crons to send email notifications.  It sounds like you definitely want to keep your custom system cron script instead of using standard WP Crons.  So to me the simplest solution is just to turn off the the additional/extra BPS Pro upgrade check on the S-Monitor page.

[liane]

Ok, took me quite some time, but I finally nailed it down.

If you run this WP-CLI command with simple debug code like echo $bpspro_version:

sudo -u www-data wp cron event run "bpsPro_update_check" --path="/WP/PATH"

you’ll observe that:

1. the file bulletproof-security.php is run and the variable $bpspro_version is loaded with the correct value (13.8)
2. then bpsPro_update_checks() is executed, but the global $bpspro_version is empty at that time

What happens here is that WP_CLI loads WordPress inside a function, so the $bpspro_version variable in bulletproof-security.php is a local variable, not a global one.
https://github.com/wp-cli/wp-cli/issues/2200#issuecomment-155789850

So, the fix is pretty simple: a single line of global defines in bulletproof-security.php makes it compatible with WP_CLI (and perhaps future WP versions):

global $bpspro_plugin, $bpspro_abbr, $bpspro_last_version, $bpspro_version, $bpspro_edition... and so on

[AITpro Admin]

https://stackoverflow.com/questions/13530465/how-to-declare-a-global-variable-in-php

If a variable is declared outside of a function its already in global scope. So there is no need to declare. But from where you calling this variable must have access to this variable. If you are calling from inside a function you have to use global keyword

The $bpspro_version variable used in the BPS Pro update checks function is defined in that function as a global and is located in the bulletproof-security.php file and is already a global variable. There is a way to make that variable a super global, but I am very hesitant to do something like that and would not do that. See the StackOverflow link above.

So in summary I believe what you figured out is that there is a problem with your WP_CLI and/or bash script and what you can probably do is fix the WP_CLI and/or bash script directly somehow. Maybe you can do something like add the BPS Pro $bpspro_version variable in either one of those scripts so that WP_CLI and/or bash script will process the $bpspro_version global variable correctly.  Once again this problem is occurring due to how WP_CLI and/or your bash script is not processing working BPS Pro code correctly.

[liane]

No, please read again my message: your variable is not declared as a global, so when your code is executed in a function, it is not a global.

See the link I mentionned as a reference:

WP-CLI now loads WordPress inside of a function: #2089

Global variables need to be explicitly globalized in order to function as expected in WP-CLI.

There is no problem with the script, it uses WP_CLI as it is meant to, just declare your variables as globals and it works, at least do the test I described.

[AITpro Admin]

Thanks for the GitHub link.  I read several other GitHub posts about WP_CLI also causing these same issues in several other plugins.  I’m sure explicitly using the global keyword in BPS global variables should work fine.  For now I assume you have already edited the bulletproof-security.php global variables and have added the global keyword to those global variables and everything is working ok correct?  If so, then it will probably be a while before a new version of BPS Pro is released with these changes, but you have already found a working solution until a new BPS Pro version is released.

[liane]

Yes, I admit I hacked your code a little, mainly for testing purpose though, so yes, everything is working ok on my side (I just “globalized” $bpspro_version)

It seems that little documented glitch may also cause some trouble in the register_activation_hook, which also looks at $bpspro_version:

https://codex.wordpress.org/Function_Reference/register_activation_hook#A_Note_on_Variable_Scope
https://wordpress.org/support/topic/register_activation_hook-and-global-variables/

[AITpro Admin]

Yep, that function would probably not work correctly with WP_CLI either.  I’m planning on going through all BPS Pro code and explicitly using the global keyword for any variables outside of functions.  I was not aware that WordPress recommends doing that.  Apparently I’m not the only person who was not aware of that.  😉  I almost did that at one point years ago, but thought it would be redundant to explicitly use the global keyword for variables outside of functions since in a non-WordPress environment those variables would be in the global scope.  Everything has worked fine for many years so I did not think there were any issues/problems with that.

[Author]

Posts