dmsnell
commented
2 years ago These don't need to exist in the final render, right? Or do some kind of collected settings need to persist into the front-end, for example, for interactive view-time blocks?
If we have a need to pass through the organization to the rendered site, whatever that entails, then a group block seems not only a workable option but also a fairy central use-case for why the group block exists.
If, on the other hand, we mainly want to organize content inside the editor I wonder if we couldn't play a trick with the block system whereby we have a EditorGroup block that exists while editing, but is actually a normal block like the group block, just one that WordPress removes by default on render.
It would behave like the group block to collect a pattern's blocks, would be able to provide cascading data to its inner blocks, but the render filer on the server would strip it away leaving no div or any actual HTML tag in the output.
simison
jameskoster
nerrad
johnstonphilip
annezazu
SaxonF
carolinan
luisherranz
mtias
critterverse
Since their inception, patterns were meant to be a very thin layer that just collected some blocks without any additional structure imposed on the block tree. This has many advantages for the way patterns are transported, inserted, shared, validated, and combined. However, when it comes to building templates and specialized pages, there has been a growing need for patterns to be more stable units at the root level of a document so that there can be an editing experience that focuses more on the larger placement of sections and less in its inner details.
Many ideas in the drawing board we want to work on — like a zoomed out view where you interact with sections only — depend on this structure being in place. The goal of this issue is to describe a possible path for combining many of the techniques developed so far that can allow patterns to be used as more controlled design elements, with more limited editing but very expressive capabilities.
This affects both insertion and editing. The step to get there is relatively minimal given all the tools we have already developed.
Block Type or Variation
There are mainly two ways to go about implementing these new sections:
Each one of these approaches has pros and cons. The block type approach means that all the specific behavior is tied and colocated clearly in a defined block type. The downside is that the editor can’t support wrapper-less blocks easily, which means that we do need an extra div in both frontend and backend for each of these sections, and that container needs “layout” support as well.
The variation approach means that we don't need extra containers, we can just turn any part of existing templates/patterns to sections by setting a flag. We can reuse the current “styles” attribute and introduce a new “settings” attribute for these section variations. It'd also make it easier for other types of containers (Columns or third-party blocks) to also opt-in into some of these behaviours if we express them as
supports.A combination of the two can also be explored through the
wp:patternblock that is available for themes.Related: #27324.
Style Partials (theme.json)
There's a growing need for patterns to define visual aspects that can cascade to their child blocks. Right now this works either by establishing these attributes on a parent that supports them (like "color" in Group) or by repeating the style on every children. This is obviously inflexible for patterns that aim to have and retain more control.
The good thing is we already have a system to achieve this with
theme.json, which was designed to provide styles and settings to control how blocks look and behave. It currently works at a global scale but making it work for sub-structures has been on the roadmap for a while (primarily targeted for specific templates, pages, and parts).We can apply this technique of
theme.jsonpartials to these controlled patterns quite elegantly as well. Since the json config allows control over default styles, presets, elements, and settings, the expressive capabilities become a lot more interesting. This would allow patterns to exist as a harmonic unit, where child blocks are kept in check — for example, disabling specific design tools from them, or registering a restricted palette (imagine a "dark" element on an otherwise "light" site) that govern the look and feel of that section. We can think of it as a theme.json that is specific to a given section.Another opportunity that opens up is the ability to offer style variations at a pattern level (the encapsulation of presets across all the available customization options) using the exact same mechanisms we have for global styles.
Related: #38167.
Locking and Absorb Toolbar
The ongoing work on locking mechanisms (#29864) is also a huge lift that when combined with UI settings like the "absorb toolbar" can provide a pattern editing experience that seems like a single entity even if composed of child blocks.
Generally, to achieve the best user experience when designing a page or template using pre-built patterns or “sections”, it is important to avoid surfacing all the inner blocks and low level building elements of that section. Users should be able to style and interact with these sections as a single unit and potentially dive into the smaller bits for advanced customizations.
If we combine the locking provided by the
lockattribute, the inner blocks template, and what can be achieved withtheme.jsonsettings, we can achieve almost any degree of customization and control.Right now, the editor optimizes by default for bottom-up customizations (clicking a paragraph in a section selects it first and the discoverability of the parent section become harder to reach. Given the children would be locked, we can also surface the movers of the parent even when a child is locked since we wouldn't have the issue of duplicated movers.
Cycling through Patterns
By having stricter structures that can be edited but not rearranged, transforming between different designs becomes more straightforward beyond what we achieved already for semantic template parts (headers and footers). This can allow a user to cycle quickly through variations of a section pattern while retaining its content customizations. While we have these features already in the ability to transform a pattern into another pattern, this can significantly simplify how these patterns are connected.
This is a feature we can surface in the container block toolbar, for example, in addition to the carousel explorations we added for template parts.
There's a question of how to conceptualize these variations (consider a pattern with an image, a heading, some text, and a button, arranged in different ways but with the same overall elements) when defining or registering patterns. We should look at it from the perspective of the patterns directory as well.
It's also important to discriminate between cycling between patterns that have the same elements and replacing a pattern / section with something else entirely. The latter we already support for template parts, for example. In the case of patterns, we should probably still retain the two, since you may cycle between variations of a "call to action" pattern or aim to replace that section with an entirely different "hero" pattern.