So if you happen to follow me on GitHub you know that I juggle a lot of projects. So you may wonder why so many? Well some projects are just handy little one offs while others are interconnected ideas like a finely woven mesh. It is these latter projects that keep me going. I have been building and extending bacon framework for a number of years. It started out as a simple concept born out of my time at Etsy where I overhauled their WordPress multisite and beat it into submission. It is also where I became intimately familiar with mu-plugins and in essence where bacon was born al be it a very different concept at the time.
Recently I built a new plugin Virtual Ads.txt and based it upon the bacon framework. However I wanted to ensure that if the user already had the framework properly installed as a mu-plugin (suite) then this new plugin would simple utilize the installed version and if the user was not tech savvy enough to manipulate mu-plugins, why should they suffer? Therefore I built the new plugin with and bacon autoloader.
In my experience coding for so many years, when you start working on something it’s hard to not get drawn into multiple directions. To maintain focus I keep a notebook and as I think of tangent I write them down. Over time I return to the resource and start marching in the new direction.
Fast forward to the present day I have been hacking away on dummy a project who’s sole purpose is to make defining your WordPress site as simple as forking or branching the repository and setting your options in a composer manifest. Unfortunately this in turn lead to the immediate development of yet another two projects the WordPress Configurator and it’s support system config installer. By now you’re wonder why such complexity?
It boils down to choice.
When I started dummy it was simple have a repo to hold the composer manifest that defines a WordPress install and then I could create a branch for each site/installation so that I could keep the manifests separate. That lead to the problem of how do I maintain a site/installation through it’s ENTIRE development life cycle. Thus WordPress Configurator was born.
The concept is simple use Apache’s vhost config to tell PHP what environment the installation belongs to. This keeps the code base simple and clean but now you need a was of adjusting WordPress to adapt to each environment’s settings. So during the build of this system I played with and ruled out many possibilities ultimately landing on a solution that I feel actually enhances WordPress. a configuration object built such that you can override default class constants thanks to LSB keeping the subsequent child configs light and easy to troubleshoot. In addition this object is now a persistent part of the installation meaning you can read setting quickly in your plugin code. Why would anyone want to do that you say?
Environmental distinction
What I mean by this is now that I have a consist object in ALL environments I am able to write things plugins that have super advanced feature. I have a noindexer plugin that knows when it is not on prod and ads noindex, follow to the entire site. So you could achieve similar with the ‘Search Engine Visibility’ in settings but if you resync you prod database to an environment your staging or dev environment and forget to recheck that box you’ll know in a few weeks when Google drops your site rankings for duplicate content.
Yet another example DFP ads are expensive and you don’t want them displaying ‘real’ ads in staging or dev environments. Thanks to this simple config object my DFP ads plugin checks the value of a single constant if it’s set one way production ads are display otherwise test creative is shown, saving money and ensuring 100% ad fill. The latter makes QA & UAT infinitely easier because there are no empty ad slots on the page.
While there are a number of other methods to achieve the same many of them involve costly URL parsing and analysis procedures. I personally prefer a direct top down approach. In the coming articles I shall write moxre about this philosophy.