I’ve been using WordPress for about ten years now. Installing the backend, fiddling with the front-end, making child themes, writing plugins and improving my CSS.
In that time, the editor has gone through a lot of changes. The original Gutenberg editor, the many others in between. The themes get steadily more and more powerful over time.
But at some point you realise you’re in a corner. And this happened a while ago with my wife’s business’ website Thinking Museum. Originally setup in 2014 we went through a few iterations of trying SaaS solutions and nothing really fitted. So a bespoke WordPress setup (originally on Multisite) was created and Thinking Museum had a home.
Add many years of blog posts, integrations, a shop, a successful membership (Woocommerce) and then we’ve almost come full circle. Back to a landing page style of WordPress with external services either embedded or completely hosted outside of WordPress.
The last couple of days I’ve done a major theme update which required a lot of manual copying and creating of content. But the result is going to be cleaner, easier to maintain and upgrade and crucially, not suspectible (or less suspectible) to the whims of theme developers.
What do we learn from this? That when it comes to configurations and customisation – if you stay as close as possible to the default, out-of-the-box configuration, then you’re going to have an easier time upgrading and providing a consistent service for your users.
Simplicity is power. Choose defaults that are closest to your actual needs.
This applies whether you’re a developer for WordPress, or a Product Manager for a FinTech startup, or the DevOps Lead or VP Engineering choosing an IDP or Developer Platform for a successful retail website. Look at your architecture, your tooling, your configuration – and get as close to vanilla as you can.
You’ll thank me when it comes to deployment, upgrade and migration time.