Plugin Blocks CLI

Hi Brain,

At the beginning of the files, I added these lines to prevent Sunny from working directly(without WordPress).

if ( ! defined( 'WPINC' ) ) {
    Die
}

Deleting them should make your CLI script works.

What is the purpose you run the scripts? I will consider delete the lines at the next release.

Thanks for reporting the problem.

Well, I call wp-cron.php from a cronjob (disabled in wp-config) and also an RSS autoposter script. Using Wget adds to the server load, so I prefer not to use it.
Maybe you could add it as an option on/off. But there are a lot of other WordPress plugins that have the facility to use a *nix cronjob and not wp-cron (examples would be: some of the missed schedule plugins; WooCommerce products importer; Automatic Updater, etc.), notwithstanding a scant few who update from the Command Line.
I don’t see why it is necessary to restrict php from accessing the site since it has to be run on the same server and therefore should not require that degree of security unless there is some other rogue script running and, if so, then one has a whole other level of problems (and there are other security plugins to address those issues).
Thanks for your prompt response!
-Brian

The lines are removed since v1.4.14
But, i kept the ones at sunny.php and uninstall.php as a security precaution.

Thanks for making Sunny a better plugin.

This was driving me crazy, and I didn’t realize that sunny was the problem.

Apparently that (above) was not the problem, since it is still doing it (in ver. 1.4.14). Disabling Ban Login with Bad Usernames has no effect. Unticking iThemes Security and Zero Spam has no effect, either. I think it might be with the secuity_check private function, since there is no referer (referrer), but I’m not sure. I will dig into the code (it is some of the most well structured and well documented plugin code I have seen in a long time) and see if I can find the problem.
Curl and Wget work okay, but they have timeout and resource overhead issues.
If I run from shell I get a proper response (Content-type:text/html). For instance:
/path/to/php “$HOME/html/www.example.com/path-to-script.php”
Regards,
-Brian

Update: It may also have something to do with server clustering. I know that in GoDaddy’s Grid Hosting, “locahost” and 127.0.0.1 are handled in a different way; and WHM and cPanel too.
For instance if I enter:

curl https://ipecho.net/plain; echo

from shell, I get a totally different IP address from the server IP address, i.e., xx.xx.113.1 (server IP) returns xx.xx.196.220, so we need to test/whitelist the secondary IP(s).

Something like:
/sbin/ifconfig |grep -B1 "inet addr" |awk '{ if ( $1 == "inet" ) { print $2 } else if ( $2 == "Link" ) { printf "%s:" ,$1 } }' |awk -F: '{ print $1 ": " $3 }'

Which theoretically returns something like;

eth0: 10.20.10.1
eth1: 10.20.1.168
lo: 127.0.0.1

Regards,
-Brian

Yet another update:
Okay. I realized that I had to change to php 5.3 because this plugin has an anonymous function that is not supported in php 5.2, which changed the path to php.
On a Sunny note (pun intended), while experimenting, I created scripts in the public root to call wp-cron.php and the /wp-content/plugins/path/to/plugin-specific/cron/script.php and I named them something like wp-adminrun-cron.php (which simply calls wp-cron.php as an include file. So, if your CloudFlare page rules are set up like we discussed over on Rufus’ site https://wphuman.com/make-cloudflare-supercharge-wordpress-sites/ then wp-cron won’t be touched by ClourFlare at all (which is what you want if you are using Curl or Wget). If you are using the CLI in a real cron job CloudFlare won’t see it anyway.
[ Signature moderated ]