Code smell

Immobile code

Code is immobile when parts of the code that could have been useful in another place can’t be reused because it’s tangled up in some other part of the code.

Rigid code

Cascading changes. Code is rigid when it’s difficult to change because a small change in one place triggers the need for another change in a seemingly unrelated place of the code. The more cascading changes that occurs and the more modules or classes that get affected, the more rigid the code.

A typical example in PHP is when a code in several places refers to array elements by their numerical index, assuming that the array will always have the same fixed number of elements. If some code is changed so that the array is constructed differently, any statement that refers to a numerical element in the array might break. A change in one place leads to a lot of changes in other places.

Note that code can be both fragile and rigid at the same time.

Fragile code

Code is fragile when a small change in one place causes the several other parts of the system to stop fail. Fragile code tends to be difficult to change without introducing lots of new bugs. As soon as one bug is fixed, a slew of new and conceptually unrelated bugs appear. An common cause of fragile code is when it makes can be that the code makes assumptions about the time zone in a way

Note that code can be both fragile and rigid at the same time.


WP Bootstrap 0.4.0, now a wp-cli sub command

Dr Martens - spring edition


So, as this post is written, the test suite for WP Bootstrap 0.4.0 all turned green and a new version is about to get tagged and available via composer. This release is a big one. If you’re the least bit interested in managing WordPress in a proper deployment workflow, I think you should continue reading.


Tighter wp-cli integration

This is the first release of WP Bootstrap that is entirely intended to be used as a wp-cli sub command. That means that instead of using WP Bootstrap as a stand alone command (or via composer scripts), all WP Bootstrap actions are now sub commands of wp-cli. Where we’d previously would have typed:

$ composer wp-setup

We’ll now be typing

$ wp bootstrap setup

That might seem as a very small change and on the surface I admit it is. But underneath the hood it has meant a lot of changes like replacing almost all external calls to wp-cli via exec() to using the internal wp-cli methods. Since wp-cli comes with functions for logging, output formatting and most importantly, internal functions for running other wp-cli commands, a lot of code has been cleaned up and Monolog  as well as Phpleague CLImate was replaced with corresponding wp-cli functionality. Last but not least, WP Bootstrap now uses Pimple for dependency management because it’s one of the few with the same PHP version requirements as wp-cli itself.

Settings files with dotenv and Yaml

Previous versions of WP Bootstrap has used json files for both application and local settings. Since json is not really that suitable for configuration files they are now gone.

Environment specific settings was previously kept in localsettings.json but are now replaced with dotenv files. Most DevOps engineers are familiar with dotenv files and several provisioning and deployment systems has support for working with them. So one of the benefits of switching formats is that more engineers will recognize them. WP Bootstraps uses Vance Lucas implementation of dotenv which enables a very elegant way of overloading values from several dotenv files. By defining that we’re working in environment ‘test’, we can have WP Bootstrap first load values from the base .env file and if it exists, overlay with values picked up from .env-test.

A bigger change is that appsettings.json is now replace with appsettings.yml. The format is pretty much still the same and converting an old appsettings.json can be done in seconds using a service like JSON to YAML Online. The main benefit of switching to Yaml is that Yaml allows comments. For a configuration file that keeps on growing this is surprisingly important. Just like dotenv, Yaml files are already quite popular among a lot of DevOps engineers, probably because Ansible uses them. And the fact that wp-cli itself relies on Yaml made the decision quite easy.

Feature upgrades

There are a few new features, some of them technically saw the light of day earlier than 0.4.0 but haven’t been previously announced (besides in the change log):


Yes, WP Bootstrap now supports having extensions that can react to actions and filters. An extension is just a PHP class that implements the method ‘init’. In the init-method the extension can hook up to a few filters and actions. The PHP class can be loaded using Composer auto loading or it can exist as part of a theme or plugin. WP Bootstrap just needs to know the name of the class and you just need to make sure it implements the init-method.

The use case for this is to provide a way to perform extra processing during export and import. For instance, we’ve written a WooCommerce extension that handles import and export of the custom database tables that WooCommerces adds to a WordPress install. I expect to find the time to write blog posts on this topic really soon because it opens up a whole lot of new use cases for WP Bootstrap.

Plugin dependencies

Another important new feature is the ability to define dependencies between plugins and themes. Some plugins (mostly) simply will not install correctly or at all unless some other plugin or theme is already in place. To mitigate this, WP Bootstrap now allows you to define which other themes or plugins that needs to exist before this one gets installed.


When importing lots of media files, WP Bootstrap would always regenerate all thumbnails. When dealing with hundreds or even thousands of images, this becomes very time consuming. WP Bootstrap now checks if an updated image was actually changed before generating the thumbnails again. In a similar way, in the setup phase, WP Bootstrap would try to reinstall plugins even if they were already installed. While wp-cli would refuse to do the actual work, the plugin file would be downloaded from the repo on every attempt which costs a lot of time.

Removed features

Since WP Bootstrap is now just a wp-cli command, there’s no real need for keeping the upgrade commands for themes and plugins anymore. For command line management of plugin versions, you are better of using the standard wp-cli commands instead.

Test coverage

Refactoring tests and using with WP_Mock

Code quality is still one of the most important aspects of WP Bootstrap development, so a lot of time was spent on refactoring code and making sure code coverage remains high. Tests are now divided into unit tests and functional tests. Unit tests uses WP_Mock and manages to get up to about 50% code coverage without even needing a proper WordPress installation or a database. It should be possible to reach near 100% coverage for the unit tests, but we’re not quite there yet.

The other half of testing is made using functional tests. The functional tests requires a WordPress installation to work. Generally, the functional tests are easier to write but they are also much slower to run. Some tests are also impossible to get code coverage measurements from. As of the 0.4.0 release, functional tests covers roughly 66% of the code base but the overlap with the unit tests are quite high. Together unit tests and functional tests covers about 82%. That’s actually down a little bit compared to version 0.3.0 and that’s obviously an area to focus on going forward.


All test cases are still kept in a separate github repo just for testing. If you want to contribute to WP Bootstrap, this is where I recommend you start looking. Any contributions to WP Bootstrap are more than welcome, you can just send a pull request or better, shoot me an email first at:


WP Bootstrap 0.3.1 released

Lots of spare time over the holidays means a lot of work can go into WP Bootstrap. Version 0.3.1 brings a few bug fixes and small but nice new feature

Version 0.3.0 had support for working with taxonomy terms that are named after a post id. That was a nice feature, but it turns out that the import process had to run twice for the import to work properly due to a PHP type conversion problem. The export of special taxonomies was enhanced with a WARNING message in the logs if the configuration isn’t correct.

The new feature is wp-cli related. Runnit the wp-init command generates localsettings and appsettings unless they already exist. In 0.3.1, it also creates a wp-cli.yml file that defines the path to the WordPress installation. The condition is that localsettings.json exists and that the wppath parameter in it is different from the default “[wppath]” value. So run wp-init once to get a template localsettings file and edit it. Run wp-init again to get a wp-cli.ym file.

The benefit of defining the path to WordPress in a .yml file is to reduce typing when running commands.