Using WP-CLI on Bluehost

WP-CLI is a powerful tool that can help make common WordPress maintenance tasks easier, especially if you want to automate those tasks using cronjobs in a secure way. Here at Bluehost, we love this tool, and even provide it pre-installed on every hosting account.

There are some gotchas that can confuse even developers that are already familiar with WP-CLI. So I wanted to quickly outline them.

Using the Pre-Installed Command

The official instructions for WP-CLI instruct users to install it as the super short and convenient “wp” command. However, because our shared hosting accounts support multiple versions of PHP including version 5.2, which WP-CLI does not support, we were required to provide a wrapper around this command called “wpcli”. So every time you see instructions for running a WP-CLI command, you must replace “wp” with “wpcli”. This wrapper already knows how to force WP-CLI to always use PHP 5.4 (or later). For example, here’s how to check which themes you have installed:

devbryan@dev-bryanpetty.com [~/public_html]# wpcli theme status
6 installed themes:
  I smallbiz       3.8.6 Lite
  I twentyeleven   1.7
  A twentyfourteen 1.0
  I twentyten      1.6
  I twentythirteen 1.1
  I twentytwelve   1.3

Legend: I = Inactive, A = Active

We rely on this tool ourselves to help provide you higher quality support, but in the interest of security, we’re required to review updates to any tools we install on our servers, so sometimes our version of WP-CLI might not be the latest version available. If you find yourself needing some newer functionality or fixes to bugs within WP-CLI, you might still want to install the latest version on your hosting account yourself…

Installing WP-CLI on your Hosting Account

Since shared hosting does not provide you with root access to the server, the recommended installation instructions provided by WP-CLI won’t work. Instead, we’re going to install WP-CLI as a “user-specific installation”. It is still perfectly possible to install WP-CLI without root access without losing any functionality provided by WP-CLI.

We are still going to download WP-CLI in the recommended way, however, we are going to download it into your ~/bin directory instead:

devbryan@dev-bryanpetty.com [~]# cd bin/
devbryan@dev-bryanpetty.com [~/bin]# curl -L https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar > wp-cli.phar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1075k  100 1075k    0     0  1731k      0 --:--:-- --:--:-- --:--:-- 1798k

And rather than using the “php” command as instructed by WP-CLI, Bluehost accounts are required to explicitly use the “php-cli” command to run PHP in command line mode. So you can check that WP-CLI is working correctly by running this:

devbryan@dev-bryanpetty.com [~/bin]# php-cli wp-cli.phar --info
PHP binary:	/ramdisk/php/54/bin/php54-cli
PHP version:	5.4.24
php.ini used:	/usr/php/54/etc/php.ini
WP-CLI root dir:	phar://wp-cli.phar
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	0.14.0

WP-CLI is actually installed now, however, it’s not very convenient to use still. You don’t want to have to run “php-cli ~/bin/wp-cli.phar” every time you want to run a WP-CLI command, so we’re going to setup an alias for it so you can just run “wp” like you normally would.

To do this, we need to edit our ~/.bashrc file, and add our alias right alongside any other aliases setup for our account. You’ll notice that Bluehost has provided a few basic ones in this file already. We’re just going to add one more, the location in the file isn’t important (but I like to organize all of my aliases in one spot next to each other). Just add the following line to this file:

alias wp='php-cli ~/bin/wp-cli.phar'

Once you save this file, we’re done. You can either log out and SSH back in for this alias to be loaded, or you can run the following command to get it working immediately:

devbryan@dev-bryanpetty.com [~]# source .bashrc

Now we’re in business:

devbryan@dev-bryanpetty.com [~/public_html]# wp plugin list
+--------------------+----------+-----------+---------+
| name               | status   | update    | version |
+--------------------+----------+-----------+---------+
| akismet            | inactive | none      | 2.5.9   |
| better-file-editor | active   | none      | 2.1.2   |
| hello              | inactive | none      | 1.6     |
| jetpack            | active   | available | 2.8     |
+--------------------+----------+-----------+---------+
Advertisements

