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:
- What does the 3rd party ecosystem struggle with today for adopting FSE?
- What impact with this have for end site builders using products (plugins) that want to but can’t yet work with Site Editor because features are missing (custom post types, templates, shortcodes) and the following impact to their clients?
- What areas feel incomplete yet in Site Editor?
“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.
