Removing beta label from Site Editor tracking issue

[annezazu]

A temporary beta label was added to the site editor UI when it was released in WordPress 5.9. In order to make a decision around removing this label, the following issue seeks to track items to address related to the removal of this label, including both removing it initially and follow up items to address after.

Must Haves for removal:

• Refine the Site Editor loading state #35503
• Provide a pathway to migrate widgets to block themes #39270

Both of the above items are underway as part of Phase 2 work.

Immediate follow up items after removal:

These are items that are still important to address but aren't critical to resolve in order to remove the beta label when taking the broader current experience into perspective.

• Trac > Provide other ways to set the site icon.
• Template editing: List existing template parts in the Inserter Patterns tab #41399
• Template editing: convert semantic patterns to template parts upon insertion #41397
• Remove coupling of templates and parts when switching themes #25071

Completed:

• Preserve the navigation on theme switch #38291
• Block Template creation is using empty content instead of the appropriate fallback #36648
• Site Editor: Add New - Custom/General template #36860
• Template Part replacement modal – make results searchable #40791

Of note, the following issue should also be considered when this work is completed #43926

cc @priethor @critterverse

[courtneyr-dev]

I would like to see a unified effort on how much user and developer supporting materials across LearnWP, HelpHub, and DevHub we can have ready before the Beta label is reviewed.

What would the community's expectation be for supporting resources related to beta, and what capacity do teams have to reach that goal?

[courtneyr-dev]

Seeing @priethor 's indication this is a to-do. I don't know that I feel good about that for 6.0. Aside from my questions above around training resources:

• 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.

[JustinSainton]

Having been an early adopter of FSE (for pagely.com's launch back pre-5.9) - and someone who believes in the vision of it and appreciates how far it has come - I don't think we're really anywhere near classifying it as "no longer beta".

I think all of @courtneyr-dev's questions above are really important - I don't have great answers for them yet, but I really appreciate them as a starting point for making an assessment like this around whether or not we're still communicating a "beta" level of development for FSe.

[aurooba]

Seeing @priethor's indication that this is a to-do for WordPress 6.0 really concerns me as well.

I have always understood the need to merge the Site Editor into core at an early stage because that's required for wider pools of experimentation, bug reporting, feedback, and all the other things that come out of a larger number of people testing, experimenting, and sharing what they think about a feature.

However, just like the Block Editor needed a few versions to stabilize enough for third party support and real world usage, the Site Editor will need that time too (maybe even more because it impacts so many more things). Nothing I've seen in the preliminary roadmap or tracking issue indicated that the Site Editor will be ready enough to warrant removing the beta label.

Josepha 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.

I do not yet know what the full criteria should be for removing the beta label, that warrants discussion and consideration. Some things that come to mind right away:

• custom post type support
• a truly usable navigation block
• tangible API changes and support coming out of the discussion kickstarted in Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability #38998
• better responsive support

I would like to see FSE proceed with community support, but that won't happen if we remove the beta label too early.

[annezazu]

Thank you all for chiming in with these excellent questions! Just for context, this being added to the 6.0 project 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 :)

For some of these questions, I don't think this is the right avenue for discussion. Specifically, I would move this into more of the training space so it doesn't get lost:

What would the community's expectation be for supporting resources related to beta, and what capacity do teams have to reach that goal?

[0aveRyan]

I'd cosign everything @aurooba and @courtneyr-dev said, but expand on Aurooba's last point around responsive support.

Right now most Theme Authors creating well-designed Block Themes are using CSS logical functions like max() and clamp() for responsive spacing and typography within the theme.json, but there isn't support in the Site Editor for editing or creating these styles, meaning it still requires code to make the best Block Themes and the Site Editor is still second-tier, even though it now supports variable widths.

This has been discussed in #35558 and is related to #38998, but some way to at-minimum edit the CSS logical function, or better create an experience within the Site Editor (perhaps leveraging editor device previews) to set min, max and scale values seems a critical step towards maturation.

