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:
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.
Does anyone know how long the Classic editor will continue to be supported? While I like the idea behind Gutenberg, the sites I manage don’t have a need for it as we use a lot of CPT and custom fields for the structured content we manage.
I say it has to be supported for a few more years at least. Gutenberg just does not have the functionality of top of the line page builders like DIVI and Elementor.
That will take at least one year plus for the Gutenberg team to give us.
Also we have many FREE plugins that do exist to enable the classic editor and bypass Gutenberg.
The current timeline is through the remainder of 2021 for the Classic Editor plugin. At that point, the team will reevaluate based on usage. Given its current active install count, I imagine that they will extend that date.
It’s also important to note that if/when official support drops, it doesn’t necessarily mean that the classic experience will disappear altogether. It could mean that the classic editor code is removed from core WordPress and ported entirely into the official plugin. We really don’t know what it will look like at that time yet. There really isn’t a big (or even a small) push to remove classic support right now.
December 2021. https://wordpress.org/support/topic/the-classic-editor-plugin-will-be-officially-supported-until-december-31-2021/
Honestly, when Gutenberg first came out, I was on the fence and still used the Classic Editor. But now that Gutenberg/Block Editor is maturing, I think it’s time that we all get on the same page and make the switch this December.
This “blockification” of WordPress seems to be consuming all the resources for the core team. It’s like they are trying to hammer a square “block” problem into a round hole.
Navigation must be blockified!
Widgets must be blockified!
Media manager will be bockified!
Long live blocks!!!
Most of my clients hate the block editor and prefer using the Classic Editor for its simplicity.
I don’t understand why the whole of the WordPress UI needs to be blocks?
Also – where is the same effort in refactoring the old code-base to use OO code, frameworks, speed and efficiency?
So what was the final go/no-go decision?
Will FSE be included in the WordPress 5.8 release?
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