WP-CLI for Development

If you are not familiar with the WordPress Command Line (WP-CLI) you should really check it out. There are a lot of uses for it, and I think some of it’s power comes in the form of what it can do for you when you are developing a website locally. While there are a number of plugins that can also do the same thing, they don’t offer the flexibility the command line offers and you still have to install, manage, and then remove the plugins later.

Generating Content to Use

When you are working on a blog roll, list of user profiles, or any other feature that rely on have a lot of content to make sure it is styled correctly, the CLI is here to help. There are several commands that come in handy for creating on the fly content.


For example, say you need to generate 100 users:

wp user generate --count="100"

This will create one hundred subscribers. You can also assign them to a specific role instead by using the –role flag.

wp user generate --count="100" --role="administrator"

To show your new list of users all you need to do is enter:

wp user list

Screen Shot 2015-12-17 at 11.44.16 AM


Another command that I have found particularly helpful is for generating posts. Just like with the user command, you can specify a lot of information, just looking at the full command list you can get an idea for how powerful it is.

wp post generate [--count=<number>] [--post_type=<type>] [--post_status=<status>] [--post_author=<login>] [--post_date=<yyyy-mm-dd>] [--post_content] [--max_depth=<number>]

There are quite a bit of parameters here, besides the obvious count, post date, and status, you can also set the post type (page if you need a page) and max_depth which is the number of child posts you need to make as well. You can generate 5 generic posts by simply providing a value for the count flag:

wp post generate --count="5"

In addition to automatically creating numerous posts, you can also create them using a file. This can be extremely useful if you have the content you need for the pages and want a quick way to populate them, or if you simply have boilerplate ipsum text you’d like to use.

wp post create [<file>] [--<field>=<value>] [--edit] [--porcelain]

As you can see there are only a few base commands for creating a post however, you actually have the ability to do far more complex interactions. You’ll notice the field flag, here you can enter associative arguments that correspond to their parameters in wp_insert_post(). For example you can use –post_title to set the title of the post.

For me the most interesting thing that you can do with post create is supply it with a file to fill in the content. I’ve only began using this to input the content but someone with far more skill could probably integrate this into a function to pull content from a source like Google Docs.

In this example I created a plain text file on my desktop and feed it to the function, creating a new post in the process.

wp post create /Users/lukepettway/desktop/ipsum.txt --post_title="A Post From A File"

This will create a post with the title A Post From A File and use the ipsum text in that file to fill up the content. Pretty flipping cool right? Listing out your posts is as easy as typing in:

wp post list

Screen Shot 2015-12-17 at 11.44.06 AM


One of the things I constantly find myself having to do when working on sites is regenerating thumbnails. Whenever you add a new image size you typically want to do this, there are plugins that handle it as well as programmatic ways to do it as well. WP_CLI provides a quick way to do this:

wp media regenerate

You will be prompted to confirm the command and then it will execute (use the –yes flag to bypass the confirmation). A list of changed files will show you what has changed.


Aside from regenerating thumbnails you can also import files too, it works similar to how you use a file to populate a post:

wp media import /Users/lukepettway/desktop/ipsum.txt


Hey it worked! This isn’t really any faster than dragging a file to upload to WordPress but again, that is where the scripting power of the command line can come in really handy, you could easily feed in boilerplate files without having to log into the admin.


Another super handy dandy command you might want to use are the plugin commands. You have the ability to update, delete, install, activate, and deactivate.

Deleting a plugin is as simple as typing in the name

wp plugin uninstall hello-dolly


Sorry Matt! Now that we feel bad about uninstalling it, all we have to do to make up for this tragedy is run the install command.

wp plugin install hello-dolly


Things are now how they were before. But what if we are using a plugin that isn’t in the WordPress plugin repo? No worries because we can specify a url or file from a path:

wp plugin install ../path/to/zipfile/awesome-plugin.zip


One of the biggest annoyances of working with any database is making a backup. It’s not hard, but it’s a lot of clicks to do something so simple yet so important. With the command line, you can create backups in a snap:

wp db export

This will create a database dump at the root of your site. For anyone working locally, you might need to add the path of your mysql bin in terminal (on AMPPS I did this export PATH=$PATH:/Applications/AMPPS/mysql/bin). One of the most powerful features, while not part of the db command, is search-replace. Just by the name you can probably guess what it does. It is a rather jam-packed command:

wp search-replace <old> <new> [<table>...] [--network] [--skip-columns=<columns>] [--dry-run] [--precise] [--recurse-objects] [--all-tables-with-prefix] [--all-tables] [--verbose] [--regex]

The biggest use you are going to have with this is when you need to migrate a database. Most of us are probably used to doing a SQL query in phpMyAdmin to update our sites which isn’t really so good of a practice. There are times when data is serialized or in weird tables, and sometimes those queries don’t always get everything. Search-Replace can manage to get all of that data safely and update it. It is pretty straightforward too:

