Always display Customizer menu item

[Mamaduka]

Description

The team discussed this change during WP 5.9 project board triage today. Without full feature parity, it seems reasonable to always display the Customizer menu.

Features that require Customizer and don't have Site Editor alternatives:

• Site Editor: not possible to change site icon #29126
• [Block Themes] Consider an FSE-compatible approach to starter content #35680

How has this been tested?

• Appearance -> Customizer sub-menu item should be visible.
• You should be able to modify.

Screenshots

Types of changes

Backward compatibility

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[Mamaduka]

Maybe we should also remove the "Menus" and "Additional CSS" sections for Block Themes?

[aristath]

Maybe we should also remove the "Menus" and "Additional CSS" sections for Block Themes?

Makes sense to me

[Mamaduka]

Thanks for the confirmation, @aristath. I've removed those panels.

Screenshot

[aristath]

Tested and confirmed.
Code looks good 👍

[youknowriad]

I think this is a mistake. If we keep the customizer at start, we'll never be able to remove for backward compatibility reasons. My personal opinion is that it's fine to not have full parity for block themes for V1. For people that still rely old features from the customizer, they should stick with a classic theme.

[Mamaduka]

@youknowriad, we still have to display a customizer menu for plugins that rely on it - #35877.

I think we'll be able to remove the menu item, and there will be yet another "Enable X Feature" plugin.

[youknowriad]

Switching a theme is a conscious decision and not something done automatically on upgrade, so I think it's fine if there are some plugins that don't show up when you use an FSE theme. Of course, we'll need dev notes... but using an FSE theme is an impactful thing anyway and accessing menus is not the only thing that will potentially break. I think if a plugin really wants the customizer back, they can enable it on their own.

[Mamaduka]

I think if a plugin really wants the customizer back, they can enable it on their own.

I think this is what WooCommerce is doing.

I don't have a strong opinion on this one, happy to revert the change or create alternative PR. However, it would be nice to hear more thoughts on this.

/cc @noisysocks, @kjellr, @jffng, @jasmussen.

[jasmussen]

One thing I'd like to see is a better, more unified and simple place for plugins to store their options, so people don't have to go look for them in various places. For a block theme, the customizer doesn't feel like an obvious place to go look for such things, so in that vein I lean towards Riads suggestion: if a plugin can enable the customizer, that can be a good path forward.

[priethor]

I think if we introduce block themes and the block theme editor while keeping the customizer in the admin menu, we are missing the opportunity to set expectations for block themes and bock editing in general, both for users and theme/plugin authors. Users might default to using the customizer instead of adopting the block theme editor (learning new tools can be challenging and requires effort), which can make it very difficult to move forward from an optics point of view.

As @youknowriad says, plugins can always opt into the customizer if they need it. As a more advanced alternative, @noisysocks also shared a WPTavern suggestion to automatically detect hooks and filters that require the customizer and enable it.

[Mamaduka]

@priethor, we had filter detection in place and can revert to it. See #35877.

[priethor]

Thanks for pointing that PR out @Mamaduka! I hadn't seen it merged yet 🎉

Doesn't this PR make #35877 obsolete, though, as it will always show the customizer regardless of the filter? I think we should favor the solution in #35877 for 5.9. #35892 is close to landing, too, which is also a good compromise to allow changing the site icon without the customizer in this first version.

[kjellr]

It sounds like others have already voiced this strongly, but I agree that surfacing the customizer doesn't seem right for this release.

Yes, it theoretically solves #36168, however in 5.9 I think the customizer is a pretty outdated place for folks to start their site-building experience (especially if it just contains Site Identity and Homepage Settings), and I'd strongly prefer we have something in place that leverages our new features. Many experienced folks will land in the customizer and mistakenly think that there are fewer options for customizing their site than there were in the past.

[aristath]

My 2 cents:

I agree with the above that the customizer is an outdated place for settings in a block theme, and IMO it's also completely inconsequential.
I can't think of any valid scenarios where the customizer would be used in a block theme... Even in the case where plugins add options in the customizer.
The customizer controls visual & in some cases, structural aspects of a site.
In block themes however, everything is a block. Any content added by a plugin will be done using a block - and therefore the options for the block belong in the block itself (that includes Woo products etc).
As for the structural changes that some themes were doing using the customizer, that's a moot point since everything is done in the site-editor.

It's true that global options don't currently support all the things that the customizer did.
But they don't have to, that's the beauty of it. Want to change the appearance of your content, comments, header, whatever? Go to their respective blocks and do what you need to do.
In a block theme, nothing can be not-a-block, so I really don't see the point of having the customizer menu item show.

[mtias]

Let's aim for having it disabled by default on the first betas for themes created with blocks. It'd be important to properly test the proposed IA — its benefits and shortcomings — to have a streamlined admin flow without confusing bifurcations. We can always restore it if that's where the feedback leads. We should still attempt to enable it automatically if any plugin (or theme) has functionality hooked into it.

[noisysocks]

I think there is some confusion here. Let me go over the timeline of how this evolved so that everyone is on the same page.

Previously, we were always hiding the Customize link. Plugins such as WooCommerce will re-add the link if they use the Customizer to display settings. The problem with this though is that multiple plugins will re-add the Customize link causing duplicate links.

Therefore we implemented #35877 which makes WordPress automatically show the Cusomize link if it detects that a plugin is using the Customizer to display settings.

I believe this is an elegant solution and it's my preferred approach for WP 5.9.

However, we're a day out from the feature freeze date and have no solution for two limitations of the Site Editor:

• Inability to change the site icon Site Editor: not possible to change site icon #29126
• Inability to see starter content [Block Themes] Consider an FSE-compatible approach to starter content #35680

Always displaying the Appearance → Customize link allows users to work around these two limitations. This is why we opened this PR.

I am okay with—in fact, I'd prefer—reverting this PR and going back to how things were after #35877 but to do this we need to address #29126 and #35680.

Since there is strong opposition to always showing the Customize link I will revert this PR and allow #29126 and #35680 to be addressed after the feature freeze date next week. Please help out with those issues if you are able to.