WordPress? In 2024? Yes, actually
A lot of people have a lot of opinions on WordPress. It’s a system that has stood the test of time, and has the warts and weird bits to prove it.
In 2024, there are a lot of choices for building a website or web-based system. Most architectures will rely on a CMS to store content, so content editors aren’t required to change content stored in HTML markup. (To non-technical people, markup is scary - understandably so!)
WordPress as a system has existed from the early 2000s. Throughout that lifetime, the key priority for the core maintenance team has been backwards compatibility. The most modern version of WordPress will run on decades old versions of PHP. This is a phenomenal undertaking in itself - what other software can you think of that can say that?
When you view the history of WordPress through that light, a lot of the decisions make sense. You put the codebase in the public directory of a web server, and it runs. The barrier to entry is low. This is a good thing! We should encourage people getting into technology and educate them in a positive and empathetic manner.
A lot of technical folks dislike WordPress because it doesn’t follow modern development practices. This is fine, but it’s not the only thing that matters.
If you want a traditional CMS that feels familiar, WordPress is probably where that sense of familiarity came from. If you like Headless Architecture, WordPress can do that for you too! The bad old days of your entire site getting hacked because of xmlrpc are over. The present day WP REST API is robust and easy to pick up.
Because the WordPress ecosystem is so large, there is probably already a tool in your favourite programming language or frontend JS framework to retrieve data from a WordPress powered backend and display the content without having to think too hard. This is a good thing! It lets you focus on building what matters.
If you want to set up version control for your WordPress install, use modern Composer-based packages, use NPM/Yarn/PNPM/whichever Javascript package manager is cool this week, use a CI/CD pipeline that runs automated tests and deploys to environments automatically, you can do that! If you don’t need that, you don’t need to!
I’ve seen WordPress installs that have no boundaries in the codebases, throw plugins at everything, mix models/views/controllers in one php template file, and commit clean code sins that would make Uncle Bob furious. They’re not fun to work in. They’re not what we should be striving to build as engineers. They also do the job.
I’ve also seen meticulously crafted WordPress installs, that rely on 3 core third-party plugins to operate (ACF Pro, Gravity Forms, and Yoast) and the rest of the functionality is provided by a “bespoke” enterprise architecture, combining a “core” plugin and a “core” theme. Sometimes these codebases are more difficult to work in, but they provide structural support that means maintaining the website in 10 years will be the same experience as it is today.
As developers and technologists, we have a responsibility to non-technical folk to make content management as easy as possible. There are a lot of estimates of WordPress usage on the web, with figures reportedly being between 40% and 65% (depending on your source). Because of this, there is a high probability that the person you’re building the website for has encountered WordPress in the past. This is one less hurdle to jump.
Don’t pick a tech stack because it’s cool, or “modern”, or “hip”, or “the latest thing”. Pick a tech stack that solves the problems you face.
(Perhaps ironically, this website is a headless system - Nuxt and Vue on the frontend and Contentful on the backend. My website is my place to test out new approaches and techniques, and changes more regularly than a website for an organisation would.)