Sometimes it feels like the Internet is growing faster than the universe is expanding. During the global COVID pandemic, businesses that had never even considered how to operate online were forced into the digital world to survive. More than ever, hobbyists, bloggers, and solo entrepreneurs are creating websites to compete for attention in a noisy world.
With this proliferation of new websites, it may be an opportune time to ask, "Are our content management systems actually serving these ever-expanding needs?" Maybe they're not. It often seems like CMS platforms have been busy chasing trends rather than focusing on solving the problems of specific types of users. This is especially true in the open source world.
In this post, we will look at the origins of modern content management systems, their technical challenges, and their evolutions. The post will conclude by exploring what CMS platforms might be able to do to better serve their users in the future.
Many of the major open source content management systems were built in the early 2000s. The digital landscape looked very different than it does today. Easy-to-use visual website builders like Squarespace hadn't yet become household names. Social media hadn't yet gained its foothold.
If you wanted to share your ideas online, installing a PHP website builder on shared hosting might be the most practical option. Countless open source projects like b2/cafelog empowered non-technical users to build personal blogs. As b2/cafelog evolved into WordPress, it transformed into a full-blown content management solution with a theming system, plugins, custom post types, a REST API, and visual page builder.
WordPress's expanding feature set led to increased developer adoption. Yet many of the features that made platforms like WordPress practical for non-technical users became major pain points for developers. UI-driven plugin updates could break websites. Configuration that was stored in the database made it hard to keep development and production environments in sync. Custom fields–most often implemented with the Advanced Custom Fields plugin–had UI-driven configuration that also must somehow be kept in sync between production and live sites.
WordPress was designed to empower non-technical users to manage a website almost entirely through the UI on a single, stateful server. The inexpensive virtual private servers of today didn't exist when it was released in 2003. Nor did object storage or affordable managed databases. Continuous delivery pipelines weren't in the psyche of developers–after all, Git wouldn't even be invented for another 3 years. Because of this, the UI-driven configuration paradigm is at the heart of WordPress. It often must be carefully sidestepped when using the CMS to build heavily customized sites.
Having so many features built into WordPress can create a heavy mental burden for non-technical site administrators who manage hyper-customized sites. WordPress's menu builder was built before mega-menus became a design standard. Sure: it's possible to download a mega menu plugin, but this often creates confusion for administrators who have 30+ items on their admin sidebar and multiple screens to configure menus. Custom themes often use custom queries in their templates that have the number of results hardcoded, which can create a confusing experience when a site admin tries to change the "Blog pages show at most" setting. Changing the permalink settings can wipe out a site's SEO and break every link to the site. Many of these sharp edges can't be removed from WordPress.
Other built-in features come with considerable security risks and potential to leak sensitive data. While it's possible to password protect a post, the title of the post may still show up in the search results. I've seen newsworthy information accidentally exposed in the titles of protected posts. A knee-jerk solution would be to make sure that there are no search boxes on the site, but you can search a WordPress site by tacking
?s to the end of a site's domain (like
https://example.com/?s). A site admin may think that their identity is protected because their author information isn't displayed on a single post page template. However, it can still be displayed on the archive page, RSS feed, or in the REST API. Leaked author information has the potential to cost the lives of activists who post anonymously in oppressive countries. Yet most users are unaware that their content management system is leaking so much data.
Some developers were determined to keep the headless CMS dream alive and concocted "the JAMstack," a methodology for building websites where all of the pages are pre-rendered to HTML. JAMstack frameworks like Gatsby.js could pull all of a site's content using a CMS's REST API, then pre-render every page as an HTML file. While this is an interesting approach that improves initial page load times, it meant that any change to a site would need to trigger a rebuild that could take several minutes. Ultimately, the JAMstack failed to gain the adoption necessary to realize the dream of headless content management systems.
WordPress has long had third-party plugins that enabled page-builder capabilities, but the WordPress team decided to bring the functionality into the platform's core. They built a page builder called Gutenburg.
Years after Gutenberg's release, its success has been mixed at best. The page builder doesn't show what the actual page will look like: it's a rough approximation. Once a component has been added to the page, its template can't be changed programmatically because its markup is generated on the client then saved to the database. Server-rendered blocks that enable programmatic markup changes are possible, but they're strongly discouraged by the Gutenberg team. The blessed path for building your own custom blocks is using React JS, which is a dramatic departure from the way that most WordPress sites are developed.
After revisiting the past decade of content management, it seems like the best course of action for open source CMS platforms may have been to simply focus on bringing their platforms up-to-date with modern development practices.
That's exactly what Drupal did for its version 8 release. Drupal replaced its legacy procedural code with object-oriented code, and it replaced many of its core components with components from the Symfony framework. It began implementing modern package management with Composer. The hope was that by leveraging tools from the greater software development ecosystem, it could reduce the amount of Drupal specific knowledge needed to build websites and encourage more developers to adopt the CMS.
As you may have expected, the results were mixed. Drupal's Symfony components added complexity beyond what many developers were willing to tolerate to build content-driven websites. Many important Drupal packages took years to migrate their code from Drupal 7 to Drupal 8. Updates to Drupal were split between the UI and PHP's package manager, forcing admins to upgrade in two places. Many organizations chose to rebuild their Drupal sites in WordPress rather than incur the cost of the upgrade to Drupal 8.
In his address to DrupalCon North America 2021, Drupal creator Dries Buytaert reflected on the history of Drupal and why users originally fell in love with the CMS. As he asked the community, he found a common thread: people fell in love with Drupal because it empowered less technical site builders to do ambitious things through the UI. He recognized that while Drupal's modernization efforts brought significant advantages, they disempowered the platform's less technical users.
Content management systems are in a peculiar place. Open source platforms like WordPress are still compelling options for individual users to make a blog or build a small website. But as custom development platforms, they tend to suffer from enormous complexity. The causes of this are numerous: ranging from legacy procedural code to usage of dense modern frameworks. It can be caused by build steps and distributed architecture. It can be caused by an administrative interface that lets non-technical users break their site with the click of a button. It can be caused by an impedance mismatch between what the tool was built to accomplish and what users actually want to accomplish with it.
Proprietary systems like Webflow and Squarespace offer a much simpler and more administrator-friendly experience, but it comes at the cost of lock-in and a limited ability to add custom functionality.
The root of the problem may be that we have too few tools that are trying to be too many things to too many people.
WordPress currently powers 43% of the sites on the Internet. These include Fortune 500 company websites, local restaurant sites, and health food blogs. The people building these sites include top-tier development teams, freelance developers, designers who drag-and-drop sites together, and bloggers who don't even know they can change the theme. It's hard to imagine that this single content management system could be perfectly ideal for all of these types of sites, much less all of the types of people who build them. Drupal and others have also had the same struggle of providing the best experience to all of their different types of users.
If the problem is that content management systems are trying to be too many things to too many people, the solution may be to disentangle them from this responsibility. We can do this by building more CMS platforms that cater to more narrow use cases. Webflow has done a great job of this by creating a visual content management system that caters almost exclusively to designers. I'd like to see simple CMS platforms geared towards the design illiterate, and others geared towards non-technical bloggers. I'd like to see content management systems that allow configuration to be committed to code and have a better ability to opt-in to features instead of forcing developers to opt-out. There's more work to be done here.
Today, people building websites have more focused needs than general purpose platforms are able to support. Years of effort was wasted experimenting with modern architectures that may have unnecessarily complicated the development process. But there is enormous potential. If developers can focus that same engineering effort into building platforms that solve narrower sets of problems for specific types of users, the future of content management will be brighter than it's ever been.