Idea: using the group block in synced patterns as a freeform content area (via pattern overrides)

[talldan]

What problem does this address?

In my own usage of the block editor, I'd find it useful to add sections to my posts that have a predefined style/layout, but would still allow me to add freeform 'blog' style content (an unbound amount of paragraphs, images, videos etc) within those sections. Right now I use unsynced patterns for this, but that means I can't manage the design aspects of these patterns.

This is a shortcoming of pattern overrides currently. Only a few blocks can have specific 'content' attributes overriden in instances of a pattern. Even if more block types and attributes are allowed in the future, those blocks are locked in place and the user can't move them (which is an advantage for some types of content, but a disadvantage for others).

In the future I think there might be space for different ways to edit content in synced pattern instances using overrides.

What is your proposed solution?

UX

I think it may be possible to solve this by allowing pattern overrides on a group block. For a user, the process would be the same as declaring an override on any other block. Click the 'Enable overrides' button and name a group.

Some default blocks could be added within the group as part of the pattern.

When inserting an instance of the pattern, the group's inner blocks would be a completely unlocked part of the pattern with the user able to add/remove new blocks freely.

The group block also supports an allowedBlocks prop, so that would open up some interesting editorial/workflow possibilities, like only allowing basic text and media blocks as a preset.

Technical solution

The inner blocks for these groups need to be saved somewhere, but I think it would be ok to save them as part of the pattern block's inner blocks when serializing:

<!-- wp:block {"ref":338} -->
<!-- wp:group {"metadata":{"name":"Section freeform content"}} -->
<div class="wp-block-group">
<!-- wp:paragraph -->
<p>This is freeform content within a pattern.</p>
<!-- /wp:paragraph -->
</div>
<!-- /wp:group -->
<!-- /wp:block -->

Only the container blocks that are enabled in this way would be serialized, and it would be possible to support multiple container blocks in a pattern that work this way.

When rendering post content server-side, the content of these named groups would be copied into the correct container blocks.

In this way it works a little bit like slot/fills.

Considerations

• The server side content replacement might be very pattern specific, I'm not sure if it makes sense to still use block bindings for this, or are there are also ways block bindings could leverage this kind of feature? E.g. saving block markup to a custom field?
• It moves away from the idea of a pattern schema, though potentially the two can live side by side.
• This could also remove lots of the use cases for unsynced patterns. I think users mostly detach patterns to allow more freeform editing.
• Interestingly, I think it means patterns start encroaching on templates, the post content block works similarly to what's described above.

[fabiankaegy]

I really like the idea of this. Currently, we often have to build custom block wrappers that then have an open inner blocks area. Pattern Overrides in general still have the limitation, due to it's usage of contentOnly locking, of not even allowing the addition of new list items / buttons as described in: #52018

[talldan]

Pattern Overrides in general still have the limitation, due to it's usage of contentOnly locking, of not even allowing the addition of new list items / buttons as described in: #52018

Yep, I think this is one area that makes me hesitant at the same time. I think there could still be separate solutions for blocks like list/buttons, those containers that have one supported inner block type (gallery and social links are maybe others) and aren't really freeform.

I think this might be good so that contentOnly can still be leveraged (but with additional features like adding/removing list items). That would allow creators to do things like setting a list style that can't be modified, or maybe setting the min/max number of blocks.

I would be hesitant of too many solutions for this kind of thing, but at the same time I think a freeform area in synced patterns would be quite a powerful feature.

[carlomanf]

• Interestingly, I think it means patterns start encroaching on templates, the post content block works similarly to what's described above.

Over at #37753 a good point was made about "template tag" blocks being facsimiles of generic blocks (e.g. Post Title and Site Title being facsimiles of Heading) that would be better implemented as block bindings within the generic blocks. I guess the point quoted above is the same point regarding Post Content as a facsimile of Group.

Accordingly, the solution described here could enable post content data to be a block binding source for Group, and would be a better solution to #41073 which I would be happy to close in favour of this issue.

[youknowriad]

Great idea indeed. For me this means "inner blocks" support for block bindings. It's important that the implementation of such feature is not pattern overrides specific and would allow any block bindings source to inject blocks.

[eric-michel]

This is the holy grail of hybrid template / freeform editing and is something I've been dreaming of since the block editor was introduced. I agree with @youknowriad that making InnerBlocks support bindings is the way to go, which opens the door for many other block types to activate the same functionality (including custom blocks).