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

talldan commented 4 months ago

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 commented 4 months ago

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: https://github.com/WordPress/gutenberg/issues/52018

talldan commented 4 months ago

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: https://github.com/WordPress/gutenberg/issues/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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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).

talldan commented 3 months ago

Another good use case for this will be nesting patterns. For example you could have a section that contains a header, images and an overridden grid/columns, and within the grid/columns you could nest card patterns. That allows for pretty cool composition of patterns.

mtias commented 2 months ago

With the ability to now express allowedBlocks directly in the markup this makes a lot of sense. I can see serializing these as nested elements. Curious if naming the group blocks is the only thing needed to now where to allocate these if you have more than one group block.

Side note, but we need to expose allowedBlocks in the Advanced UI of the group block as well, it's a super powerful feature. The UI can be similar to the block manager.

talldan commented 2 months ago

I've also been thinking on the idea of composing patterns. An example use case I have in my head is a pricing table pattern. It has a 'freeform' columns block, and by default there are a few columns, and each has a pricing-table-card pattern within it showing some placeholder content (name, features, pricing).

A challenge would be that when the user appends an additional column, the new column is going to be empty whereas I think it could be populated with the pricing-table-card pattern. The user could fuss around with finding that pattern in the inserter, or duplicate the column, but I think it'd be better for the appender to insert the right content or suggest the right content for the column by default.

This use case isn't limited to only pricing tables, it's illustrative, there are plenty of situations where a pattern designer would want users to insert consistent content into columns, grids and other types of lists.

Some kind of allowedPatterns or suggestedPatterns API might work, or perhaps even allow pattern slugs in allowedBlocks. It could also be an entire category of patterns that's allowed/suggested.

This might be a few steps ahead of where we are right now, but it's good to think about how these things can be configured.

Faton1995 commented 1 month ago

Hello, I would say my suggestion also fits here.

https://github.com/WordPress/gutenberg/issues/63878

gziolo commented 3 days ago

Quoting the issue created by @liviopv:

https://github.com/WordPress/gutenberg/issues/59606

What problem does this address?

For the Buttons Block (and eventually other blocks like List, Group, Column, Cover, Gallery), users might want to create patterns where all the nested blocks can be overridden, not just specific nested items. There should be a setting inside the parent block give users this option

What is your proposed solution?

Add a "Allow overrides in all nested blocks" option for blocks that only accept one type of nested block like Buttons, List, and Gallery

Add a "Allow overrides in nested blocks that support it" in blocks that can accept multiple types of blocks, like Group, Column and Cover.

It might be a good idea to consolidate these two issues and expand the scope for this one.

WordPress / gutenberg