[alexstine]

Before removing the beta label, I would like to see big improvements on an accessibility front. The difference between FSE vs. the post/page editor is the post/page editor is at least somewhat passable. What I mean by this is it might be slow for me to write a post/page in the post/page editor, it is not impossible at this point. The FSE UI/UX for screen readers still needs a ton of thought as the 2 operate differently and are not even in the same universe when it comes to accessibility. What I mean by this is FSE is still really off limits completely for any screen reader users and I think it should at least get to a passable/usable state first.

I believe there are some improvements coming that will help the experience in all the editors but I cannot speak for the specifics of FSE at this point as my focus has been catching up other components globally.

[luminuu]

I absolutely agree with all the points already mentioned here. It's way too early to consider removing the beta label.

From a my point of view, I'm thinking of these at the moment:

• Improved CSS handling and responsive support, see Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability #38998
• the Query Loop block should offer more parameters like the WP_Query function, or at least have the ability to extend the parameters
• Template / block / feature locking for the use case where only contents should be edited/adjusted but not the layout/design itself. I know this is contrary to what the block editor / FSE is all about, but it's important for agencies/enterprise systems or even freelancers.
• A complete and up to date end user AND dev documentation.

[priethor]

Seeing @priethor's indication that this is a to-do for WordPress 6.0 really concerns me as well.

Apologies for the late reply and any confusion caused. As @annezazu mentioned above, adding this issue to the 6.0 board doesn't mean the beta label will be removed, but that need to make a decision in either direction based on the feedback you are all providing, so thanks for chiming in! 🙏

[Clorith]

I'm going to jump in with some thoughts as well, I've intentionally let this sit with me a little bit first :)

I feel some crucial points are still missing from the feature to be considered ready, and past experiences tells me we will see many iterations over it still, which are probably going to lead to some changes in behavior/functionality. As soon as that "beta" label is gone, we are saying this is ready to use, and what is there is what you can safely use; I do not feel comfortable making that proclamation as of right now though, and with the time-frame till 6.0 enters beta, feel quite confident in saying we won't be there for 6.0, possibly not 6.1 either, and that's OK, we want to provide the best possible feature after all.

[courtneyr-dev]

I feel some crucial points are still missing from the feature to be considered ready, and past experiences tells me we will see many iterations over it still, which are probably going to lead to some changes in behavior/functionality. @Clorith

What specific criteria can we identify that feels "not ready yet"? What do we mean by "ready"?

I don't have good answers, but want to find a common consensus on these questions.

[Clorith]

Those is an excellent question, and I understand the concept of "ready" is quite hard to get right, but some big hitters that are needed from my own experience (which may have been addressed, but leaving them for a release rotation to mature would be nice):

