Ask the Bartender: What Happens to the Customizer When a Block Theme Is Active?

Something on my radar right now is third-party plugins that have settings in the Customizer. What I gather of friends who are the devs working on Customizer and front-end stuff within a few plugin companies, global styles and block styles are not yet on their radar. So what happens if someone installs Twenty Twenty-Two or another block-based theme? The left admin menu for Customizer isn’t there. The janky way to get there is via Appearance > Themes > Customizer. But the expectation is that third-party plugins and themes need to move settings over. In fact, this seems more like they need to duplicate settings in both places for a while.


For those out of the loop, let me provide a quick refresher on this topic. When WordPress 5.9 lands, we expect it to ship with the new site editor and global styles interface. However, most users will not see this screen unless they are running a block theme.

Given that the upcoming Twenty Twenty-Two is also shipping with WordPress 5.9 and judging the popularity of past default themes, we can expect many thousands of users will be transported into this whole new world. For some, this might be as shocking as the launch of the block editor in 5.0.

When a block theme is active, links to access the old and familiar customizer will disappear from the user interface. The widgets and nav menu screens won’t be around either. However, they will still be accessible if you know the URL for the screens.

We first learned this would be the case last year as part of the Gutenberg 9.3 release. There is also an open issue to ensure that the site editor has feature parity with some core WordPress settings.

It is OK that these features are being phased out for block theme users. They were all early, disparate attempts at creating individual pieces of what the site editor will allow. WordPress is bringing all of these concepts together into a more cohesive user experience. It is a standard that contributors can continually iterate on. It will not be perfect out of the gate, but this first version in the core platform should fuel the feedback needed to improve it as more users start installing block themes.

The problem presented here has more to do with the plugin market. The customizer was initially built as a theme-settings tool and has primarily been used for that purpose. But, many plugins have tied various settings to it over its nine-year history. A search for wp_customize in the plugin directory pulls up over 1,400 results. The customize_register hook shows over 1,900. These are not necessarily exact matches for how many plugins actually add panels, sections, settings, or controls. However, it is an indicator that many are relying on it to present options to end-users.

So, we are back to the question at hand. What happens when a user installs a block theme, such as the upcoming Twenty Twenty-Two, while using a plugin that relies on the customizer?

It depends.

Some plugins like WooCommerce have already conveniently placed a direct link to their customizer panel/section in the admin menu. This will be a non-issue for their users. However, for everyone else, the customizer will seem to disappear entirely.

WordPress customizer screen focused on the WooCommerce plugin panel, showing the shop page.
WooCommerce customizer options accessible with block theme.

In a matter of weeks after 5.9, depending on how quick the adoption of Twenty Twenty-Two occurs in particular, we could be looking at thousands of confused users. Of course, all of this could change in the time leading up to the release. However, this is a conversation that needs to happen now.

“The concern here is for end-users,” said the anonymous questioner. “They will be looking at knowledgebase articles, directions in plugin settings, and more indicating where to look for the settings.”

At least at the moment, the onus is on plugin authors to address this for their own users. However, there are multiple pathways they may want to go down.

The most straightforward method is to follow the lead of WooCommerce. The plugin checks the gutenberg_is_fse_theme() conditional (note that this function name may change). If it returns true, the plugin adds a link directly to its customizer panel.

Linking to a customizer panel, section, or control is simple. Plugin authors can find the URLs in the developer handbook. They can also just copy the technique the WooCommerce team employed.

This is a quick method to ensure users do not lose access to their options if plugin authors cannot make changes before WordPress 5.9 lands.

In the long term, it is not the ideal solution. The customizer will be around for a long while, but plugin authors will need to deal with two sets of users: those running both block and classic themes.

Because each plugin is different, solutions will need to be different. Many can simply use the Settings API to build a custom options screen. If that is a workable solution, it will not matter what theme the user is running.

However, the reality might be maintaining two systems for both sets of users. One that integrates with the customizer and another that pulls options into the site editor. If the plugin has design-related features, block theme users will expect to see settings in the new interface.

On the theming side of things, there should be fewer problems. A block theme does nothing with the customizer anyway. One outstanding issue would be converting starter content over, and there is an open ticket to bring that to Full Site Editing.

More than anything, keeping open lines of communication with users will help ease the transition. Some of that should come from core WordPress. However, many users will need to hear it from their plugin and theme developers. This might be blog posts, knowledgebase or tutorial updates, and keeping up with support.

Then, there is the final solution, one that WordPress itself could implement. It is also the path of least resistance.

