The WordPress war over… revisions?
WordPress revisions cannot be the cause of the Matt Mullenweg vs WP Engine war.
Quick note: It’s been a hot minute. Over the past ~2 weeks, I had planned to muse on a few topics, especially the legal filings from both WP Engine and Automattic. However, two weeks ago I was laid off. Going forward, I plan to set aside writing time each week, primarily on this site.
This past Wednesday, at TechCrunch’s Disrupt conference, Matt Mullenweg joined TechCrunch Editor-in-Chief and General Manager, Connie Loizos, for an interview on stage.[1] In my opinion, it’s a reasonably balanced interview, mostly covering his “war” with WP Engine.
At approximately 8:45 in the interview, Loizos leads into her next question (my emphasis):
So, again, just trying to get to the root of, I guess, what’s happening and how it gets resolved. So, you’re frustrated by some of the things that they did, including making the revision history harder to manage. I guess the question is: Was that any of your business to start with?
Loizos’ question references the WordPress.org post from Mullenweg on September 21, 2024, in which he called out WP Engine, stating it’s not WordPress and, as an example, added:
WordPress is a content management system, and the content is sacred. Every change you make to every page, every post, is tracked in a revision system, just like the Wikipedia. This means if you make a mistake, you can always undo it. It also means if you’re trying to figure out why something is on a page, you can see precisely the history and edits that led to it. These revisions are stored in our database.
This is very important, it’s at the core of the user promise of protecting your data, and it’s why WordPress is architected and designed to never lose anything.
WP Engine turns this off. They disable revisions because it costs them more money to store the history of the changes in the database, and they don’t want to spend that to protect your content. It strikes to the very heart of what WordPress does, and they shatter it, the integrity of your content. If you make a mistake, you have no way to get your content back, breaking the core promise of what WordPress does, which is manage and protect your content.
(The post is longer, of course, but the above summarizes Mullenweg’s key argument.)
The day this post was made, WordPress developers worldwide squinted and muttered, “this is certainly an interesting argument, given how WordPress works…”
I don’t have access to WP Engine’s internal systems or, more importantly, the precise must-use plugins (“mu-plugins”) they use on every managed WordPress installation. I also don’t know the mu-plugins that Automattic uses for their WordPress.com and WordPress.com VIP offerings. However, I do have access to public documentation.
Before Mullenweg’s post, I had no idea that WP Engine disabled WordPress revisions. However, it’s well-known within the community that a large WordPress database can cause performance issues. Moreover, it’s widely known that revisions, in particular, contribute significantly to a large database, directly impacting performance. But, don’t take my word for it.
Kinsta, a managed WordPress hosting provider says the following:
The larger your database is, the more storage space it’ll occupy. Unfortunately, this can slow your site down and lead to longer loading times, hampering your site’s user experience and search engine optimization (SEO).
Therefore, it’s critical to learn how to control revisions in WordPress to your advantage.
… before explaining how to disable, delete, and limit revisions in WordPress.
In its documentation about optimizing performance, SiteGround, another managed WordPress hosting provider, states the following:
Over time, these revisions can accumulate, significantly increasing the size of your database. A larger database can slow down your website, as it takes longer for WordPress to retrieve and display data. By limiting or disabling revisions, you keep your database more streamlined and efficient.
… and then explains how to limit and disable revisions in WordPress.
Pantheon, which provides both WordPress and Drupal hosting services, writes the following about WordPress and revisions:
WordPress is a wonderful tool, but there are still a few holes in its architecture.[2] The fact that revisions stack up in your database is one of these holes.
… before providing instructions for, you guessed it, removing and limiting revisions.
Another managed WordPress hosting provide, Pagely, provides the following in its documentation (my emphasis):
Saving all WordPress post revisions forever might sound good on the surface, but the database can quickly become cluttered. Over time, this can become a significant issue if lots of edits are made to site that has been up for a long time or if the site has many authors generating new posts and edits.
By default Pagely has opted to disable revisions unless they are needed by the user.
… yep, that’s right—Pagely, like WP Engine, also disables revisions by default. Is their offering considered “WordPress”?[3]
On the list of recommended WordPress hosts, published on the Mullenweg-owned-and-operated WordPress.org website, sits Hostinger, which writes about fixing “overloaded” WordPress sites:
WordPress saves all revisions by default, making the website database heavier as more revisions are stored.
… before providing instructions on how to limit revisions. They provide additional details and options for limiting or disabling revisions elsewhere, deeming it important enough to publish a second time less than six months later.
Another host recommended by Mullenweg on WordPress.org is DreamHost, which notes in their documentation about optimizing WordPress databases:
WordPress post revisions are historical or autosaved versions of your site's posts. WordPress limits the revision count to 10 by default, but these can expand as your site's post count grows. Use the commands below to clean up revisions in your site's database.
This isn’t actually true. WordPress-the-software does not limit revision count at all[4], so this statement implies that WordPress on DreamHost limits revisions to 10 posts.
Perhaps more interesting is this post from 2023, from Automattic-owned Jetpack, which blogs (my emphasis):
For example, WordPress.com saves 25 revisions for Free, Personal, and Premium plans, and 100 revisions for Business and eCommerce plans.
If you have lots of revisions, they can clog up your database and slow down your site.
You read that right! The Automattic-owned WordPress.com limits revisions.
Even Automattic’s enterprise WordPress.com VIP limits revisions. In a pull request from May 25, 2023, an engineer limited revisions to 100, fewer than the original 500.
Except, wait! That code was commented out by WordPress.com VIP’s Chief Technology Officer Brian Alvey on September 23, 2024,[5] just two days after Mullenweg’s post on WordPress.org about WP Engine.
Around the same time, WordPress.com VIP’s public documentation was also updated. Previously, it read:
By default, VIP environments store the last 100 revisions.
It’s clear now, from statements made by Mullenweg after September 21, and through to the TechCrunch interview, that the underlying issue is not about how WP Engine handles revisions. However, it seems curious that many of the statements from Mullenweg reference how “different” the product that WP Engine provides is from WordPress users download from WordPress.org.
The fact is, every WordPress host modifies WordPress, usually through mu-plugins. Every WordPress host balances performance, features, and cost to ensure they’re providing the right product to its customers. Every business tries to meet the needs of its customers for the best possible price.
Customers, meanwhile, are savvy—they compare offerings, looking primarily at costs and features. If an offering isn’t living up to the demands of the market, businesses can either adjust, or fail. That WP Engine has grown its sales to $400 million per year[6] says that its customers by-and-large like WP Engine’s product—they like the modifications WP Engine has made to WordPress through mu-plugins, paired with the base product WordPress provides. They think it balances well the pricing WP Engine offers, even with its tradeoffs.
So, what does this mean?
When I worked at Automattic, my team oversaw the dreaded “Merge”—the moment in time when the WordPress core software was merged into WordPress.com, combining years of code customizations that make up “WordPress.com” with the community-created codebase that makes up “WordPress.” It wasn’t pretty. The code customizations felt endless, and often conflicted with WordPress core. Certainly, the situation has improved in the intervening years, but I have no doubt that the process is still complex, and custom modifications persist.
In understanding motivations and rationale for this proclaimed “war”, we’ve seen conflicting reports—was the offence “bastardized simulacra,” “trademarks,” “lack of contribution,” or something else entirely?
To take Mullenweg’s argument about “bastardized simulacra” to its logical end, Mullenweg must believe that millions of customers have been wrong all along—they’ve somehow been duped. The product they’re using isn’t WordPress, even though that’s what they’re buying. And, what’s more, the changes WP Engine has made are so bad, so egregious, that virtually every major WordPress host does the exact same thing… including Automattic’s WordPress.com and WordPress.com VIP products, which both limited revisions before Mullenweg’s September 21 blog post, and all heavily modify WordPress through custom code, whether direct or via mu-plugins.
The argument doesn’t hold.
Given this, it should be abundantly clear that, whatever the cause of this war, Mullenweg didn’t suddenly start to oppose WordPress customization—his opposition was purely and solely to WP Engine.
As it so happens, I was in the audience, sitting in the front row, during the interview. I was pleased to see Loizos reference BlackRock’s devaluation of Automattic, something (I believe) I was first to report on. ↩︎
Harsh. Accurate, but harsh. ↩︎
Yes. ↩︎
Revisions haven’t been limited by WordPress core since the feature was introduced in 2008. ↩︎
I am neither an engineer nor a CTO, but I don’t believe it’s best practice to comment out production code like this. With version control, I’d expect an engineer to remove the code entirely, knowing the change can be reverted later, if needed. ↩︎
As reported by Mullenweg, in any case. WP Engine is still a private company. ↩︎
