Yesterday, Josepha Haden Chomphosy announced the roadmap for deciding whether Full Site Editing (FSE) will land in WordPress 5.8. After the launch of Gutenberg 10.4 on April 14, a small group of core leads will participate in a go/no-go demo.
The following people will be on the call:
- Matias Ventura – Gutenberg Project Lead who will host the demo.
- Matt Mullenweg – WordPress Project Lead.
- Helen Hou-Sandì – Lead Developer.
- Josepha Haden Chomphosy – Executive Director.
The meeting’s agenda is simple. Ventura will host the demo, and the group will discuss and cover implementation questions.
If there are no blockers, they will share a plan for merging FSE into WordPress. The more likely outcome is that they will find at least a few items that must be addressed. In that case, they will share these publicly with a plan to tackle them before a second go/no-go date of April 27.
The first beta release of WordPress 5.8 is set for June 8, with a general public release for July 20. The team needs to decide on inclusion early in the release cycle to give theme and plugin developers time to prepare.
While many are on their toes awaiting a final decision, everyone needs to have a little patience at the moment. Everything needs to be carefully weighed by the project leaders. There is a good chance we will not know the outcome until that second, April 27 deadline.
Most of the FSE transition would be a beta run for a subset users. Including these features in core does not mean that WordPress immediately flips the switch and enables everything for 40% of the web. For the overall FSE experience, users must make an explicit choice to install and activate a block-based theme.
With that in mind, the onboarding experience should be a welcoming one that invites users into site editing while letting them know the potential issues. If it is a built-in beta, they really need to understand that improvements are forthcoming.
An in-core beta run like this is also welcome, given the project’s launch of the block editor a couple of years ago. Regardless of whether people loved or hated the block editor, the rollout was not smooth for everyone. WordPress dropped end-users into an overhauled system, which was a shocking change for many. The project has a chance to do better this time around by incrementally introducing features to users and allowing others to immerse themselves in the new experience of their own choice.
“The most important context to share is that it isn’t shipping as the full, default experience for users,” wrote Chomphosy in the post, noting that the team is growing beyond past mistakes. “One of the clearest pieces of feedback from the Phase One merge process was that there wasn’t enough time for our extenders (agencies, theme authors, plugin developers, site builders, etc.) to prepare for the upcoming changes.”
The decision-makers may also decide to ship some pieces but not others. FSE is a project made up of several components.
“The whole full site editing project is sort of an umbrella term for a collection of tools and projects, so it would be possible for some pieces to ship while others don’t,” said Haden Chomphosy. “There are probably some exceptions to that, as you mentioned, but many of these can ship as they are ready.”
The exceptions she was referring to are components that make more sense together. For example, block-based themes via a theme.json config file and most of the site-editing blocks are not as useful when separate.
Of course, there are cases where something like the Query block could be used outside of the site editor. Users might create custom queries within a page without the benefit of the site editor, for example.
My primary concern is not with features related to the site editor but with block-based widgets. It is a transitional tool for users on traditional themes. Along with the new nav menus screen, it is not a part of the block-based themes experience. The goal is to allow users to start using blocks in more places. However, this will result in a broken UX in many cases.
The widgets experience is still partially broken, treating each block as a separate widget. Users must learn to put a Heading (widget title) and another block (widget content) into a Group (widget wrapper) for the correct widget-related classes on the front end of the site. For some themes, whether users do this will be a non-issue. For others, it will look ugly at best and break the layout at worst. Putting this responsibility on the shoulders of end-users was deemed an acceptable solution.
I wanted to focus on this issue because it is one of those things that may simply be flipped on for all users. I am still afraid that transitioning from a functioning system to a potentially broken one will make for a bumpy ride.
The WordPress 5.6 release team decided not to ship block-based widgets. Hou-Sandì, as the core tech lead for 5.6, provided a historical account of the decision and why it was not ready for inclusion:
My question for features that affect the front-end is “can I try out this new thing without the penalty of messing up my site?” — that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.
While widgets have arguably improved, I still see the answer as being the same as last October. I have not seen enough buy-in from the theme development community to support the block editor itself, much less new block-related features. However, at some point, the project simply needs to move forward. Themers will just need to keep up.
