This week WordPress and its founder, Matt Mullenweg, got into a conflict with the Managed WordPress hosting company, WP Engine. WP Engine started in 2010 under the helm of Jason Cohen. It currently hosts 200,000 WordPress websites. At the WordPress WCUS 2024 event, Mullenweg called out WP Engine for its ‘lack of contribution’ to the community. WP Engine sent a cease and desist letter over the statements. WordPress sent a cease and desist letter of its own. In their letter on the 23rd, they called for action and a response by October 3rd. On September 25th, Mullenweg blocked access to code updates by all of the WP Engine sites hosted there. In short, WordPress wants 8% of WP Engine’s estimated $400-million/year income for “licensing.” They want $32-million. The WordPress community is in disarray. Some are siding with Mullenweg. Many are questioning if this is the point where WordPress dies. It’s a good question. One person has hobbled 200,000 websites leaving them vulnerable to bugs and exploits. WordPress runs approximately 30 – 40% of the websites on the Internet. If there is a massive shift in how it functions, how one can gain access to updates or how much it costs, they could change. Developers adopt content management systems. Salespeople sell what the developers produce. If WordPress becomes toxic, that adoption trend could reverse. People could start to replace their WordPress websites with alternatives like Squarespace, Laravel, etc..
What if, as some have said, this is The Death of WordPress? Well, first: it won’t be the actual death of the project. People out there are still using janky applications concocted in 1995 and they won’t surrender them. There’s always going to be a million websites using WordPress. Second, people are going to adopt new tools. The trend of simplicity is going to snag many WordPress site owners who have been shaken out of their complacency. They will go to Squarespace, Wix, Weebly, Card and a host of other simple solutions. For many, this will be fine. Honestly, there’s a tier of WordPress sites that were never well served by the excess horsepower of WordPress.
Maybe this is an opportunity.
Where am I coming from? My personal history with content management goes back to the 1990s. I’ve been coding since the Apple ][ days. I was tapped ca. 1996 to build functionality into my websites. I built ecommerce systems from scratch. I built Perl based content management systems. In the 2000s, I built “Daccor” an ASP driven content management company that ran sites like the BC Conservatives website and the CARP BC website. Why didn’t I keep going? Money. I was too poor to do the slog of evangelizing an unknown CMS while building out functionality, roll out new designs, and being a breadwinner. Since 2005 or thereabouts, I have been building custom code for Drupal, WordPress and other projects.
WordPress started as blogging software. It was a fork of the b2/cafelog project by François Planque. Mullenweg and Mike Little forked the code and began building towards what we know as WordPress today. If you look at the b2 code, you can see evolutionary clues of what grew from there. A lot has happened in 21 years.
The Content Management System
Here are my thoughts for what a content management system needs. It’s coloured by my affinities, so what I propose will echo what I like. For the longest time, WordPress’ stack looked like my goto stack, so some of these choices will be familiar.
PHP Based. Love it. Hate it. PHP is very popular and runs almost all of the web servers. PHP8 is economical in its processing. It’s well adopted. The one trend I see that I don’t like: Composer. There are so many applications that ship with the need to go through Composer to get the supporting libraries. That’s great for nerds, but for every nerd rolling out a WordPress website, there are 1000 non-nerds who want to hit [DOWNLOAD] and call it done. Using Composer knee-caps adoption. If a product is going to be popular, it needs to be easy.
When it comes to coding conventions: I spent my first 20 years (1983 – 2003) writing procedural code. Object oriented (OO) code is bolted on as a skill set for me. I found that how WordPress combined OO and procedural code was really attractive. Some developers are so in love with OO code that they miss the heart attack it delivers to the hardware it runs. The code needs to be as lean as possible. Period.
When the considerations are stacked: security, performance, utility: in that order. There are so many bad actors, security has to be the first and foremost considerations. Second, but a close second: the CMS needs to deliver its output quickly. It’s not uncommon to see WordPress sites dawdle for two to three seconds before it gets around to serving its content. What a failure. Third, utility. The user experience has to be good. There needs to be easy templating available to control the look and feel of the admin screens, the front end displays and data directly sent to users.
The code conventions need to be straightforward and orderly. There needs to be a way to filter all of the content and templating easily. I used to write code to track the behaviour of Drupal code to build its output. It would go round and round and round, refactoring and messing with the presentation of the data. That all cooks into server load, performance lags and unpredictable code.
JQuery Based. This is a personal bias. I like JQuery and I dislike React. As WordPress has adopted JQuery, it’s a move I like that I would keep with a new CMS. I would move towards headless, but not full on headless. I have seen web servers have partial failures and their output is immediately lobotomized. I maintain that while search engines can index dynamically built pages that pull in data via Ajax, search engines better index pages where the content is on the page. I like the idea that a page can be saved offline and look intelligible. I don’t like the idea that a web page has to only be viewed on the connected Internet. It flies in the face of using the Internet to publish data in a way that delivers portable content. I like the idea of using Ajax to bring in content for progressive disclosure– to enhance the experience. Maybe having the JavaScript library as a swappable element would be a winning feature. It would let some developers work with React, JQuery or whatever library they choose.
MySQL Based, but flexible. MySQL and MariaDB are workhorses. Going to one server for the true source of data creates a chokepoint. WordPress’ architecture has been good when it comes to its data schema. I used to wince seeing all of the tables that Drupal would spin up; with their complicated and resource intensive db joins; the 500+ tables that would give the MySQL paging system a stroke. WordPress avoided that for the most part. I think they went a little too far and some of the tables are cumbersome and problematic in their own way. Lessons learned from other CMSes:
- Fewer tables is better, to a point.
- Simple queries win– it’s best to pull a lot of records.
- Remember revisions. Every piece of content should have a way to see its history.
- Find a way to warehouse old data to remove it from the active data.
- Build in a way to use DB replication (master-slave relationships) from the outset. Write to main DB, read from the best available child DBs.
- Build in a way to pull in other data sources easily to synthesize a complete picture: remote data, S3 storage, text file content, etc.
- Cache data as much as possible without being its own performance hit.
- Pre-package data as much as data when the data will be commonly called in its packaged form.
HTML5. Embrace it. Use the HTML5 potential and all that it brings. There are powerful shorthand ways to accomplish things nowadays. Make sure all of the HTML conventions work with lean code.
Build with SEO and Performance In Mind. We’re talking about web publishing. It’s not an afterthought to have the page load fast, work well and be discoverable on the web. WordPress will plunk all manner of render blocking Javascript in the header. Don’t do that. Put as much code in the footer and defer as much as possible. Work with what web clients need to create the best output delivered in the best fashion. Build the output to make the time-to-first-byte (TTFB) as short as possible.
Fetch some content routinely at the client. Some of the aspects of a page don’t need to appear immediately. If they’re not indexed by Google it may not be that important. Build in a capacity to easily fetch some content from the CMS or even remote sources of data.
Portable. Portable Portable. Make everything on the site portable. Make it show that content and configs can be backed up, downloaded, moved, frozen or otherwise worked with. With the prospect of use generated content, but the need to promote websites through the development lifecycle there needs to be easy ways to move setting without slamming content.
Reconcile CSS before it gets served out. In my coding, I will see three and four layers or countermanding CSS instructions: WP core, Woo, Divi, some other plugin, then eventually what I introduce to style the output. That’s sloppy. There needs to be a compilation step that sorts out these conflicting and countermanding rules before the styling comes out. If it’s not reconciled, it creates processing load for the web client, and inconsistent user experiences. It needs to be cleaned up before it’s delivered.
Inherit Good Code. In mulling this over, I’ve thought: keep all of the WordPress hooks, lose some of the code. WordPress plugins go beyond hooks. I’ve written many plugins that drill right into the core of WordPress to get the functionality and data I need. This proposed plugin should be poised to make the use of the huge number of WordPress plugins that exist. Because of the deep ties to the WordPress core, I propose this instead: map the hooks (actions and filters) to how the arguments are made with WordPress. Build a conversion system to adapt incoming WordPress plugins to operate in the new CMS. It gives those products additional longevity and it gives the new CMS a library of tools to start with.
The Open Source Project
WordPress’ row with WP Engine has shown off that the organizational shortcomings can jeopardize a project more than bad coding or poor adoption. There needs to be several things in place to proceed successfully.
Make it Open Source. Make it under the GPL2 license to ensure that there won’t be a rug pull later by a petulant player.
Put shared assets under the control of the non-profit. It should be easy to add assets and value. It should be hard to vandalize it; or repeal it. That’s in the core of the Open Source movement, but it’s obvious that people can decide to ignore that. The key holders of these critical elements need to be vetted by the non-profit oversight and then there needs to be a means to hold them accountable to uphold a charter of conduct.
Set up a non-profit. Set up a non-profit that oversees the roadmap. Make it democratic. Given how many anecdotes there are of women and other voices being squelched by less than diplomatic developers and gatekeepers, put governance, safeguards and oversight into the core of the organization, along with a way to deal with people who make the contribution environment toxic. When my staffer and I were listening to a talk by Angela Byron about how they were blockaded by bad actors in the Drupal community, she described their tactics, their language and how they put a chill on participation. Everything she said was valid and I believed all of it, but also: my staffer and I experienced the same thing despite being men. The gatekeeping and anti-social conduct can kill a community. The oversight of the community needs to keep people on good behaviour and it has to watch the watchers with cycles of accountability and democratic interaction.
Set up a means of commercialization. Often founders struggle to get a glimmer of adoption. Then something kicks and the process takes off. Open source is a different beast from commercial software. Software accomplishes work and carries value. When open source does that, often consultants and producers of add-on products reap the rewards. With software, the money comes to those who exploit the technology more so that the person who pioneers the technology. There needs to be an understood means of commercialization that all parties understand. If one company reaps billions while another gets millions, that’s how it goes. Rasmus Lerdorf, the inventor of PHP, is not as wealthy as Mark Zuckerberg the user of PHP who used the technology to build Facebook. It’s impossible to police parties that profit from a successful venture.