Should WordPress 6.0 Remove the “Beta” Label From the Site Editor? – WP Tavern


Justin Tadlock
The short answer: probably not.
The longer answer…
It will depend on many things going right over the next couple of months. WordPress 6.0 is scheduled for launch on May 24, 2022. The 6.0 Beta 1 is on April 12. Even with a slightly extended cycle, major updates come fast.
Anne McCarthy opened a discussion in the Gutenberg repository on Tuesday. She posted:
Across the community, I’m getting questions around when the beta label for the site editor will be removed. While not explicitly stated in the 6.0 post, I know it’s been discussed around having it removed for 6.0 as this was meant to be a temporary label to communicate that the site editor is still in early stages.
In order to track this concern and have a place to point people, I’m opening this issue so, when the time comes, a decision can be made and folks can be notified.
In response, Courtney Robertson said she would like to see a unified effort on creating support material across LearnWP, HelpHub, and DevHub. “What would the community’s expectation be for supporting resources related to beta, and what capacity do teams have to reach that goal?” she asked.
In a separate reply, she posed additional questions:
“Before removing the label, we need feedback about the expectations when there is no beta label,” she wrote.
Alex Stine noted accessibility issues as a blocker for removing the beta label. Dave Ryan added items that theme authors were still hard-coding because they are unsupported in the editor.
Avoiding the WordPress 5.0 Gutenberg debacle should be a priority. The block editor was arguably the worst feature rollout in the platform’s history, one that has left a fractured community that is, over three years later, still picking up some of the pieces of itself.
The problem was more about communication than anything. It was not that the block editor was in and of itself a poor product. It just felt very much like beta software that was switched on overnight — the platform’s users its guinea pigs. Plus, the lack of a built-in method of staying on the classic editor without installing a plugin made for a rough transition.
Aurooba Ahmed noted a similar risk with removing the beta label early:
[Josepha Haden Chomphosy] talked about the impact and experience of social proof not being on Gutenberg’s side early on in the project. I think a lot of that had to do with how things were presented and a bunch of PR issues. Removing the beta label from the Site Editor could be just as problematic.
Some FSE features like block-based widgets and nav menus have also had problematic rollouts. Developers and end-users have often needed to scramble for solutions without an appropriate transition period before switching the features on when ready.
However, the site editor and global styles have been entirely opt-in FSE features thus far. That is not changing anytime soon. Users must explicitly activate a block theme to access them.
This has made for a far gentler transition, allowing early adopters to test the waters before the rest of the world. And, make no mistake, the site editor and block-based themes fundamentally change how WordPress’s theme and customization system has worked for years.
We will be lucky if even 100 block themes are in the official directory when WordPress 6.0 launches. Today, there are 53, a fraction of the 1,000s of themes in total.
There is little harm that could be done by keeping the site editor in beta for a while longer. When something breaks, it feels better knowing it is an experimental feature.
Of course, it must come to an end one day as we peel back the label and let the site editor shine in its own light. It cannot stay in beta endlessly, and “6.0” is a nice, round, feel-good number. Despite WordPress marching to the beat of its own versioning drum, it does not erase how much those “x.0” releases feel like they should be revolutionary in some way. Putting a stamp of approval on the site editor would be a highlight, but it would likely be premature.
WordPress 6.1 may be a more opportune moment. There is no pressing need to rush support material, bypass accessibility issues, or not let features mature for a cycle or two.
Thanks for bringing attention to this discussion! It’s been really informative to hear all the varying thoughts/questions/concerns/etc. It’s encouraging to see how the knowledge and awareness around FSE is continuing to grow. I see momentum around issues like this as a reflection of that, along with the concerns people have.
I mainly wanted to comment here to re-share something I said on that issue so that folks have clarity there. This issue being added to the 6.0 project and being open at all with reference to 6.0 does not mean it’s for sure happening for 6.0. This issue is meant to reflect a decision needing to be made and a place that people can follow along as the discussion unfolds. The decision is the to do — not the removal of the label outright.
I wanted to make that clear as I fear that accidentally I somehow gave off the wrong impression. It’s part of why I changed the title to start with “Discussion” to better match the labels and situation at hand.
Separately, if you’re an extender (whatever form that takes), I deeply encourage you to comment on open issues or open your own around blockers you might be running into in order to adopt various features of full site editing. Doing so will help us move with confidence when the time does indeed come to remove the beta label since it’ll give the WordPress project the ability to address widespread concerns sooner rather than later. I’m @annezazu on slack if you want to chat. I’m off work for the next two weeks but will respond as soon as I can upon returning.
Thank you for another fascinating article. I was shocked to read there are only 53 block based themes in the directory, out of @ 1,000 elsewhere! Where could we find more well-coded, premium is fine, block based themes, maybe even some with full site editing? Thank you. ❤️
I updated the wording in the post. After re-reading, it sounded like I was saying 1,000s of block themes. I meant that there are only 53 block themes in the directory out of the the 1,000s of themes overall.
I agree that the beta label needs to stay on the Site Editor a while longer. When Gutenberg was released, I used the Classic Editor on all my websites for about a year, because I was worried about the editor breaking or features not being available.
When I checked back on the editor’s progress a year later, I gradually started using it on all my websites without any major problems.
I hope with the Full Site Editor that it will always be an opt-in feature, since many of my websites only have myself as an administrator, so a drag-and-drop interface would not be needed.
I’ve been testing the block editor continuously since the beginning, comparing it to the page builder I use everyday. As a method of getting content laid out on a page it definitely has its merits. I will use it say for post content, if the site has a news/blog element to it.
But, when one goes to apply it to anything other than this things get pretty hairy. Exploring the latest innovation of FSE, while workable, is a lot less intuitive and powerful compared to the better page builders. As mentioned, there is no accommodation for other post types, unless one adds something like Toolset. Again, as mentioned, shortcodes are an issue in FSE. This then means adding, again, other plugins so that we can work with dynamic content.
While WordPress and the block editor needs to think forward on what needs to be implemented, to make a powerful platform, it has overlooked certain quandaries it purports to solve. One of these was some sort of standardised regulation so that one could switch themes and keep content intact to some degree.
From early on it struck me that allowing plug-in and theme authors to make blocks that covered the same ground as the the base install of blocks was really looking for trouble. I see it again and again. You work up some ideas and layouts, adding in extra blocks to fulfil what the new editor can’t achieve. Layer some of these additions need to be removed and some things collapse or one can’t work with some portion of content as something is missing.
This should have been though through from the inception of the block editor. A strict selection of blocks should have been implemented for structure (sections, rows, columns) and the main content elements. After this no other implementation of these should have been allowed, the exception being blocks with specific purposes not covered by the block editor. The base instal of blocks should be reasonably basic, with at least spacing and main typographical controls where necessitated. There then should be a powerful mechanism to allow third party plugins, themes and page builders to hook into this and override it so that their own bells and whistles and UI could be added. Change/turn off themes, builders or plugins and at least content and layout would remain intact. All third parties would be asked to conform to this standard, to some degree at least.
Other thing of note that the block editor lacks.
It isn’t very good at presenting breakpoint previews in the editor. You need something like Toolset or Kadence to achieve anything that is code to a real life representation in terms of spacing and then this is often not as good as some of the better page builders.
When it comes to templating, the block editor leaves a lot to be desired. It has abandoned the concept of separating the content from design and instead mashes things up with patterns and reusable blocks. This has been addressed to some degree with FSE but there are far better solutions out there in the form of page builders and Toolset.
Related to this is a logical UI for working with dynamic content. I work a lot with directories and inventories where content is displayed in a consistant manner through a CPT fronted by a template. On the back end of each post instance all I need or want is a custom post type form for quick data entry. I don’t need the block editor part of the UI getting in the way. I do like how the new editor saves asynchronously without reloading the page so I have had to hack together a rudimentary plug-in that removes the block editor. I see we still don’t get a Gutenberg styled editor fir Woo products?
It seems Matt and the Gutenberg team have been focused too much on the blogging origins of WordPress and have neglected to recognise all the dynamic ways the platform has grown into. This is a pity because the block editor has a lot going for it.
The site editor is not opt-in by default though.
For a brand new WP user, FSE, site editor and global styles are the default, and not using these tools is opt-out.
As most of the voices around this subject are seasoned WP users, I wonder what impression a new user would have when they see Appearance > Editor (beta)?
Is this different and separate from ‘Open site editor’ in the welcome panel? They look the same, yet one link is marked as beta. What’s going on here? etc..
I also wonder if the term “beta” is meaningful to the average user in any way. Would a new user to WordPress even understand that it might be a somewhat limited feature or an experience that is expected to change?
As a film collector, every time I see “beta” my mind always wants to jump to Betamax. 😉
Instead of beta perhaps “Early Access”, “Experimental” or something to that nature better explains what it is about.
I planned to move to a FSE theme for my main site and wondered how to manage custom post type templates. I did not find any information about this and I discover here that it is not possible. Why Gutenberg – and now FSE – are lacking features that actually works well in WP since years. I just don’t understand the logic. It seems the message is “your future is brighter but don’t expect to keep what you like”.
It is 100% possible to use templates for CPTs in the site editor. As of WP 5.9, they just need to be added via the corresponding .html templates. This works the same was as adding the old .php templates.
They are editable via the site editor if included in the theme. So, you could just stick an empty *.html file in there and build from the editor if you prefer.
What’s not possible in 5.9 is creating new custom templates directly from the site editor. The dev team limited this feature to a sub-set of templates because they wanted to work on the template-creation flow in 6.0.
Your email address will not be published.

document.getElementById( “ak_js_1” ).setAttribute( “value”, ( new Date() ).getTime() );
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable



Please enter your comment!
Please enter your name here