Fun with WP-CLI

I’ve started to replace manual interventions after a code deploy with scripted interventions that Bamboo can run for me.

While getting this figured out, there have been a few things with wp-cli that were confounding and there seem to be some limitations to the documentation, so I am going to record those things here. For posterity.

First problem: the version of php-cli that we routinely use is not all that up to date. As in, 4.3. This is the default when we call php on the command line and I wasn’t in a position to get it updated quickly so I needed to point wp-cli to another php-cli build.

After some fiddling and reading of the shell script wrapper for wp-cli, I realized that it looks for an environment var if you want to override your default php. So before running any wp-cli commands, I now run…

export WP_CLI_PHP=/path-to-current/php-cli;

My first task was to pull a big lump of settings out of the sitemeta table for one WP instance and insert it into the sitemeta table for another instance.

Because both are multisite, for each site I pass:

Because I am working with separate installs, I pass --path=[file system path to wp]. This was my next problem. The documentation has the path in backticks. I tried it in backticks; I tried it in backticks again because I am obstinate/crazy. I tried it in single quotes. Possibly I tried it in double quotes. I tried different variations on the path, since I have WP core in its own directory. I gave up in frustration.

The next day I accidentally typed it in bare. And it worked! And you do have to point to your install of WP core, not just to the root of the project, of WP is in its own directory.

And to be clear, despite what the doc says, it should be:


This particular task requires nesting a wp-cli command within another. The syntax is pretty straightforward, however, I got errors that I didn’t understand when I ran it, specifically:

too many positional arguments

After some searching I finally turned up a similar issue with a CLI interface to something completely different – not WP-CLI. The solution was, duh, quotes.

On Linux I found that double quotes around the nested command did the trick, like:

"$(wp network meta get])"

This worked beautifully! Except that it completely broke the plugin that the settings were for. Whups.

What I realized was that the command:

wp network meta get

helpfully returns an array. So rather than serialized data, I had shoved an array into the sitemeta table of the receiving instance.

This was a bit of a headscratcher. Googling turned up nothing. At first I assumed that WP-CLI was unserializing the data in a excess of helpfulness. After searching through the WP-CLI source I realized that WP core was probably returning the array, WP-CLI was just passing it along because, duh again, it’s just an interface to WP core. Self, remember that.

I can’t remember what I was googling when I ran across the --format= flag. It wasn’t specifically listed in the docs for the wp network meta get|update commands but it seemed to be supported on a lot of similar commands. The only documented value for this flag is json. I tried a few variations on serialized but got an array every time. So I just set the flag to json for both incoming and outgoing and booyah!

So here is the final, rather lengthy, hard-won command:

wp network meta update 1 megamenu_themes 
   "$(wp network meta get 1 megamenu_themes --path=/mysite_stage/wp/ --format=json)"