Have you ever accidentally erased your entire post while drafting content in WordPress? As a WordPress developer with a decade of experience, I’m embarrassed to say that it happened me just the other day. It all started with a tweet from Daring Fireball writer John Gruber.
Gruber asked if anyone used Safari’s “Tab Groups” feature to organize their tabs. As a Safari user and someone who loves experimenting with “productivity enhancement” as a way to procrastinate, I thought messing around with tab groups might help me to deal with the various different hats I wear throughout the day.
Theoretically, separate sets of saved tabs could allow you to mitigate the negative effects of context shifting on your ability to focus. In reality, the feature is so buggy and half-baked that I spent most of my time trying to figure out how to switch between groups and find my open tabs. I eventually had to abandon it, though there’s always a decent probability that I was just using it wrong. At some point, however, I opened the same draft blog post in two separate tab groups- I was editing two separate versions of the same post in WordPress, something that post locking doesn’t actually prevent.
When I was about halfway through writing the article, I saved my draft and closed the tab. Sometime later, I decided to abandon my flirtation with Tab Groups and close everything out once and for all. Somewhere in the tab group labyrinth was another browser with the same draft post. However this older copy only had the first few sentences of content. When I closed the tab with the outdated MasterWP draft in it, it asked me if I wanted to save my changes before closing the tab. Did I click ‘save’ and intentionally erase my own work? All signs point to yes. I saved this much shorter, early draft, overwriting the newer draft in the database and erasing all of my hard work.
If you’re familiar with WordPress, I know what you’re thinking.
What about post revisions?
So we’re big fans of WP Engine. We think it’s a great managed hosting company that has stayed on top of the two most important features: fast, knowledgeable support and powerful developer tools for agencies building lots of websites. They give back to the community by contributing to WordPress itself, employing a ton of great people, and offering their fantastic local development tool for free. Because their pricing is not for the faint of heart, we consider WP Engine a “premium” host, but we usually tell our clients that it’s worth it.
After I erased my own blog post, I spent about two seconds blissfully imagining that I could just hop into my “post revisions”, a feature that has been in WordPress since version 2.6 (14 years!), and bring a previously saved version of my article back from the dead. Cue record scratch: I immediately remembered that WPEngine disables post revisions by default. That means that unless you have already turned them on for your website, there’s no saved history of changes to posts.
In many ways, this makes a lot of sense- post revisions are probably not necessary for most WordPress users, revisions can completely clog up your
wp_posts table, and the post revisions feature is one of many that could use a little attention from WordPress core.
But the fact that they don’t offer an easy way to enable them does have me scratching my head. So I headed over to the support chat to make sure this didn’t happen again. I sent something like “post revisions” to their chatbot to see if it would send me to an article or straight to a team member. Their first response:
As a managed host, WP Engine disables WordPress revisions and does not allow revisions to be enabled in the wp-config.php or php.ini.WP-Engine Automated support response
This reminds me of a similar article we published from Spencer Foreman. He argued that hosts were making it too hard for users to understand and disable the crazy caching mechanisms on their website. It was an example of managed hosting overreach. This felt like a similar situation of a managed host going the extra mile to increase performance, but at the cost of making some core (or plugin) features require an extra trip to the support desk.
Look, I get it- a strong argument could be made that someone with my experience should have known to turn on post revisions or else stop using a live WordPress site to draft articles. I take full credit for that mistake, especially since we’ve been using WP Engine for years. But I never really considered the possibility that I’d accidentally erase my content by saving an older draft cached in my browser (though I’ve since learned I’m not the only person who has done this). But that’s not the shocking climax of this article.
No managing content in your content management system
Before sending me to a support rep who could update that one line of code for me, their automated chatbot continued with some unsolicited life advice:
We recommend using a separate editor to manage content prior to publishing. This protects your site and ensures positive server performance.WP-Engine Automated support response
I’ll admit that this one stumped me. Doesn’t WP Engine think I should be writing my blog posts in WordPress? Nope. WP Engine is telling me that they can’t “ensure positive server performance” while I’m dreaming up blog posts in WordPress.
WordPress is a content management system. More than that, at it’s core, WordPress is blogging software. The number one killer must-have feature of WordPress is writing posts, managing content. With each new round of features hitting the block editor, more and more of WordPress is specifically pointing us towards using the block editor to dream up every single aspect of your site, moving us away from coding locally in PHP and instead towards constant iterative updates in Gutenberg.
Sure, I’ve personally written a few articles complaining about the block editor overall, but the core blogging experience has become quite elegant. For blog posts, it’s so much better than writing in Google Docs, Microsoft Word, or Apple Notes. Are there quirks about the editor that I feel the need to complain about from time to time? Certainly, but most of those exist in the realm of page building and full site editing, pointedly still Beta software. For writing a typical blog post (on a cutting edge laptop computer with ultra high speed internet), the editor actually feels quite amazing.
Is the block editor a performance killer?
So why doesn’t WP Engine think we should be managing our content from inside of WordPress? I can understand their reasoning behind disabling post revisions, but recommending that users don’t manage draft content using WordPress at all seems a little intense. The key word in their response seems to be “performance.”
Now, I’ll admit that I’m a paranoid “Save draft” clicker. I smash that button after every malformed thought leaves my head. Years of training have taught me that its never too soon to hit ‘Save’ just one more time. Its hard enough stringing together a coherent sentence the first time.
Just a quick glance at my network tab shows me that the block editor on a post with no large media assets or embeds clocks in at about 13 MB for the initial page load (though some of that may be due to additional plugins running which, while not unusual, would add a little extra weight). For context, a frontend article on MasterWP with no large media or embedded tweets comes in at 3 MB, much of that probably being served by our CDN at Cloudflare anyway.
So what happens after our bigger initial load? Every fifteen seconds or so the Heartbeat API pings the server, less than half a kilobyte. Then some ‘autosaves’ fire off, not much larger. I finish this sentence and pause for a quick “save draft” which fetches a whopping 2.5 MB, almost the size of a logged out frontend page load, our largest offender yet. And like I said, I’m clicking that button fairly religiously.
To be fair, there’s probably a lot more going on than just network requests. We may also be fairly minimal in our plugin choice, I could probably load up a few client sites and see numbers that run much higher. But it does have me wondering about Full Site Editing.
If editing basic post content in the block editor is a performance concern, what happens when you’re editing the entire theme and layout of your website? If you think my continual ‘Safe draft’ habit sounds bad, you should see me on Full Site Editing: I’m not only clicking ‘Publish’ every few minutes, I then have to go to the frontend of the site and refresh multiple times just to make sure the back and front designs are actually matching (spoiler alert: they’re often not). As we move from building websites locally in code to live from inside WordPress, I have to imagine that we’ll be seeing more, not less, performance issues for hosting companies to deal with.
And as one colleague of mine pointed out, anyone who has spent time in a page builder (especially one that I won’t name but will link to here) knows that many page builders flat out crash when you spend a lot of time editing a big landing page. Without drafts and revisions being saved in Full Site Editing, building a site live on a host becomes a risky proposition. With them- WordPress will need even more power and performance.
The Gutenberg Phase Shift
What comes after Full Site Editing? The next two phases of Gutenberg are collaboration and multilingual. These are features that require more, not less, resources to pull off successfully. And they are some of the coolest features coming to WordPress core.
The collaboration phase may actually work to fix my original problem- if we do see ‘Google Docs’ style live-editing of posts, then theoretically my “outdated” draft wouldn’t have existed- it would be constantly updating itself with the newer version. Then again, that’s a heck of a lot more network requests that even basic content editing. True collaborative document editing requires near-constant saving and refreshing, something that I’m sure Google has been spending years honing their server infrastructure for.
Multilingual will offer another set of performance issues, as Matt Mullenweg mentioned in his last State of the Word. For every piece of content, from block to post, you’re multiplying the amount of data that needs to be generated, managed, stored, and served. It’s hard to imaging that “using a separate editor to manage content prior to publishing” would be an attractive option for large sites handling multilingual content. After all, the point of WordPress is that it’s supposed to make content management better, not harder.
WordPress will always have to put in more effort than any proprietary competitors, primarily because it doesn’t control the hosting environment of every install. While Google or even Squarespace can optimize for modern web features that require more performance, WordPress will always be a victim of backwards compatibility, even on a premium host such as WP Engine. I’ve reached out to WP Engine and I’m hoping they’ll let me know that this was all just a bad dream- that they’re fully on board with my server-stalling block editor addiction.
Because I still haven’t learned my lesson, I’m drafting this post in WordPress- mostly because I just really enjoy writing straight into Gutenberg. If you have a really good app for writing your blog posts, something that can handle code blocks and links and pasting into WordPress without butchering everything, then please let me know (there’s been some awesome suggestions there already). In the meantime, I’m turning revisions on and sticking with WordPress as my one-stop blogging tool.
There’s a common phrase used to describe Apple technology: “it just works.” This is how WordPress should feel. I should feel confident writing in WordPress. I should assume that my progress is being saved, that there’s even some tiny amount of version control or backups, that the whole process is being… managed. If WordPress is going to improve it’s reputation, we need to get on the same page about what the future vision of WordPress is going to be.
We’d love to hear from some hosting companies about their plans for optimizing for Full Site Editing and even more resource-intensive tasks like Gutenberg multilingual and collaboration. We know you hire plenty of developer advocates, so send someone our way to teach us about what you’re doing.