By getting started, I mean really just getting started. I’m just going to show you how to get WP-CLI running. I think once you do, you’ll take off on your own.
If your local development environment is on VVV, then stop reading, you’ve already got WP-CLI installed!
Here’s a summary of what we’re going to do:
- Download the application
- Make it executable from the command line
- Move and rename it
- In case of XAMPP (or MAMP), add its binary directory to PATH (need to make sure XAMPP’s php is used, and not your machine’s)
Yes, the instructions for installing WP-CLI can be found on its site, but sometimes I just like to reiterate and expand.
WP-CLI is a command line tool, so presumably you already have some familiarity with Terminal, or your command line application of choice. Go ahead and open that up.
I’m going to install this on my local machine, but you could just as easily do this on a web server.
First, we need to download the application. WP-CLI is available as phar file, that is, a php archive – all of the files needed bundled into one easy to manage file. You may also clone the git repo if you wish, but I’m not covering that here.
Go to the releases page and grab the link to the latest phar file. Or,
https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar should always be the latest stable package.
You can use
wget to download it (sure, you could just click the button, but where’s the command line love?).
curl -L https://github.com/the-url > wp-cli.phar
wget -O wp-cli.phar https://github.com/the-url
With curl, you might get an “SSL certificate problem” warning, in which case just add the -k flag.
curl -L -k https://github.com/the-url > wp-cli.phar
I have intentionally not included the valid URLs. You should go grab the url for the most recent version instead of whatever was current when I wrote this, especially in case the files have moved.
To test, we can run a simple command (from the same directory where we’ve just downloaded wp-cli.phar),
php wp-cli.phar --info. You should get output like this
PHP binary: /usr/bin/php PHP version: 5.4.17 php.ini used: WP-CLI root dir: phar://wp-cli.phar WP-CLI global config: WP-CLI project config: WP-CLI version: 0.14.0
If you get nothing, the phar was not downloaded correctly – try that again.
Of course, we don’t want to constantly preface the command with ‘php’ so let’s make it executable.
chmod +x wp-cli.phar
Now if you’d like, you can try
Move and rename
Still could be better. Now we’ll rename it to a nice short ‘wp’ and move it so it’s available from anywhere, not just the current directory.
mv wp-cli.phar /usr/bin/wp
At this point, you may be told permission denied. Just run
sudo !! to rerun the last command as sudo, and enter your password.
Time for more testing. Without changing directories, run
wp --info. You should be getting that same info we got earlier. Good job!
But now we have to to do the real test. In Terminal, navigate to the root of your local WordPress install. In my case, I’m running XAMPP, and WordPress is installed in a subdirectory called stable, so
Now let’s see if we can get a list of the available WP-CLI commands. Run
wp help. If you get a list, kudos, you can skip the next little section. But if you’re like me, you might be getting some HTML indicating a database connection error. Fear not, we shall conquer this.
Basically what’s happening is the wrong php is being used when running the command. We need to add the binaries provided by *AMP to PATH. To do this, we’re going to edit the
.bash_profile file located in your home directory.
You could use
nano ~/.bash_profile or
vi ~/.bash_profile, but I like Sublime Text, so I use
open ~/.bash_profile -a "Sublime Text" (actually, I have a shortcut for that in my .bash_profile:
alias st='open -a "Sublime Text.app"' so I can just use
something something command line love shut up
So what we need to do is check if *AMP’s bin path is already in PATH, and if not, prepend it. If the *AMP path is not listed first, the wrong php will continue to be used.
## # WP-CLI / XAMPP compat ## echo $PATH | grep -q -s "/Applications/XAMPP/xamppfiles/bin" if [ $? -eq 1 ] ; then export XAMPP_PATH=/Applications/XAMPP/xamppfiles/bin export PATH="$XAMPP_PATH:$PATH" fi
We do the if check otherwise that the XAMPP path is prepended every time you source the bash file. Speaking of, we need to do that:
Check that this worked by echoing PATH in the Terminal
echo $PATH. Hopefully you now have something like
Note: If not using XAMPP, or possibly a different version of XAMPP, your path may be different, and you may need to poke around a bit. For example, MAMP’s may look like this
Okay, okay, okay
At this point, we’ve downloaded, made it executable, moved and renamed it, and possible even modified our PATH.
In your WordPress install’s root, you should be able to run
wp help and get a list of available commands.
To get help on a specific command, use
wp help [command], for example,
wp help post, and then even
wp help post create.
Enjoy! Have fun!
If you need a birds-eye view of what’s going on, here’s a
* In the screencast, I don’t add the *AMP path the way I should. Fortunately, I think it’s unlikely anyone will copy that when there’s a nice copy-pasta snippet above. 🙂
23 thoughts on “Getting Started with WP-CLI”
Hi there, thanks for this. The wp-cli site needs this documented somewhere I reckon 😉
All the best!
Thanks for your tutorial.
I’m using MAMP and am trying to get this working:
However, on step 3 (the line bash bin/install-wp-tests.sh wordpress_test root ” localhost latest) I get
bin/install-wp-tests.sh: line 73: mysqladmin: command not found
I already tried several things, such as using
/Applications/MAMP/tmp/mysql/mysql.sockinstead of localhost, but I’ve not been able yet to get this working.
Any idea what might be the issue?
MAMP is organized a little differently, so it looks like you’ll need to add another path to your PATH.
Using the guide above, add
/Applications/MAMP/Library/binto your path. After that’s added, you should be able to run
which mysqladminand see it reference your MAMP install’s bin folder.
Thanks for the tutorial!
I’m a bit stuck. I’ve followed it, but it didn’t work 🙁 I’m using XAMPP too. I undid all the changes specified in the tutorial and checked my $PATH.
It’s the following: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
I wonder if it affects it somehow, that changes from the tutorial didn’t work.
I’d hugely appreciate any help.
My recommendation would be to double-check that you followed the steps under *AMP Compat. Summarily: add the XAMPP bin path by editing your bash_profile, re-source the bash_profile, echo $PATH to make sure
/Applications/XAMPP/xamppfiles/binis there and first.
Do you know if these instructions have changed since you writing this?
I can get this step:
mv wp-cli.phar /usr/bin/wp
and I can see the file in there, but
wp –info won’t work.
I get -bash: wp: command not found
If I follow the instructions on the wp-cli.org site, I get this error:
mv: rename wp-cli.phar to /usr/local/bin/wp: No such file or directory
/usr/bin/wp --infowork? Alternatively, there was an issue posted on github recently that has a some similarity, maybe it’s the same.
Managing multiple WordPress websites is a hectic job, as you have to logging to each site and setup/install plugins and settings for each site independently.
Luckily for those well versed to work in command line, they can use WP-CLI to manage multiple WordPress sites with just a few commands. WP-CLI comes with built-in commands specific just to manage WordPress websites.
Through WP-CLI you can install, manage plugins and themes. Control settings such as cron-job, comments etc.
Learn a few basic commands here: http://www.cloudways.com/blog/how-to-use-wp-cli/
Nice post. We are trying with wp-cli. But it is behaving quite weirdly. Don’t know why this is happening.
wp help plugin -> lists all subcommands
wp plugin list -> returns nothing. Though I’ve couple of plugins installed, but not activated.
wp plugin install -> does nothing
We must be missing something. Any hints will be really appreciated.
Thank you for this!!
I am using XAMPP on a Windows box and am wondering if I could at all follow these instructions of if they are purely for OSX/Unix/Linux systems? Would like to be able to use WP-CLI with XAMPP running Windows 7 as OS, if possible. Thank you for any help or pointer or links to how to get this done on a Win box.
OK, I see the CHMOD command so that means this is for OSX/Unix/Linux system since file permission are handled differently on Windows systems, though I am confident I can apply your tut to Windows with a few bits and bobs changed.
Unfortunately, I’m not familiar enough with Windows systems these days to know which bits and bobs need to be adjusted.
I hope you can work it out!
Hi Kailey, thanks for the tutorial. Unfortuantely, it doesn’t work for me. When using the command [wp core update], I always run into an error message that tells me my WP installation can not be found.
I suppose this has to do with the different folder name of my WP installation, which is “public” instead of “wordpress”.
So, any chance I can nevertheless update the WP core?
I am running NGINX as my webserver and while I can update my plugins from my WP backend, I can’t update the WP core. This is why I tried to use a command line tool.
I am more familiar with Drupal and could update my Drupal core via shell with a drush command. Somehow I hoped it would be that easy with WP, too, unfortunately it isn’t.
Another way to update the Drupal core, is to simply replace all core files/directories manually (via sftp), while you keep the ./sites folder. After that you only have to update the db and that’s it.
Does this solution work in WP, too?
I really have no idea how I elsewise could update my WP installation in Nginx?!
I’d be glad for any advise. Thx!
hi,I have installed wp-cli at Centos7
then made it executable and renamed as your tutorial
But when I run the command “wp –info”
It shows the message ” YIKES! It looks like you’re running this as root. You probably meant to run this as the user that your WordPress install exists under.”
But why I haven’t seen anybody even mentioned this ?
Hi Kailey, I just visited your website, because I hoped to meanwhile find a solution/an answer for my above mentioned problem.
Unfortunately, you haven’t found it necessary to reply to my question, so I will give myself the answer.
I have done a little more recherche on the problem and I can answer with yes, it is possible to simply replace all core files/directories manually (via sftp), while you keep the ./wp-content folder and the wp-config.php.
After a final database update, the WordPress core is updated again. No need to use a command line tool.
Simply upload all folders of the new WP version (expect for wp-content folder and wp-config.php) and replace the old files and folders. Afterwards the WP core is up-to-date again.
you should check something like this out for the path. in the example above, you’ve hard coded the PHP version into the path.
I kept trying to move the file to `/usr/bin/wp` but continuously got the error `mv: rename wp-cli.phar to /usr/bin/wp: Operation not permitted`
So, after following the [link to the GitHub Issue](https://github.com/wp-cli/wp-cli/issues/1330) you posted in the comments, I tried moving the file to `/usr/local/bin/wp` and it worked. Just in case anyone else gets stuck on that step.
My local development environment is on vvv but nevertheless ‘wp’ only leads to
-bash: wp: command not found
php wp-cli.phar –info leads to
Could not open input file: wp-cli.phar
and searching for wp-cli.phar finds:
What’s wrong here? I don’t understand what’s going on.
Hope this helps someone. After downloading wp-cli.phar and moving it, I was getting “wp: command not found”.
Turns out, that the installation step that says ”
$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /usr/local/bin/wp
“, the second step is suppose to be renaming the wp-cli.phar to wp.
So in the end, you have /usr/local/bin/ and the new file name is wp which is the executable.
>>the second step is suppose to be renaming the wp-cli.phar to wp
That was exactly what was wrong. Once I renamed the file to wp, it worked.