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 | +--------------------+----------+-----------+---------+
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.
I don’t think it does, I guess it’s actually not really required in this case, but doesn’t hurt either way.
You’re right, this isn’t necessary at all, I’ve removed it for simplicity.
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.
Sorry the path in that first error message should read:
/home7/my_username/bin/wp-cli.phar
I’ve also checked out the phpinfo() for my site and PHP archive support is listed as being enabled.
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:
Pingback: Copying WordPress Locally - The Injection
Aaah you’re a life saver! I never would have thought there’d be two instances of php installed?
As you pointed out, the other instance of php is located in /usr/php/54/usr/bin/php-cli
Running
on both instances produces the following output:
And now for the important bit.
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. 🙂
Thanks for posting this stuff guys, helped me out big time on an old legacy client!
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.
This is now the third time I’ve landed on this post when configuring a client’s site to use wp-cli. Thank You!
Does this work on VPS accounts?
Pingback: Copying WordPress Locally | The Injection
On a shared account, I had to perform the following to get wp-cli to work with WP 4.4:
# create the /bin directory
mkdir bin && cd bin
# download latest wp-cli
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli-nightly.phar
# rename
mv wp-cli-nightly.phar wp-cli.phar
# edit .bashrc
vim .bashrc
# add this line to .bashrc and save :wq
alias wp=’/ramdisk/php/54/bin/php54-cli ~/bin/wp-cli.phar’
The current WP-CLI version should already be available to use on BH servers.
Wonderful beat ! I wish to apprentice even as you amend your web
site, how could i subscribe for a blog website?
The account helped me a applicable deal.
I were tiny bit acquainted of this your broadcast provided vibrant clear concept