Title: Plugin Blocks CLI
Last modified: August 22, 2016

---

# Plugin Blocks CLI

 *  Resolved [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * (@brianbrown)
 * [11 years, 7 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/)
 * Hi Rufus!
    This is a great plugin and I especially thank you for implementing
   the Zero Spam integration! However, are you aware that this plugin prevents php
   scripts within WordPress from being run from the Command Line, either from shall
   or in a crontab? I wondered why my cronjobs quite working so I temporarily set
   them all to use Wget as I thought surely it was something that the webhost did,
   but this morning I confirmed by deactivating the plugin and, sure enough, the
   CLI scripts ran perfectly. Is this by design? I think not. What can be done about
   this and what can I do to help you. P.S.: It would be great if you lifted the
   code from the “official” CloudFlare plugin and incorporated it into your plugin.
   Thanks so much for your hard efforts! -Brian Brown, Ph.D. “Geeking for over 50
   Years!”
 * [https://wordpress.org/plugins/sunny/](https://wordpress.org/plugins/sunny/)

Viewing 7 replies - 1 through 7 (of 7 total)

 *  Plugin Author [Tang Rufus](https://wordpress.org/support/users/tangrufus/)
 * (@tangrufus)
 * [11 years, 7 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395649)
 * 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.
 *  Thread Starter [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * (@brianbrown)
 * [11 years, 7 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395656)
 * 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
 *  Plugin Author [Tang Rufus](https://wordpress.org/support/users/tangrufus/)
 * (@tangrufus)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395856)
 * 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.
 *  [schecteracademicservices](https://wordpress.org/support/users/schecteracademicservices/)
 * (@schecteracademicservices)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395857)
 * This was driving me crazy, and I didn’t realize that sunny was the problem.
 *  Thread Starter [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * (@brianbrown)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395865)
 * 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
 *  Thread Starter [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * (@brianbrown)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395866)
 * 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 http://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
 *  Thread Starter [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * (@brianbrown)
 * [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395871)
 * 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/](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](http://codex.wordpress.org/Forum_Welcome#Signatures)]_

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Plugin Blocks CLI’ is closed to new replies.

 * ![](https://ps.w.org/sunny/assets/icon-256x256.png?rev=1798938)
 * [Sunny](https://wordpress.org/plugins/sunny/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/sunny/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/sunny/)
 * [Active Topics](https://wordpress.org/support/plugin/sunny/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/sunny/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/sunny/reviews/)

## Tags

 * [cli](https://wordpress.org/support/topic-tag/cli/)
 * [cron](https://wordpress.org/support/topic-tag/cron/)

 * 7 replies
 * 3 participants
 * Last reply from: [Brian Brown, Ph.D.](https://wordpress.org/support/users/brianbrown/)
 * Last activity: [11 years, 6 months ago](https://wordpress.org/support/topic/plugin-blocks-cli/#post-5395871)
 * Status: resolved