WordPress management the right way

I first wrote about Wp-bootstrap in a post a few weeks ago and now it’s time for an update.

New version 0.2.2

Version 0.2.2 that was released today is actually quite a release. In this version, Wp-bootstrap is now feature complete to the extent that everything I described in my book, WordPress DevOps is now possible to do using Wp-bootstrap. This means that a bunch of Grunt scripts that quite honestly grew to be fairly complex can be replaced with a well formed, easy to read json file instead. I can’t tell you how nice that feels.

Quality ASSURANCE

I’ve got a separate repository on Github with the test cases for Wp-bootstrap. For the 0.2.2 release I spent a lot of time making sure to get code coverage up to an acceptable level. The overall coverage is now at 83%, a number I’m quite happy with at the moment. The missing 17% are in a part of the package that I’m considering scrapping and it’s not presented in the documentation, so no one should stumble on the untested code by mistake.

References

The big thing in this release is reference management. When you import options into WordPress using Wp-bootstrap, you might sometimes include a value that is actually a reference to a post ID. The most obvious example is the WordPress option “page_on_front” that stores the page ID for the page that works as the front page of your site. If you are using Wp-bootstrap to import the front page itself, chances are that the ID of that front page will be different between your development and production installations. So if you import the “page_on_front” setting, the integer value in the database will almost certainly be wrong.

Wp-bootstrap can overcome this problem by managing these references for you. Just tell Wp-bootstrap which settings that contains references to a page/post/term. If that item was included in the imported data, Wp-bootstrap will update the database accordingly. This is a very powerful feature and it works across both posts (pages, posts, attachments custom post types) and taxonomy terms (categories, tags etc).

Intended use case

There is an intended use case or workflow that I had in mind developing this package. A quick overview:

On the development server (hint: use Vagrant):

• Start a new project by requiring wp-bootstrap in composer.json
• Run vendor/bin/wpboostrap wp-init-composer to get easier access to the wp-bootstrap commands
• Create a localsettings.json and appsettings.json
• Make sure you exclude localsettings.json from source code control
• Initiate the development installation with commands composer wp-install and composer wp-setup
• As settings are updated, use the WP-CFM interface in WordPress Admin to include the relevant settings into the application configuration
• As plugins and themes are needed, add them to appsettings.json and rerun the wp-setup command to get them installed into your local environment
• As posts and menus are added, include them in appsettings.json.
• When it’s time to deploy to a staging or production environment, run composer wp-exportcommand to get all content serialized to disk. Add them to your Git repo

On the staging or production server:

• Create the local database
• Check out the project from Git
• Create up your localsettings.json file with the relevant passwords and paths.
• Run composer update
• Run vendor/bin/wpboostrap wp-init-composer to get easier access to the wp-bootstrap commands
• Run composer wp-install, composer wp-setup and composer wp-import

Once the target environment has been setup, new changes from the development environment can be pushed by checking out the new changes using Git and rerunning wp-setup and wp-import.

Take it for a spin

Now it’s over to you. If you’re interested in a more structured workflow around WordPress, give Wp-bootstrap a try and let me know what you think in the comments section. Or better, get in touch to let me know how you can contribute to Wp-bootstrap. I’m eager to hear from you.