FSE: A method to disable access to Site Editor > Styles

[unscripted]

Our agency develops custom themes for our clients. We are shifting to FSE and running into challenges specific to access to Site Editor > Styles, where changes in the editor may not make it back into the version-controlled theme. Below are two scenarios that highlight the issues we've encountered.

Multiple hands
During the build, a non-dev team member changes a global setting in the editor. Meanwhile, another team member is continuing to make changes directly within the theme.json file. The committed changes are not displayed on the front end because the custom style is now in use.

Clients
As an agency, we often adhere to the client's brand guidelines. After the site launch, a client team member may inadvertently change a global style without the knowledge that they just changed a lot of things. This then becomes an unnecessary support issue for our team to resolve.

Neither of these scenarios is critical, and there are workflow steps we've attempted to put in place to prevent them. However, the ability to disable access via a wp-config.php setting (similar to DISALLOW_FILE_MODS) or another way would be awesome.

Has anyone else run into a similar issue or have a potential solution?

[annezazu]

Thanks for kicking off this conversations! This seems like a good thing to create and document for this resource: https://developer.wordpress.org/block-editor/how-to-guides/curating-the-editor-experience/

If anything, I've been hearing the opposite with folks wanting to expose the Styles UI for classic themes: #41119

Depending on where this discussion leads, let's make sure to create an issue if it comes to it!

[unscripted]

Thanks, @annezazu! While different, I like the proposal in #41119 as well.

We love the Styles UI and see it as a super powerful tool. It's even better for devs when paired with the Create Block Theme plugin. However, with great power comes great responsibility. [insert bad Spider-Man meme]

Another option our team discussed was the potential of using the WP_DEVELOPMENT_MODE constant paired with the wp_is_development_mode( $mode ) function to enable or disable access to the Styles UI.

[MattMcAdams]

I'm part of a team that develops a block theme for use at a large university. Because we have strict brand standards, almost all styling options are NOT decisions content creators get to make.

Its good that we've been able to largely restrict block settings with theme.json, but it seems as though the FSE Styles tab just ignores all of that. For example, we have typography settings set to false yet the user can still manipulate paragraph text size through this menu.

If there was a way to simply disable the styles panel, it would make a huge impact on the viability of block themes at our institution. If there is a way to manage what options are available on the Styles page, we may be able to disable them piecemeal, but I haven't found a way to do this either.

[unscripted]

@MattMcAdams - Have you explored the "templateLock": "contentOnly" attribute? @richtabor has a great post on Content-only block editing. We use this with some clients, but it has major disadvantages when used at scale or when working with list items.

We're excited to see what's happening with the upcoming ability to override content in synced patterns, but we will have to wait and see if we can use it to solve this problem.

Ultimately, we still wish we had an easier way to restrict this for our clients with strict brand requirements. Internally, we built a mu-plugin that works similarly to what @t-hamano suggested below, where we disable the Site Editor. This helped, but isn't perfect.

[t-hamano]

Access to the Global Styles is determined internally and currently will always be accessible if it is a block theme.

On the other hand, the Site Editor itself cannot be accessed without edit_theme_options role, so if clients do not need to edit templates, template parts, or patterns, one option is to exclude this role from the user account distributed to clients.

Alternatively, although this might not be a recommended method, you can probably remove it visually using CSS.

[bridgetwes]

Is this still being looked into? There's quite a mix of content clients need access to edit, and styles they can mess up within the single edit_theme_options capability. Clients usually need to edit their site menus. It is nice to allow clients to finally be able to edit their 404 page, and header/footer (and also easily controlled so clients can't mess up something big by locking blocks and the block_editor_settings_all filter / canLockBlocks setting).

But gosh, no, I don't want clients adding fonts or changing my carefully crafted text/headings/colors. Can some finer controls be added so it's possible to block a user from changing their site's Global Styles while also allowing them access to edit other content in the Site Editor?

[unscripted]

It's definitely something that my team is still working to resolve internally.

Navigation and synced patterns are two of the main issues we've ran into recently.

Do you have a list of features you'd want your clients to always have access to?

[bridgetwes]

Are you building something that might become a plugin, or working on WordPress itself? It seems we having similar issues with client access. Personally, I'd like to give the Editor Role access to the edit_theme_options capability so they can edit content in the Site Editor, but not change things in Styles. I started hiding Styles with CSS for the Editor Role, which isn't ideal because a sneaky user could figure out the path to Styles.

Are you also having issues with Exporting the theme (either through Export in the Site Editor, or the Create Block Theme plugin) and patterns getting messed up, renamed, or not exporting? I'm having trouble with this, and it is making it pretty much impossible to keep the theme version controlled or share changes with another developer working on the site. Navigation also gets messed up and has to be recreated after an export.

[t-hamano]

I found an interesting issue, so let me share it.
If a routing API is implemented and expanded, some issues may be solved.

#60584