As the WordPress 6.1 development cycle comes to a close, we’re beginning to see the shape of the next, and presumably final, release of WordPress in 2022. Some WordPress developer advocates have labeled 2022 the “year of full site editing,” and I assume their expectation was that 6.1 would be the release that finally rips the “beta” bandaid badge off of Full Site Editing. After watching the 6.1 Product Walkthrough, I’m fairly skeptical that we’re looking at a production-ready version of Full Site Editing for anything more serious than a personal blog.
In the upcoming core release, one standout feature is the ability to use block-based template parts (think random chunks of content editable in Gutenberg) anywhere in a classic/hybrid theme (testers welcome). If executed correctly, this has the potential to be a true game-changer for classic themes, something to replace the haphazard use of ‘widgets’ and ‘menus’ that often required more client training than almost anything else. That, of course, assumes that some progress has been made on the navigation block:
Free MasterWP for life if you can tell me what any of those icons mean or where active focus is.
It also assumes that there’ll be some progress towards the front-end ‘Edit’ links becoming a lot more intuitive and helpful, even for classic themes. Sending users off to find “Appearance > Templates” is only marginally better than sending them to the Menus and Widgets screens and is certainly a user experience regression from the Customizer (the thing that actually showed version-controlled live previews of the front-end of your website).
I am optimistic that the new “block-based template parts” (more on names later) will be a major improvement – and an opportunity for classic themes to take further advantage of Gutenberg and potentially have more buy-in into the project. And yet sitting in the audience for Matt Mullenweg’s Chat at WordCamp US last week and reading the comments on Sarah Gooding’s write-up of the feature over at the WP Tavern both left me scratching my head.
I was surprised to see Matt, Sarah and many commenters fall into the same trap that keeps coming up in WordPress conversations today. I’m calling it: The Block-vs-Classic False Binary. (I know that rolls off the tongue beautifully.) Let’s dig in.
The Block-vs-Classic False Binary
Think of “classic” as just, like, a stop-gap. If you’re still building sites with “classic” in 2022, like see how you can maybe minimize that or, or migrate the users, or spend an hour with them to teach them how the new stuff works.
Matt Mullenweg, WCUS 2022
I can understand where Matt is coming from here. Someone actually asked him if they could include the Classic Editor plugin by default in WordPress. It’s important to note that the Classic Editor is already inside core WordPress. The plugin just manages it for you. Another person asked him to commit to maintaining the Classic Editor experience indefinitely (I’m sure they pretty much are. Like I said, it’s in core.). These people are representative of “classic editor” users, but that’s a different crowd than “classic theme” developers.
When Matt spoke, he used the more broad term “classic” fairly loosely to include anyone not fully committed to Gutenberg as a whole. And the distinctions between block themes, block templates, block template parts, block-based template parts, block editors, site editors, full site editors, classic editors, classic themes, Coca-Cola Classic, and all the various terminology was reduced to just: people writing blog posts in the Classic Editor.
Here’s that same false binary in practice, from a comment on the WP Tavern:
As long as I read this kind of discussions, for years now, I’m always wondering:
What is wrong with the classic block?
Telling People to use the classic block if the prefer the classic experience can’t be that much of of an effort.
What point am I missing?
Comment from Ruif on WP Tavern
Prefer the classic experience? Use a classic block. It’s just that simple. Except that it’s not. This was on a blog post about “block-based template parts” – a feature that has absolutely nothing to do with the Classic Editor plugin or writing content in a classic editor. I understand the confusion, however, because you might not catch all of that from the name of the feature. It’s a confusing time of transition in WordPress.
Back to Matt’s WCUS chat. Here’s one interesting statistic that I believe helps us understand his perspective a little bit better:
Half the people coming to wordpress.com are actually blogging and we’re seeing a ton of activity there. One of the things I’m most excited to work on, like, as I mentioned before, we’re switching Tumblr to be WordPress-powered.”
Matt Mullenweg, WCUS 2022
In that context, Full Site Editing as a simple framework for setting up blogs or Tumblr feeds makes a lot of sense. And I’m sure that half of the people coming to WordPress.com are there to blog – because what else can you do there? I’m not sending friends there to set up their e-commerce store or marketing website unless I want to lose their friendship entirely. So I’m just not sure what that statistic is supposed to mean, other than the fact that Matt still sees WordPress’s primary goal as a blogging platform, not the operating system of the web many of us were invested in.
The main question then is whether WordPress will continue to be the correct tool for advanced website development. Is advanced website development just part of the “classic” phase of WordPress, not the future? It’s not unrealistic when the project lead is still unhappy about WordPress’s inclusion of a REST API and cool advanced features like application passwords are still undocumented after two years.
Language Matters
The reality is that many of us don’t want to live forever in the classic experience. We want some of the Gutenberg experience, we want the shiny, new things, too. We want to use the block editor sometimes, but probably can’t use the site editor. This is the huge middle-ground where a lot of developers live: using blocks and the block editor for some content types, but not all. Maybe it’s blog posts in Gutenberg, landing pages and other archives and templates in PHP, or some combination of the two. And almost no agency I’m aware of is using “block” themes (meaning Full Site Editing) for high-end client websites (we’re looking for examples, though) even if they’re using the block editor for much of the content.
Confused, yet? Understandable. The verbiage is confusing, mostly because it hasn’t even been settled by the people in charge. Here’s a typical question and answer:
I also recommend taking a look at this popular article arguing that we should retire the word Gutenberg. It’s no wonder we have a communication breakdown. For what it’s worth, Fränk Klein’s article does a great job of distinguishing between the ‘block editor’ and the ‘site editor’ and makes the case for clarity:
Precision helps to ensure understanding across the board, but it also reassures your audience that you really know what you’re talking about!
Fränk Klein, Human Made
We can’t even agree on what we’re talking about, so it becomes easier to lump everyone into two opposing camps. This trickles down into everything from reductive takes on the situation to an inability to find tutorials relevant to what you’re actually trying to build.
If the WordPress community, and leadership specifically, can’t successfully articulate what they’re trying to build, they’ll continue to relegate anything vaguely critical to the pejorative “classic” category. We need to separate “classic theme developers” from “classic editor bloggers” because many classic themes, like our very own Understrap, are actually heavily investing in finding ways to support the Gutenberg project.
Who builds the most themes anyway?
The worst outcome would be that this large middle portion of “custom theme developers” starts to see that WordPress may not be the best CMS around for their particular use case in next few years. That would be the direct result of ignoring the vast majority of WordPress theme developers who are not building themes for the Theme Directory but for high-end clients who want bespoke designs and often advanced functionality via custom plugins.
I think this comment from Eric Karkovack summarizes it best:
I use the block editor on every new project and generally enjoy it. But I also prefer the control I get with classic themes. Block themes just aren’t as flexible or even necessary for me at this point.
Comment from Eric Karkovack on WP Tavern
This feels the closest to my experience as well. MasterWP runs on a “classic” theme, but we use the block editor for our posts, podcast episodes, and many of our landing pages. On the other hand, we attempted to make our homepage using FSE’s query blocks, but the final product was… to put it lightly… a flaming pile of garbage. It was unshippable at almost every responsive breakpoint imaginable, but I would love to see someone prove me wrong. (Send Commissioner Gordon up to the roof to turn on the Pootlepress-Signal!)
Granted – our homepage is actually built using a number of custom queries, reordered flexbox columns, conditional statements, and more. I wouldn’t expect to build our homepage in a no-code environment, and I would bet that the team behind the NY Times or The Verge (holy redesign, batman) wouldn’t either. We needed to write the entire page, layout and all, in code; the block editor simply wasn’t going to handle it.
One comment in particular summed it up in a way that made a lot of sense:
We see the key problem being this: though WordPress has always been our first choice to build a website with, we were never building a “WordPress website”. Modern WordPress is all about building WordPress websites.
Comment from Rebecca on WP Tavern
Our clients don’t ask us for a “WordPress” website. They ask us for a good, reliable, unique, safe-to-update website. And WordPress has always excelled at that. But many developers who don’t want to build cookie-cutter websites (something we all used to criticize Squarespace for) are turning to other, more flexible CMS options, like Craft or Statamic.
Can’t we all just get along?
Descriptions like this opening paragraph from the WP Tavern do not help:
If you watched Matt Mullenweg’s Q&A session at WordCamp US last weekend, it’s evident that there are significant parts of the community still clinging to the Classic Editor who would be happy for it to be supported indefinitely. For whatever reason, millions users are not ready to switch – some prefer the old editor, don’t like blocks, don’t want to learn a new system, or simply find the newer versions of WordPress too confusing.
Sarah on WP Tavern
Perhaps the use of the word “clinging” was just giving me flashbacks to Obama’s infamous faux pas. Any criticism of Gutenberg is reduced to block-editor-hate or classic-editor-love. It’s seen as a failure of insight, imagination, or perspective about the future of the project. I tried to respond to Sarah on this, but I actually felt like this commenter did a much better job of explaining the problem:
The framing of the reasons people aren’t adopting Blocks is quite ignorant of the realities on the ground. I wish the discussion would be more nuanced about the mismatch Blocks based WP has with an important sector of the WP Ecosystem.
Comment from Sean Rasmussen on WP Tavern
I understand there is a large number of users (and commenters on WP Tavern, specifically) that do fall into the category of “Gutenberg naysayers”. They just don’t like the block editor and won’t hesitate to remind you. That’s fine. Personally, I love writing my posts directly into the block editor even when my hosting company tells me not to. Sure, I don’t think it’s quite ready to be a “landing page builder” let alone a “full site editor”, but I’m trying to board the Gutenberg train.
Next Steps
The WordPress leadership is making it clear that no-code is the future by ignoring the present – that many of us want to continue using WordPress to build websites that can’t be built in a WYSIWYG, because we want to push the boundaries of what a website looks and feels like.
So I congratulate the contributors for hopefully attempting to clean up this mess with the new block-based-template-part-thingies. All attempts to bring some of the Gutenberg progress outside of the FSE context, something we wrote about earlier this year, are absolutely necessary to getting more community buy-in from custom theme developers, especially ones who like to control their code.
If WordPress is serious about bringing developers – not just bloggers – along for the ride and out of the “classic” category, they need something more substantial than hand-wavy dismissals and fake tribalism. This isn’t something that just requires us to just “spend an hour with them to teach them how the new stuff works”. It’s a little more complicated than that.
