Connect "Section Styling" with "Pattern Overrides"/ "Content Only" locking

[fabiankaegy]

Section Styling/Colorways is a really powerful new feature getting introduced in WordPress 6.6. Currently, it allows users to switch between the different available options via the styles Inspector Controls options.

At this point, any controls rendered inside any Inspector Controls are not accessible for a block that has contentOnly locking applied, which is also the mode used by pattern overrides.

From my understanding, the goal of contentOnly locking was to provide a simplified editing experience where a user doesn't have to think about composing blocks and configuring all the options. Instead, users can only enter content / configure very basic options.

To me, this goal would extend to switching between different color variations of a contentOnly locked area if the wrapper block that has the locking applied supports any section styles.

Because of that, I propose we combine these features and expose the "Styles" switcher for the top-level block that has content-only locking applied.

[fabiankaegy]

@talldan @aaronrobertshaw @richtabor @jasmussen I'd love to get your take on this :)

[annezazu]

I worry that will dilute contentOnly but I'm curious how we can help them play well together as I agree this would be a neat combination.

[aaronrobertshaw]

Thanks for the ping @fabiankaegy 👍

At this point, any controls rendered inside any Inspector Controls are not accessible for a block that has contentOnly locking applied, which is also the mode used by pattern overrides.

I believe the zoom-out mode feature being worked on will eventually provide the ability to cycle or shuffle through available section styles. Something similar to how sections/patterns of the page might be shuffled.

There could be an issue somewhere that covers that but I couldn't put my finger on it. @scruffian, @draganescu and others might know better.

[talldan]

I think synced patterns right now are missing some features that allow them to act properly as sections (the missing shuffle button is one), but I think it's something that needs to be addressed.

An interesting aspect is where to apply the classname to the synced pattern for the section style, since there's no wrapping element output by the pattern block on the frontend. Perhaps the block styles for the wrapping block in a pattern are an override (it'd be an override of the classname attribute), and that's how it could work. It needs some consideration around how that's configured.

This is the exciting part though, where all the different projects that have been worked on start to converge 🎉

[fabiankaegy]

In the context of custom builds, I don't think the shuffle button is the right solution. The experience needs to be predictable and repeatable.

As an editor, all I want to be able to do is select whether I want this section to appear with a light, dark, or primary background color.

Without this feature one would have to maintain 3 pretty much identical versions of every pattern which adds a lot of additional maintenance overhead.

An interesting aspect is where to apply the classname to the synced pattern for the section style, since there's no wrapping element output by the pattern block on the frontend. Perhaps the block styles for the wrapping block in a pattern are an override (it'd be an override of the classname attribute), and that's how it could work. It needs some consideration around how that's configured.

@talldan yeah it is an interesting challenge. The way I would love it to work is as an actual override of the style that has been applied to the wrapping element inside that pattern. So any is-style- class should get replaced with whatever section style the user selects.

[scruffian]

There could be an issue somewhere that covers that but I couldn't put my finger on it. @scruffian, @draganescu and others might know better.

I think it's just an idea that someone shared, but not much thought has been put into how exactly it would all fit together yet.

[bacoords]

On another thread I wrote of one idea for an approach:

The templateLock attribute itself could be expanded to take an object of values

Looking at it now, I think just adding more options to the "lock" attribute would also be helpful if templateLock wasn't updated.

Regardless of the method, I think this level of extensibility will become more critical going forward. ContentOnly locking is very powerful but also very restrictive. It would be great to have more granular control when setting "templateLock" like the ability to "unlock" specific block attributes, section styles, or the inserter for innerblocks.

Right now there's two different "lock" mechanisms that have overlapping effects, but could be consolidated into one concept of "locking" templates, with settings that more closely resemble the locking we can do in theme.json.