17 thoughts on “Using WP-CLI on Bluehost

  1. scribu

    Nice write-up.

    Does the php-cli binary check that the file it’s about to run is executable? Otherwise, I don’t get why you say that “we still need to tell the system that our copy of WP-CLI is executable”, since you’re not executing the wp-cli.phar directly.

    Reply
    1. Bryan Petty Post author

      I don’t think it does, I guess it’s actually not really required in this case, but doesn’t hurt either way.

      Reply
  2. Roy Emmerich

    Bryan I have followed your great instructions to the letter but unfortunately it isn’t working.

    Firstly I didn’t have a ~/bin directory so I created one.

    When I run:

    php-cli wp-cli.phar –info

    I end up with no output to the console. I also have a new file ~/bin/error_log which has the following contents:

    [04-Apr-2014 15:16:30] PHP Fatal error: Class ‘Phar’ not found in /home7//bin/wp-cli.phar on line 3

    A bit of searching found the following explanation here (http://tinyurl.com/ogaqjtw):
    ——
    This message means the Phar (“PHP Archive”) extension is not loaded by default on your account. If you receive this message, type the following command instead to load the Phar extension:

    php -d extension=phar.so wp-cli.phar –info
    ——

    So I then ran the following command on my bluehost server:

    php-cli -d extension=phar.so wp-cli.phar –info

    and got an additional error message in ~/bin/error_log:

    PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/phar.so’ – /usr/lib64/php/modules/phar.so: cannot open shared object file: No such file or directory in Unknown on line 0

    which accompanied a repeat of the original error message. A quick search in /usr/lib64/php/modules/ produces the following list of available modules:

    fileinfo.so*
    http.so*
    imagick.so*
    ioncube_loader_lin.so
    magickwand.so*
    mailparse.so*
    memcache.so*
    oauth.so*
    oci8.so*
    timezonedb.so*
    uploadprogress.so*
    ZendOptimizer.so

    Do you have any ideas? Your help in solving this issue would be greatly appreciated.

    Reply
    1. Bryan Petty Post author

      I’d be happy to help track down what might be causing this, but it certainly sounds like the Phar extension isn’t loaded for some reason. We do have it installed on new accounts by default, but maybe php-cli is pointing to the wrong PHP binary for your account somehow, or you might have an older configuration that didn’t enable the Phar extension.

      Just a guess here, but one idea might be running “php54-cli” instead of “php-cli”. Some additional info that might be helpful would be running these commands:

      devbryan@dev-bryanpetty.com [~]# which php-cli
      /usr/php/54/usr/bin/php-cli
      devbryan@dev-bryanpetty.com [~]# php-cli -i | grep phar
      Registered PHP Streams => https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, phar, zip
      Phar-based phar archives => enabled
      Tar-based phar archives => enabled
      ZIP-based phar archives => enabled
      phar.cache_list => no value => no value
      phar.readonly => On => On
      phar.require_hash => On => On
      Reply
  3. Pingback: Copying WordPress Locally - The Injection

  4. Roy Emmerich

    Aaah you’re a life saver! I never would have thought there’d be two instances of php installed?

    [~/bin]# which php-cli
    /usr/bin/php-cli
    [~/bin]# ls -l /usr/bin/php-cli
    lrwxrwxrwx 2 root root 21 19. Mar 09:37 /usr/bin/php-cli -> /ramdisk/bin/php5-cli*
    

    As you pointed out, the other instance of php is located in /usr/php/54/usr/bin/php-cli

    Running

    php-cli -v

    on both instances produces the following output:

    /usr/bin/php-cli -> PHP 5.2.17
    /usr/php/54/usr/bin/php-cli -> PHP 5.4.26
    

    And now for the important bit.

    [~/bin]# /usr/php/54/usr/bin/php-cli wp-cli.phar --info
    PHP binary:	/ramdisk/php/54/bin/php54-cli
    PHP version:	5.4.26
    php.ini used:	/usr/php/54/etc/php.ini
    WP-CLI root dir:	phar://wp-cli.phar
    WP-CLI global config:	
    WP-CLI project config:	
    WP-CLI version:	0.14.1
    
    Reply
    1. Bryan Petty Post author

      Yeah, the servers have multiple versions installed since it’s possible to switch websites between them without migrating your site across servers. Glad to hear you got it figured out, and thanks for pointing it out here too, I guess I have a bit to learn about other configurations myself still too. 🙂

      Reply
  5. Nikola Nikolov

    While trying to install wp-cli on a host, I ran into the issue that running php wp-cli.phar –info wouldn’t output anything.

    After some digging I couldn’t find any clues. In a last effort, I tried running the old shell install script and it brought-up the following message:
    “Some settings on your machine make Composer unable to work properly.
    Make sure that you fix the issues listed below and run this script again:

    The suhosin.executor.include.whitelist setting is incorrect.
    Add the following to the end of your `php.ini` or suhosin.ini (Example path [for Debian]: /etc/php5/cli/conf.d/suhosin.ini):
    suhosin.executor.include.whitelist = phar”

    Now, since I wasn’t able to change the php.ini(there is a php.ini file in my home directory with that exact line at the end of it, but I was still not able to run wp-cli) file, I combined your method of using an alias with the suggestion from the error message.

    My final alias command looks like this(I added-in a memory-limit option, since the default is 16 mb):
    alias wp=’php-cli -d memory_limit=64M -d suhosin.executor.include.whitelist=phar ~/bin/wp-cli.phar’

    And boom – everything works as expected 🙂
    Hope that helps someone out there.

    Reply
  6. Pingback: Copying WordPress Locally | The Injection

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s