Gutenberg 9.3 Provides Indicator of Where Full-Site Editing Is Going, a Future Without Widgets and Customizer Screens
Version 9.3 of the Gutenberg plugin dropped earlier today. It is the first version of the plugin during the WordPress 5.6 release cycle that will not see its new features land in the core platform. However, bug fixes have been backported to WordPress 5.6 beta 2 and 3. Much of the work for the release focused on full-site editing (FSE) features and fixes. However, some minor enhancements outside of the site editor landed in the update.
The Social Links block now supports Patreon, Telegram, and Tiktok, which brings the total number of social icons to 43. The Buttons block also has an overhauled alignment option.
Overall, the release mostly adds polish to existing areas. The development team fixed over 20 bugs and has continued pushing forward with improvements to the site editor.
Removal of Widgets and Customizer Screens
The biggest story around Gutenberg 9.3 is not in measurable code or user-facing design changes. Instead, it is within a discussion on a ticket about removing the Customizer and Widgets screens when a user has FSE enabled.
Version 9.3 hides the Widgets and Customizer items from the WordPress admin menu. However, they are still accessible by directly going to the URL or lingering links within various parts of the WordPress admin like on the Themes screen. This change could have implications for the future of those screens.
“I think it would be a bad move to hide them now without clearly communicating to the WordPress community what the future of widgets and the customizer is,” wrote Carolina Nymark, a Themes Team representative, in the ticket. “Hiding them is going to lead to more questions from worried users and developers. I think hiding them without answering these questions publicly is a bad idea. I’m not asking you to answer me in this pull request, I am asking that ‘WordPress,’ be it the core-editor team or someone else, presents the long term plan for these core features.”
She lists several questions that should be answered by project leaders. Most of them boil down to the central question of what role the customizer will play in the long term:
- Even if the menu item is hidden, the customizer can still be accessed, will the options still work?
- What role will the customizer have with FSE themes?
- Will it be deprecated, how and when? If it is not going to be deprecated, why hide them?
- Will it also be deprecated for non-FSE themes? How and When?
- How do I convert existing customizer options for my updated theme?
- What about the WordPress options that are only available in the customizer, like the site icon?
“The idea here is that since FSE themes don’t have widget areas, the widgets screen is useless,” responded Riad Benguella. “For the customizer, it’s a duplicate of the Site Editor screen (similar capabilities), so we need to make sure the Site Editor fills the gaps left by the Customizer. Global styles and Site blocks address most of the site options required for FSE themes and making the switch (hiding the customizer) will allow us to discover gaps we’re missing.”
That FSE themes will not have widget areas does leave one to wonder why so much work has been put into converting the sidebar/widgets system to use blocks over the past year. It was also a planned feature for WordPress 5.6 that did not make the cut.
Benguella’s thoughts seem to be in line with 5.6 release lead Josepha Haden’s recent comments. “There’s a lot of interest in reducing the number of workflows, and I’m hopeful that we can consolidate down to just one beautiful, intuitive interface,” she said in response to pulling the plug on widgets for 5.6.
Benguella’s comment is also one of the first public indications that I have seen about what such a consolidation would look like. Presumably, there will be no need for the Nav Menus, Widgets, or Customizer screens as WordPress progresses in the coming releases.
I still question whether the work that the team is putting into making those screens handle blocks is worth it. Traditional themes should simply use traditional nav menus, widgets, and customizer options. New block-based themes should use the site editor when it lands.
There are still some unanswered questions from Nymark’s list. We will need to wait for further feedback from someone in the know. She is right about the need for clear and public communication.
Automatic Switching to FSE
One of the biggest improvements, particularly for people testing FSE, is that Gutenberg now automatically enables FSE when a user activates an FSE-capable theme. It will also disable FSE when switching back to a traditional theme.
Some good themes to test FSE with are Q, Twenty Twenty-One Blocks, and Seedlet Blocks.
Users can also no longer enable FSE via the Gutenberg Experimental settings screen. Using a block-based theme is now a requirement to test this part of the Gutenberg experience. This is probably a good call at this stage. Despite being clearly labeled as experimental, thousands of users run Gutenberg in a production environment and may enable it. Plus, it keeps people from testing a broken experience when their theme does not support it.
Buttons Block Content Alignment
For theme authors who do not rely on the Gutenberg base styles, they may need to update their theme stylesheets to handle content-alignment classes on the Buttons block. However, they will also need to continue supporting the old classes for backward compatibility.
This change means that users can use wide and full-width alignment on the block while separately aligning the block’s content.
The update adds a content justification option to the editor toolbar for the Buttons block. It makes sense to use this method because the Buttons block is technically a container. It merely houses one or more inner Button blocks. The previously-used alignment system is meant for aligning the entire block rather than the block’s content.
In past versions of the block editor, the Buttons block used the traditional align* classes for left, right, and center alignment. This Gutenberg update switches the classes to is-content-justification-*.
The editor will automatically transition the Buttons block to the new classes when a user edits a specific post with the block. Otherwise, they will still have the old align* classes.
16 Comments
I hope this means that we will eventually be able to add custom controls on the site editor’s screen via an API. Without this, there’s no way we can offer the same level of customization, which is currently avaliable on the Customizer.
Report
“does leave one to wonder why so much work has been put into converting the sidebar/widgets system to use blocks over the past year”
This is for all of the millions and millions of sites on a non-FSE theme.
Report
So that means this new FSE mode will only be enabled and controlled by a theme?
Report
I still think it’s unnecessary. I’d leave non-FSE theme users with the traditional widgets system. I could be wrong (and often am), but I would think the users most interested in using block-widgets are going to be those who will also adopt FSE quickly. I’m sure there’s a sub-group in there that will want block-widgets but not move on to FSE for a few years. I know it is probably more in line with WP’s iterative approach to go this route, helping users along the path to eventual FSE. This will also depend on the theming community. We’re putting a lot of burden on theme authors by asking them to start adopting FSE while adding in support for new features for their older, classic themes. Of course, they can opt out, which is what many may do. It will be interesting for me to watch either way. :)
The biggest thing that seems to frustrate a lot of theme developers is the lack of a roadmap that lays out some of these more technical changes. I don’t think they are asking for a timeline. They just want a general outline of major feature changes. Obviously, from that one discussion, one of the leading developers from the Themes Team seemed to be caught off guard with the plan and has several unanswered questions.
The widgets system provides a good example of the need for at least a rough outline. If both block-widgets and FSE land in WP 5.7, some theme authors will want to just skip over widgets and start building FSE themes. Others may decide to continue building classic-type themes with block editor and widget support. An outline helps them plan ahead and make informed decisions.
Report
I personally like the new direction of WordPress with Gutenberg. It’s the need for sure to make it future proof and align with the modern website builders.
Of course, all these decisions are hard to implement and not every legacy can be retained.
But, definitely, things need to be progressed well communicated so that the 3rd party developers can take proper action to make their these & plugins work with the new single app WordPress & also plan ahead on what to work on and whatnot.
As in this case, I can see some theme developers are still working hard on building or upgrading the header/footer builder in the customizer and also improving that to use Gutenberg components in the customizer. If it will be deprecated, they need a clear announcement (I guess) so they know what things to work on making their theme future proof.
That said, I personally think WordPress is heading in the right direction and it is opening up a lot more new opportunities for developers like me.
Report
“There’s a lot of interest in reducing the number of workflows, and I’m hopeful that we can consolidate down to just one beautiful, intuitive interface,”
Amen to that. In my opinion try to build a hybrid / conversion / porting of Widgets and the integration / compatibility with FSE and site customizer has been a major mistake and has held back FSE development.
Let it go – Gutenberg content editor and SFE are the one beautiful, intuitive interface. Traditional themes will be around for a while but will fade out as the FSE takes over, as long as we get on with it and stop trying top build something that supports every single existing WP user and theme.
Sorry, I am frustrated by the continual delays in the development of the FSE.
Report
There are “special” things themes are doing that block-based widgets are not going to provide continuity for. I hope the Customizer, widgets, etc. are not deprecated. Existing themes need to continue working exactly as they do now, indefinitely.
Otherwise, really, WordPress ought to have been rewritten from scratch rather than Gutenberg being worked into the existing project. I’m worried that backwards compatibility is not as important as it has been and that that’s going to be very inconvenient for site owners and theme maintainers.
I am very excited about FSE, but only for brand-new themes – not existing themes.
Report
I totally agree. I have worked on my websites and taught courses with the classic editor for nearly 20 years. I will not switch to the block editor. I am even in the process of moving my website at wordpress.com to another provider because they force me into the block editor. On my other websites, I’ll keep relying on the “Classic Editor” plugin and several widgets. If that is no longer possible in the future then I’ll convert my websites to another open-source CMS.
Report
Please leave the Customizer and Widgets as they are! I use themes on live sites where both, Customizer and Widgets, are important parts of these sites. I do not have the time or the will to make any migrations or re-coding this themes. Instead, make an option to turn these features off for people who do not want to use them. I guess there are millions of sites that will be affected by such, not really needed, change.
Report
Just to be clear, widgets and the customizer will definitely still be available. They are currently disabled when a user activates a FSE-capable theme. Such a theme would not support widgets or customizer options anyway.
Report
For how long? It looks like they would go away with the Classic Editor. If you want to ship an entirely different product, why didn’t you rebrand to something else? FuturePress or something? Switching the product while keeping the name is not the right way to transfer the users.
Report
Considering that the Classic Editor is scheduled to be removed soon, what is the roadmap for widgets and the customizer to be removed?
Report
That is one of the questions being asked — whether they will be deprecated. We are years out from a decision on that. These things are so fundamental to how themes work today that it will be a long while before that could really be discussed.
Also, the lead developers were open about 2022 not being a set-in-stone date to remove the classic editor. When they evaluate whether to formally deprecate or remove it, I think they’ll push the date back. I’m not seeing the trends that would support the original deadline.
Report
Hey there! Thanks for the post and for raising awareness about these updates. I’m happy to answer some of the questions raised here. We did have a lengthier discussion with Carolina Nymark on the #core-editor channel where we elaborated further. (Discussion linked on the PR)
Yes, the options will work properly but it’s not guaranteed that the access to the customizer remains but whether the customizer should be accessed or not when this lands in Core is something that is yet to be discussed.
As Josepha expressed, the ultimate goal of FSE is to simplify the admin, reduce the number of concepts WordPress has to deal with.
The Site Editor and the customizer have the same capabilities but use different technologies. Having both at the same time can be confusing for users. The idea we are currently exploring is that the customizer as we know it today won’t have any role for FSE themes. The site editor would be the customizer of the FSE themes.
No, I believe the customizer will keep working as long as WordPress supports non-FSE themes and I don’t see support for these ending anytime soon.
A lot of customizer options are absorbed by Full-site editing blocks. For instance, you can edit template-parts right in your templates which is equivalent to widget areas capabilities, You can edit menus via the Navigation block, you can tweek the site description, logo via their dedicated blocks. You can also customize colors, fonts etc via the global styles panel. That said, extensibility APIs are needed in order to allow third-party global options. The current sidebar extensibility APIs and SlotFills available on the post editor are good indications of what these APIs might look like.
This is actually one of the main reasons for this change in Gutenberg 9.3. We don’t really have all the answers today and as we move forward, things might change.
We’d like to make it easier for theme developers and contributors to try Full Site Editing and the site editor, help us find the gaps, run user tests and address questions like: “What options are we missing by default” and “what APIs should we provide”.
Report
A block-based theme (also called Full-Site Editing theme) is a theme that by definition uses the new site-editor screen to build layouts. In that screen, users have access to global styles where they can define things like background-colors, typography etc for their site, and they can build their layouts as they wish. So it makes sense to hide the links to the customizer & widget screens when such a theme is used.
There are still a couple of things in the customizer that are not yet supported by global-styles, but these will eventually all be added. As for widget areas in an FSE theme, they are no longer necessary. Users can add a group block wherever they want, think of it as a widget-area and add blocks in there for everything their widgets used to previously do.
Want a sidebar next to the content? No problem, just add 2 columns, content on the left and “widgets”/blocks on the right.
Full-Site editing doesn’t deprecate anything. It simply abstracts the ideas a bit and allows for greater flexibility. We will essentially have an infinite number of widget-areas, wherever we want them in our layouts. They will no longer be called “widget-areas”, they are just content-areas where we can place anything, including widgets.
As for legacy/classic themes, these won’t be affected at all. The customizer and widgets will continue working there perfectly fine.
Report
I absolutely agree with Carolina Nymark on the reception of this landmark changes on the part of the regular consumer. Go a bit farther with the PR this time, that should cudgel unwarranted skepticism around the new widget-lacking offers.
Report
Comments are closed.