Should WordPress 6.0 remove the “Beta” tag from the site editor? – WP Tavern
The short answer: probably not.
The longest answer…
It will depend on a lot of things that will happen over the next couple of months. WordPress 6.0 is planned for a May 24, 2022 launch. 6.0 Beta 1 is April 12. Even with a slightly extended cycle, major updates are coming quickly.
Anne McCarthy opened a discussion in the Gutenberg repository on Tuesday. She posted:
Across the community I get questions about when the site editor beta tag will be removed. Although not explicitly stated in post 6.0I know there was talk of removing it for version 6.0 because it was a temporary tag to communicate that the site editor is still in its infancy.
In order to follow up on this concern and have a place to direct people, I am opening this topic so that when the time comes a decision can be made and people can be informed.
In response, Courtney Robertson said she would like to see a unified effort on creating support materials across LearnWP, HelpHub, and DevHub. “What would be the community’s expectations for beta-related support resources, and what capacity do teams have to achieve this goal?” she asked.
In a separate answershe asked additional questions:
- What is the third-party ecosystem struggling with today to adopt FSE?
- What impact does this have for end site builders using products (plugins) who want but cannot yet work with Site Editor because features are missing (custom post types, templates, shortcodes) and the impact following on their customers?
- Which domains still seem incomplete in Site Editor?
“Before removing the tag, we need feedback on expectations when there is no beta tag,” she wrote.
Avoiding the WordPress 5.0 Gutenberg debacle should be a priority. The Block Editor was arguably the worst feature rollout in the history of the platform, one that left a fractured community that, more than three years later, is still picking up some of the pieces of itself. .
The problem was more a matter of communication than anything else. It wasn’t that the Block Editor itself was a mediocre product. It looked a lot like beta software that was activated overnight – the users of the platform are its guinea pigs. Also, the lack of a built-in method to stay on the classic editor without installing a plugin made for a difficult transition.
Aurooba Ahmed noted a similar risk removing the beta tag earlier:
[Josepha Haden Chomphosy] Talk about the impact and experience of social proof not being on the side of Gutenberg at the start of the project. I think it has a lot to do with the way things were presented and a bunch of PR issues. Removing the beta tag from the site editor could be just as problematic.
Some FSE features such as block-based widgets and navigation menus have also had problematic deployments. Developers and end users often had to look for solutions without an appropriate transition period before enabling features when they were ready.
However, the Site Editor and Global Styles have so far been entirely FSE opt-in features. That won’t change anytime soon. Users must explicitly enable a block theme to access it.
This allowed for a much smoother transition, allowing early adopters to test the waters before the rest of the world. And, make no mistake about it, the site editor and block-based themes have been fundamentally changing the way WordPress’ theme and customization system works for years.
We will be lucky if even 100 block themes are in the official directory at the launch of WordPress 6.0. Today there are 53, a fraction of the thousands of themes in total.
There’s little harm in keeping the site editor in beta for longer. When something breaks, it’s best to know it’s an experimental feature.
Of course, that has to come to an end someday as we peel off the label and let the site editor shine its own light. It can’t stay in beta forever, and “6.0” is a nice, round, nice number. Although WordPress is marching to the beat of its own release drum, it doesn’t erase how revolutionary these “x.0” releases seem set to be in some way. Putting a stamp of approval on the site editor would be a highlight, but it would probably be premature.
WordPress 6.1 may be a more opportune time. There’s no urgent need to rush support hardware, work around accessibility issues, or not let features mature for a cycle or two.