WordPress should automatically detect filters or actions on customizer-related hooks. This should trigger a “customize supports” flag and maintain the admin menu and toolbar links to the customizer screen. This would give developers some time to catch up without confusing users in the process. There might be a few false flags or missed integrations, but it should be able to effectively catch the majority of use cases.


6 responses to “Ask the Bartender: What Happens to the Customizer When a Block Theme Is Active?”

  1. My gut says this should have been solved and considered when the Customizer menu item was removed. -And not postponed to a moment when the contributors have four weeks to merge the site editor, build the theme and EE -Everything Else. It is going to be a very hectic time.

    I believe the way forward is to use the editor components to create a new settings page, but I don’t know if the components or the developers are ready for that.

    • It is going to be a very hectic time.

      Yes, clients who simply wanted a website a while ago will start to ask why even stay with WordPress at this point, when there suddenly are bills for things which they never ordered.

  2. For years the it was advised to add visual settings to the customizer. And it was the right thing in my opinion.

    Now that there is something new in development. That is not even fully worked out and stable for a few month/versions so that developers could have time to adjust there (free/open) products to it. Suddenly the core is so arrogant to break all other developers stuff with full intention.

    WordPress celebrates itself for being backward compatible. This does not mean just the source code.
    From the Philosophies “Design for the Majority” also means to have a majority of developers in mind that have build on top of WP. Not all developers have the time to adjust there plugins and themes everyday to the latest Gutenberg changes.

    Because the core team is to lazy or ignorant to build a off ramp from customizer to FSE the solution is to offload the work to hundreds of support staff? Creating thousands of (unpaid) hours of work/communication. Something that could be prevented by putting in a few hours of development work.

    In stead the settings inside the customizer that have moved to FSE could show a notice and a link to the new place. Something well build software does like WooCommrece with there change of coupon menu location.

    Have we not learned anything from 5.0?
    Do we need another “Classic *” Plugin to fix the narrow view of the core development team?

  3. I know this is slight tangential but I really wish there was a different approach to the redevelopment. I wish they’d finish one part off before starting another massive upheaval.

    Currently we are in a transition toward FSE and new kind of template system, which will be great when it’s finished but lets be honest no developer with a big client site going Live in the next month has built it with a FSE theme. It’s not “there” yet.

    So – We create a site in August 2021 and deliver the site 1st November 2021. It uses PHP templates, because FSE and Gutenberg menus are in flux.

    We educate our clients to use Gutenberg to lay out their posts (rather than pasting tables in from Word Docs!) and we show them the Group and Column features and we say “please use this to put your picture in a block with text”. And the client tries it, and they ask questions like ” how di I increase the gaps between columns, I can see padding but not MARGIN”

    So we developers to try to explain:
    “well, that requires the new theme WP system to activate both margin and padding in Gutenberg – and theme.JSON is needed to activate the option, and we tried incorporating theme.JSON but it is not compatible with your theme because theme.JSON takes precedence over the … well, let’s just say it broke everything, it’s all in flux right now but WP team are apparently going to nail it by November this year at which point we can start to fix your new site….”

    And the client says “why doesn’t wordpress ever work simply, can’t we use something else?”.

    And we developers say “Oh it will work eventually, it will be AMAZING one day. And some good news – before they get the editor issues resolved they have already started changing how you will update menus, and styles, and layouts too”

    And the client says “That sounds like more confusion and problems!! So when will that happen, surely that’s years away … will it work OK on our site?”

    and we say “In November 2021 everything I did in September 2021 will become incompatible, or legacy, and there will be more forks and bug chasing – and no it will not work”

    And the client says “but why didn’t you build the site in FSE / Theme.JSON in September” and we say “because as I looked at the development state of FSE I began contemplating a new life as a wood carver, deep in the forest. A good honest reliable job, something with material continuity, reliability, stability “

    • My thoughts too…
      I’m constantly busy with fixing stuff, I coded before and now there’s a Gutenberg-button for what I had coded and it either overrides my stuff or the button doesn’t work. Both is distracting for my clients.
      I tried out FSE for a small project but ultimately abandoned the block-theme-approach, because the warning banner was more confusing than did help.
      I wish they would give it more time. But it happened with Gutenberg and it will happen with FSE. Merry Christmas! :-) At least, I know, sites will not break with 5.9.

  4. As a normal user, I am relaxed about the matter. Either I use an “old” theme. Then nothing seems to change. Or I’ll start over with a block theme, then I won’t miss the customizer. I have not installed a plugin on eight websites that is hooked into the customizer.
    But I also understand the concerns of theme and plugin developers.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: