wp-cli

Upgrading old WXR files with wp-cli

Leave a comment

I recently had cause to try to import an old WordPress WXR export file into a more recent version of WordPress. There are some simple differences in the way the old files and the new files are formatted that keep this from working. The usual rigamarole for getting around this is to install a throwaway copy of the version of WordPress that the export file was generated with, import the file, and upgrade WordPress until you’re at the latest version. Then you export and the WXR is updated. That’s kind of painful and lame, though.

So, riding the wave of my recent fervor for wp-cli, I made a wp-cli command for doing the conversion. It’s called… convert-wxr.

Usage looks like this:

wp-cli --file=file-to-covert.wxr --outfile=converted-file.wxr

If you don’t specify an outfile, it just spews to the screen (you can redirect output to a file). It won’t clobber an existing file.

The script just does some simple regular expression and string replacements based on the differences I found between older and more recent WXR files. It’s entirely possible I missed some differences, but the conversions I tested seem to work well enough.

Using xdebug with wp-cli

Leave a comment

Sometimes when you want to profile something in WordPress using xdebug, it’s not quite as straightforward as just enabling the tool in php.ini and passing a query string parameter. Say for example that you’re wanting to test how expensive it is to delete a term in WordPress. Well, you can load the term page with the query string parameter in place, but then you still wind up posting data without the query string parameter. You have a few options that I know of:

  1. Turn on xdebug for every request and figure out which cachegrind file contains the bits you actually want to profile.
  2. Hack the code to add the query string to your post.
  3. Write a cookie that xdebug can use in place of the query string variable.

None of these options especially appeal to me. They just seem clumsy.

I’ve used wp-cli more and more lately to interact with WordPress installs. And of course wp-cli has commands for interacting with terms. So it’d be neat to be able to profile wp-cli commands using xdebug. Luckily, it turns out to be pretty easy to do.

First, get xdebug and wp-cli set up. Links above will point you to documentation for doing so. When I set xdebug up, the extension was added to apache’s php config but not to the cli version of php.ini, so I had to copy the relevant line (extension=/path/to/xdebug.so) from one php.ini to the other.

Now you just have to add the -dxdebug.profiler_enable=1 option to your call to php at the command line. With wp-cli, you’re not calling php directly at the command line, though, so you have to figure out how to get the option passed through to the actual call. It turns out that the bash script that wraps wp-cli has a handy argument named $WP_CLI_PHP_ARGS that you can use to pass php arguments.

So if you always want to use xdebug with wp-cli, you can just do something like this in your .bash_profile:

export WP_CLI_PHP_ARGS=-dxdebug.profiler_enable=1

But maybe you don’t always want to profile wp-cli. Doing so slows operations down a little, and it generates pretty big cachegrind files, especially for complex or long-running operations (for example, a simple wp term delete command that takes around 2 seconds was generating 5MB cachegrind files for me). To run xdebug with wp-cli only when I really wanted to and without having to remember to set or unset $WP_CLI_PHP_ARGS when I wanted to toggle, I just added these lines to my .bash_profile:


alias wp="export WP_CLI_PHP_ARGS=; $HOME/.wp-cli/bin/wp"
alias wpd="export WP_CLI_PHP_ARGS=-dxdebug.profiler_enable=1; $HOME/.wp-cli/bin/wp"

Now, if I want to generate cachegrind files to profile, I execute wpd instead of wp, and life is good.