At eighteen73 the majority of our websites run on WordPress. It’s our favoured platform in most situations but here we want to discuss how we approach WordPress development a little differently to most.
Background
Usually, setting up a WordPress website involves downloading the software, unzipping it to a web server, then managing plugins and themes online. However that brings big limitations in a professional workflow where there might be multiple developers collaborating on a project. It’s all too easy for people to step on each others toes and potentially undo someone else’s good work.
Here we take that exact same WordPress framework but adapt it to fit into a modern PHP workflow that includes version control and support for Composer package management; essentially elevating WordPress into a framework that fits more modern and collaborative programming practices.
Benefits
Composer for Dependency Management
Not every piece of functionality needs to be (or should be) written by ourselves when there are good existing solutions. By using Composer we can ensure that any 3rd party code added to the website is untampered with, work exactly as it’s developers intended, and has all it’s dependencies in place.
Aside from being a convenient way to load WordPress and it’s plugins, having Composer at the core of the website also makes it far more practical to include code (whether first or third party) that is not WordPress-specific. There are many generic PHP packages that we use as part of WordPress development and it would be inefficient and dangerous to maintain each of them manually.
By having Composer take on responsibility for package updates (including plugins) we are preventing major updates from being applied to websites until our developers have had a chance to test them in place. Prior to that, all developers and the live website itself should run on the same tested version. If there’s a situation where we need to permanently stick to a specific version of a plugin (e.g. to prevent a breaking change from being introduced in the CMS) we can tell Composer to lock it and other developers can’t unwittingly update it.
The result of all this is improved stability and security.
Nebula Framework
WordPress, as supplied, is not made for Composer by default and it has a few other inherent limitations that we overcome with our own flavour of it called “Nebula”.
Nebula is an open source project at github.com/eighteen73/nebula which is heavily inspired by the well known Bedrock platform but makes it more suited to our style of development and in some ways has a lighter touch on WordPress’ native behaviour. It essentially makes a Composer-compatible version of WordPress so we can have all the advantages outlined above.
In a professional workflow a website might run in any of a number of different environments (e.g. local, staging, live) and WordPress doesn’t really have any concept of this so Nebula adds environment-specific configuration allowing, for example, a developer to see extra debug messages and CMS options when working locally but are automatically disabled in the live/public environment. Having much of the configuration in dedicated environment settings also means we can properly version-control WordPress’ wp-config.php file and stop other things from arbitrarily writing to it.
Nebula also moves the website’s public directory down one level from the project root, which is such an important security requirement for us. There are many reasons why a website project might want to include files and code that should never be web-accessible but that’s not possible in a regular WordPress website so ensure there’s always a safe area for those files to exist.
Git Workflow
The need for version control in a modern development team has been a baseline requirement for years now. At a stretch, generic WordPress websites could be placed inside a Git repository but it proves to be quite impractical because the repository becomes so bloated by large plugins and unless the Git workflow travels all the way to deployment it quickly becomes out of sync with what’s on the server.
Our Nebula platform is designed for a Git workflow and helps multiple developers collaborate on work, create branches for new/experimental ideas, and review or rollback code as we see fit. Having Composer in the mix also means the repositories can be 100MB’s smaller by avoiding the need to include all the third party packages directly in our saved codebase.
Furthermore, we use Git to streamline code deployments and can run CI/CD operations on our Git server to validate all the code that’s added by our development team.
Adding Our Own Theme
Pulsar Theme
Like all WordPress developers we’ve tried and tested so many themes over the years. The bespoke nature of our work means themes rarely have the flexibility we want or they are unnecessarily over-encumbered by complicated CMS-based customisation tools where we’re rather do something in code. As we and WordPress move more towards their modern editing experience we saw other themes falling behind so we invested in our own theme called “Pulsar”.
Pulsar is an open source project at github.com/eighteen73/pulsar and is an advanced and highly flexible theme for experienced developers who want to get the most out of WordPress’ most modern page editor and not be hamstrung by predetermined layout ideas. We use this on every new website so our team quickly gets to know it inside out and jumping between different projects feels familiar.
The theme takes on modern PHP coding styles, even where they might differ slightly from WordPress’ more legacy formatting. We think this is important for us to work more efficiently in the theme, with it being the main area of code that we have our hands on.
Future Proofing
While we do adapt WordPress quite heavily for the good reasons laid out above, not every developer can work this way and we have a belief that we should never lock anyone using our services forever. So in case a website ever leaves us, or they want to host on a service like WP Engine, we have not made such fundamental alterations that the website cannot be converted into a basic WordPress website. Essentially it only requires moving a few directories around and placing config into the default wp-config.php file. Conversely, when we take on existing websites we prefer to convert them into our Nebula setup because it’s such a quick task and it saves us so much time and effort as the project moves forward.
Nothing we do happens in secret, all decisions are fed into our publicly available open source projects where anyone is welcome to see how we work, make suggestions, and even take our code and make it their own. Our constant evolution is visible there and as WordPress itself changes, so will those projects. We use them for every WordPress build here so there’s no likelihood of them falling into disrepair any time soon!
Conclusion
The processes that we’ve outlined here illustrate how our team of WordPress developers work collaboratively and in a technical way that distinguish us from many other WordPress agencies that might not have the development experience/knowledge to dive so deep into the platform. While some people lacking the right knowledge might see these things as an extra layer of complexity in front of WordPress, every decision is in the interest of producing work more efficiently and ending up with more reliable websites.
If you are interested to learn more about our WordPress work please look out for other articles on this website and check out our GitHub repositories at github.com/eighteen73.