wp search-replace 'http://mylocalsite.dev' 'http://mylivesite.com' --skip-columns=guid

By default, this is only going to run on core tables, however there are two flags, –all-tables-with-prefix and –all-tables, which specify whether to run on all tables in the database with or without a prefix.

Community Commands

The commands that I have covered are the ones that come stock with WP_CLI, there is actually a whole community dedicated to writing all sorts of awesome things, and you can even extend it yourself. Some of the notable additions include super-cache for managing W3 Total Cache, acf for working with Advanced Custom Fields, and any-ipsum a content ipsum generator.


There are a lot of uses for the WP-CLI, especially when it comes to working on a site locally. While some of these commands may offer more utility than others, a lot of the power lies within scripting these beyond their default usage. Sure some local dev setups especially those using VVV with VV to auto-install can import your plugins during the build process, for the rest of us not using those environments, we can right simple scripts to pull in frequently used plugins directly from our computers or on a file server.

Why VVV as an Intro to the Command Line Might Be A Mistake

A Heated Topic

Recently I was given the opportunity to attend WordCamp US which was the first national WordCamp. One of the topics that kept popping up was working locally and people would ask recommendations and you would hear all sorts of answers. It seemed like VVV (Varying Vagrant Vagrants) came up a lot but was also met with concerns about complexity, overhead, ease of use, etc.

As someone who has been an advocate for working locally for years and has always been the first person everywhere I have worked to push the initiative and make it happen, I think that we might be making a huge mistake by trying to push VVV as the only option or at least the best option. There are many options out there such as MAMP, AMPPS, XAMPP, DesktopServer, or even setting up your computer itself to serve the files.

So Many Dependencies

My primary argument against starting off with VVV when someone is completely new to anything with the command line is that it has such a huge overhead. What I mean by that is the average user who is simply trying to build a small website locally has to install Virtual Box, VVV, Homebrew, and then VV to really get the most of what they are going to need. That is a lot of stuff to simply install a WordPress site locally and then work on it.  In addition to all the dependencies you still have to rely on the command line to operate the server, set up new installs, reboot everything etc.

But Having to Use the Command Line For Everything Is Good, Right?

Well, yes and no really. Sure we could make the argument that this is a great learning opportunity for everyone because they HAVE to use the command line to do every little thing but we forget in our infinite wisdom that this is a horrible way to teach someone. Can you imagine if when you were in school you were taught addition, multiplication, subtraction, all at a once and then tested on it? Most people would have a hard time keeping up and that is where the real issue lies. When someone is learning git for the first time, they shouldn’t have to worry about what Vagrant Up does, or how to create a new site through terminal, they should be learning about add, commit, push, pull, and all the other important commands.

If I tried to get my coworkers to use VVV while learning Git, Gulp/Grunt, SASS they would definitely tie me up to one of the support beams in our glorious office and use me as a human dart board. Many of us make these recommendations without thinking about the hurdles we overcame, we understand things but only because we have worked through many trials and errors long forgotten.  A few years ago when I was showing a coworker how to use a theme boilerplate that uses node, grunt, and SASS we ran into an issue where we kept getting errors when compiling. After some digging it turned out that there was an issue with node-sass and the newest version of node that was out at the time. Needless to say he was frustrated and quite frankly didn’t even want to touch the theme anymore. Luckily I was able to get him squared away and I haven’t encountered any issues like that anymore.

What I learned from that experience was that even under the best circumstances, there are so many unknown variables that can make even the simplest of tasks profoundly harder and without the experience or knowledge to troubleshoot the issue some people will simply give up and move on thinking that the tool itself is broken.

Less Is More

When it comes to teaching it is better to stay as focused on one task or as few tasks as possible. The more steps you add increases cognitive load and makes it harder for someone to memorize and understand exactly what they are doing and why. Someone learning git for the first time already has their mind full of what commands they should be using, and should be focused more on how to manage their commits and deployments, not worrying about why their VM won’t boot.

By lowering the barrier of entry and making it easier for someone to focus on a smaller set of instructions we also limit Imposter Syndrome. It can be devastatingly discouraging when someone can’t grasp concept A because concept B isn’t working properly, for example their dev environment isn’t loading correctly.  Just like in the example I gave with that theme, you can’t make a really smart person feel completely useless by giving them too much to take on.

Use Whatever Works Best For You

Start off with what works best for you even if it isn’t the best tool out there. More importantly don’t knock people down for using MAMP or other similar tools. I’ve used AMPPS for a while now, and if it weren’t for it I couldn’t have gotten convinced the rest of the team or several friends to work locally. With all that being said, Vagrant is really really awesome. You can create blueprints (with VV) to install whatever theme you develop with, install plugins, create fake content. the list goes on and on. So use Vagrant if you want or use MAMP.  As long as you can get up and running to get started with the tools that really matter such as Git then that is all that matters.