For some time now, so-called “PHP artisans” have been falling out of love with WordPress in favour of alternatives. I’m not saying I’m not a fan of new content management systems (CMS) like Craft, but I think there’s still a very clear time and place for WordPress.
WordPress’ underlying codebase has been around for some time, and a vanilla WordPress installation is missing some of the niceties that more recent content management systems have as standard.
However, WordPress powers (as of right now, January 2018) 37% of all content management powered websites, according to Built With. There are a significant number of community and private plugins on the market; many in-house developers tend to start learning WordPress first, and the wider ecosystem of PHP developers who know about WordPress is huge. For me, consulting directly with business owners who do not know how to code, these are some very compelling reasons for remaining with the technology.
To aid in our argument for WordPress development, I’d like to describe our tech stack, which has evolved to be far from vanilla.
We use Roots.io’s Bedrock framework, which pulls in WordPress as a composer dependency. This allows us to have a controlled, sharable staging environment around our team, and comes with niceties like .env support out of the box. There are also other niceties like upgraded security, and a little security by obscurity, too, in the form of non-standard file paths which protect sites from a small number of automated attacks and exploits.
Because of the number of files pulled into the project via public dependencies, the actual file storage requirements for version controlling your work is incredibly small. This means the entire Bedrock directory can be included in version control, ensuring that multiple developers maintain the same plugin and other requirements – something that’s not possible with vanilla WordPress.
Webpack and Laravel Mix
Our preference is to take this a little further by pulling in some Laravel dependencies – namely mix() – so that we can integrate our build process into Webpack JS. This allows us to run all development and live file builds automatically in the terminal window and, crucially, allows us to run the same in our automated deployment and testing environment.
The output here is cache-busting file path names, which sits nicely behind our Cloudfront setup, which I’ve blogged about recently.
There’s an awesome website out there called https://wpackagist.org/, which is effectively a WordPress plugin repository mirror with all plugins factored as dependencies for composer.
It’s WPackagist which brings true version control to your WordPress builds. As they put it, here’s why you should use composer for plugin dependency management:
- Avoid committing plugins and themes into source control.
- Avoid having to use git submodules.
- Manage WordPress and non-WordPress project libraries with the same tools.
- Could eventually be used to manage dependencies between plugins.
Media Cloud by ILAB is a great WordPress plugin/module which enables your media storage to be based on services like Amazon S3 (and others). Although this is a great permanent file store, the added advantage here is the benefits given by the separation of concerns this affords us:
|Computing power||Amazon EC2 (Elastic Compute Cloud)|
|Database storage||Amazon RDS (Relational Database Store)|
|File store||Amazon S3 (Simple Storage Service)|
|Global cache and delivery||Amazon Cloudfront|
This means your application can become scalable as there is no locally required EC2 file or data storage.
Finally, within your theme, with Bedrock and the wealth of other dependencies you can pull in via WPackagist, and others, you have a number of options for replacing the default theme boilerplate.
We have a few preferences within the team, but right now typically websites are rolled out with the twig templating language. You could also easily use Blade or even Liquid if you’re a little more adventurous.
The benefits here are the closer-to-true Model-View-Controller application structure (within the theme directory) and also the faster speed of development it brings. Also, when you have multiple developers sharing a project, standardisation in your approach is key!
Finally, as the entire website has been built as an app with decentralised storage (and we host databases on separate DB servers), this means the deployment of the application/website is compatible with Amazon’s (and others) deployment processes. Although there are other options, we use Amazon OpsWorks through a variety of Chef Recipes we’ve adapted over time.
Well, that’s a brief top-down view of our modern WordPress builds and deployments – what do you use?