WordPress is great for lowering the barrier to entry for running a professional website, except when making massive design changes on a running system.

The WordPress ecosystem, comprised of plugins, widgets, media, and built-in theme editing make the methods for controlling site design and behavior accessible to everyone capable of filling out web forms. The problem is that using the tools in the ecosystem to control the design of a site involves data entry. And data entry for design requires the time of a human to complete. When the design is data, and the data requires entry by a person, making changes to a live system is a scary endeavor.

There must be a better way to apply a meticulously crafted design and configurations to a WordPress website without taking the risk of making a mess to a live system.

What does the typical design process look like for a WordPress site? For a professional site the design work happens in a development environment, whether on local computers or in a separate domain. The design work involves tinkering with all of the widget settings, theme customizations, styles, media, and plugin configuration to get all of the wrinkles ironed out. When the development environment looks good, then it’s time to pass it along to the production site. But how? Since much of the design work requires entering data through the administrative interface in the browser, the common-sense way to get the design in place involves reproducing all of the steps, all of the configurations, all the myriad settings in all of the screens. But it’s error prone, tedious, and time consuming to duplicate all of those steps. When going to production, that’s not the kind of experience we need! And having an extended maintenance-mode, leaving downtime and unavailability is not the kind of experience the users need!

What about a blue-green deployments (having a duplicate environment [blue] that runs parallel to the actively running environment [green] that traffic can switch to)? That’s ok too, if you can control the flow of data into the system. Remember, the design is in the data. Therefore, the production database needs to be updated. In a blue-green deployment, some kind of load balancer or DNS change routes traffic to one server and allows a switch to happen at a moment’s notice. The design team could have a copy of the production database, then go like mad to enter all of the design configurations on the ‘blue’ system. If any comments are made, posts entered, etc. in the green system during that time, there’s a risk of losing that content, or at a minimum, requires an effort afterwards to copy newly entered data as a final step. This way works well enough when managed with a technical team, But still, reproducing manual design configuration settings is error prone and time consuming. In addition, blue-green deployments take resources – additional servers and load balancing infrastructure. A blue-green deployment strategy can work for applying a complex design configuration to a WordPress site, but it still inefficient.

There’s a better way. With some simple command line statements, the whole process of applying a design to a production system can be automated and much less stressful. The process involves extracting the design configuration data from the development environment, and applying it to the production environment. This allows designers to do their work at design time without worrying too much about keeping track of the steps taken to recreate the design. This also solves the problem of introducing errors in applying manual configurations.

The trick involves using the WordPress command line interface – “wp cli”. This is the tool that allows you to extract configurations and import them. The steps below require that this tool is installed on the production and development servers.

Here are the steps to follow:

1. When making changes to an existing site, make sure your development environment starts with a copy of the production WordPress site. Normally that will happen by copying the production database
2. Do the design work! Change widget configurations, change your plugin settings, etc. There’s one caveat here. The media files you might add that are part of the site design need to be managed very carefully. It’s best if the design of the site doesn’t reference media that only exists in the development environment. If you need to reference uploaded files in the media library, you’ll need to come up with a way to publish that content in your production environment so those files have the same URL path as they do in your development environment. It is best to make sure that your design references static files that are part of the theme or stored in another location outside the “uploads” directory.
3. Export the data containing the design in the development environment. This is where the fun starts. The “options” table is generally the place where data goes for the design configured in the system. This is where widget, theme, and plugin configurations generally go. The process is simple and it can be tested over and over again before applying it in a production environment. And running it takes moments. On the development environment, run this command:

   wp db export options.sql --tables=wp_options

   In the documentation for the “db export” command, you’ll see that the “options.sql” is the file that contains all of the data from the table specified in the “–tables” argument. In this case “wp_options” (the default table name where WordPress stores options).

4. Transfer the “options.sql” file to the production server
5. Run the corresponding import command. But wait! Before you do that, you’ll need to make sure that the same plugins, themes, and any other dependencies of the design in the development environment are installed on the production environment. Normally those changes can happen transparently. And for the daring, the wp-cli can also help to automate that process. When it’s time to apply the design, I encourage turning on the maintenance mode for safety’s sake, and then run this command from the production server.

   wp db import options.sql

   The documentation for the “db import” command shows that the only argument is for the name of the options.sql file.

6. Your configuration settings will probably have a different hostname between the development environment and the production environment. Since your imported options may have also transferred settings with a hostname, you’ll probably need to change that. Fortunately, there’s a command for that too!

   wp search-replace "development.mysite.com" "www.mysite.com" wp_options

   In this command, I’m searching for instances of “development.mysite.com” and replacing them all with “www.mysite.com” in the “wp_options” table

7. Rejoice! in mere moments you applied a design without having to worry about manually reproducing the tedious steps for a design on a live system. If you enabled maintenance mode, don’t forget to turn it off.

As an added bonus, the great thing about following this process is that it can be tested. In a different development environment, you can repeat these steps until everything looks right before going to production.

By following this process all your design deployments to your WordPress sites will be much more stress-free.