Deploying WordPress content changes using WP CLI

The nature of our upcoming site theme refresh provided me with an interesting challenge:

Project requirements

  1. Keep the production site alive and in use during development.
  2. Don’t enforce a content freeze on production during development.
  3. Have a development site available for page building and review.
  4. Provide a mechanism for the development team to be notified about content changes in the production environment.
  5. Only update certain post/page content for pages with given ID numbers.
  6. Manipulate certain post meta fields for specific pages.
  7. Ensure no IDs change or get created during the deployment process.
  8. Deploy changes on launch day to production quickly, en masse, and with minimal staff.

We’ve always had a DEV site, but the trouble we always faced was how we get content from DEV up to PROD once it was ready.  There were a few options, but each had drawbacks:

I decided to see if WP CLI offered the functionality required, and it turns out that it does, and does so beautifully.  In order to be a viable option, WP CLI needed to be able to do the following things:

Having this tool available for our use will be a tremendous benefit for deployment.  Since it works on individual pages and can manipulate post meta keys one-by-one, we can use it to change items in a controlled and predictable manner.  The tool’s popularity and simple, focused design builds my confidence that it will work reliably now during pre-deployment tests as well as under the pressure of launch day in a few weeks from now.

On launch day, the overall process for our migration will be as follows.

The only gotcha here is that any changes made to the page content on PROD during the development phase (1-2 weeks) will not be automatically brought over to DEV.  This is good in some cases (we have a lot of content that we don’t want to synchronize as a part of this migration), but it creates a situation where updated content on PROD would be lost if we imported the DEV content.  Since our site page content is relatively static, we can manually keep track of any page changes and make them manually to DEV during the development phase.

To help notify us of changes to PROD, we run a plugin that emails us with any changes to site page content.  If an editor makes changes to PROD content during the development period we can mirror those changes on DEV.  We have also asked the larger team of site editors to email us if they make any changes so that we can ensure they are synchronized in DEV and not lost during the launch.

In conclusion, I’m happy to report that our migration will be successful and won’t require us to work long hours doing tedious tasks over launch weekend, all thanks to WP CLI.  I’m very grateful that we have a powerful tool like this available at our disposal, and my team is happy they won’t be asked to work during their weekend time off.