• Feature parity with the template hierarchy (if a theme should be able to be more or less empty to give full freedom, and let me make the templates I need, or want, it needs to support them all)
• Default content or similar for blocks (it's not possible to reliably make a taxonomy page if you have no taxonomies for the loop to display in WP 5.9 for example)
• Customizer parity
  • hot topic, I know, and obviously WP should not need to make customizer plugins function within the site editor, that's just not realistic, but the same available elements should at least exist
  • for example the recurring mention of "Custom CSS" which has been a popular feature
  • the concept of multi level customization groupings, for example WooCommerce that has styling for different pages under a WooCommerce parent section.

And just the concept of maturity, I've mentioned the issue of breaking changes from the Gutenberg project over the past few releases, and we need to make sure we don't suddenly have a situation of "oh, this could have been much better if we did it another way, let's change it" 2 weeks after declaring such a major feature "production ready" (which is what taking that beta label off signals), so accepting that we may need a longer public beta period for this to make sure that doesn't become the case I would consider an acceptable trade-off.

[annezazu]

As a quick logistics update, this has been removed from the project board for the WordPress 6.0, meaning the beta label will remain in place as it is now for WordPress 6.0. The Site Editor, along with the various flows within, still needs refinement and, ahead of future WordPress releases, that decision can be revisited. In the meantime, folks are welcome to continue to share points of discussion on this thread and follow along for updates!

[annezazu]

As 6.1 planning begins, I wanted to loop back on this issue to share some thoughts from the broader FSE Outreach Program perspective, pulling in insights from the high level posts, hallway hangouts, etc. Pulling these items together, there are a few key issues that I think need to be resolved in order to remove beta:

• Pathway to migrate widgets to block themes. This currently feels like content loss.
• Provide a fallback to the next best template in the hierarchy when creating new ones to avoid the creation of an empty template. This inevitably is both confusing for users and feels inefficient. This is part of a broader issue: Creating a template: Present the user with initial block configuration options #41060
• Preserve navigation on theme switch.
• Remove coupling of templates and template parts from themes. Similar to widgets, this ends up feeling like content loss.
• Include a way to add a custom/general template via the Site Editor to unify the experience with the template editor.
• Provide other ways to set the site icon.

The following feel more nice to have but still important:

• Improve placeholders for site building blocks both so folks can more clearly see what changes they might be making and to prevent accidental removal of something that's needed.
• Provide more granular information for Global Styles when saving.
• Colorize template parts/reusable blocks to better differentiate global items.

More anecdotally, a block themer recently shared how it's hard to explain to users why something marked as beta is okay to use, particularly when they are building themes that are production ready. This block themer perspective is something to keep in mind in this discussion as well. For now though, I hope the above helps set some context for this broader discussion as the 6.1 cycle begins!

[mtias]

Thanks for resurfacing this @annezazu. Let's indeed aim at refining a list of blockers and nice to haves for removing the "beta" label in 6.1 that we can update this issue with.

[annezazu]

Quick note that this has been updated (title, label, and content of the issue) to follow the pattern of other tracking issues in order to provide clarification and direction.

[jameskoster]

This might be one to consider here: #42473
And this one: #42439
Another: #42154
Two more: #41947 & #42675 (both related)
Also: #40618

[joedolson]

I'd like to see a resolution to #39266 as a requirement to move out of beta, as well. We need to have testing in place that maintains the stability of the accessibility of block output in order to consider this a production-ready system.

[annezazu]

Thank you both for sharing additional issues here. At this point, I want to provide an update that removing the beta label is not slated for 6.1 with feature freeze two weeks away. When work begins for evaluating this same discussion for 6.2, the above issues can be considered at the same time based on the current experience and work.

[jameskoster]

I would be tempted to include this here: #44322

[annezazu]

As part of looking across work for wrapping up phase 2 and preparing for 6.2 overall, this issue has been updated with current blockers, items to follow up on after removal, and related work (namely, considering renaming the Editor entry point in general).

[annezazu]

In the lead up to WordPress 6.2 beta 1, the label was removed in this trac issue after first ensuring that meaningful progress was made on the final blocking issue, refining the site editor loading state. Because this was done in trac as part of the release process, I wanted to offer a quick update before closing. The remaining items mentioned as follow up are going to be reviewed and considered for tracking as part of the broader wrapping up phase 2 efforts (ex: Provide other ways to set the site icon) and/or phase 3 (ex: Remove coupling of templates and parts when switching themes) efforts depending on their current priority.

Thank you to everyone who offered feedback and followed along as this decision was made. Please keep the feedback coming so we can make the Site Editor experience continually better.

[mtias]

Thanks @annezazu for handling this issue. For extra context on the site loading task — it's a different scenario now that we load in a high-level zoomed out view, and some improvements to the layout setup are helping address some of my own grievances there. We'd continue to explore a better loading stream that avoids things popping into the scene as much as possible, but it's more of an open ended tasks as we add suspense boundaries to more elements of the site editor.