Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
talldan opened this issue Apr 30, 2024 · 10 comments
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) [Type] Enhancement A suggestion for improvement.

Comments

@talldan
Copy link
Contributor

talldan commented Apr 30, 2024

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.
@talldan talldan added [Type] Enhancement A suggestion for improvement. [Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) labels Apr 30, 2024
@talldan talldan changed the title Idea: allowing group (and other container) blocks as pattern overrides Idea: supporting the group block for pattern overrides as a freeform content area Apr 30, 2024
@talldan talldan changed the title Idea: supporting the group block for pattern overrides as a freeform content area Idea: using the group block in synced patterns as a freeform content area (via pattern overrides) Apr 30, 2024
@fabiankaegy
Copy link
Member

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
Copy link
Contributor Author

talldan commented Apr 30, 2024

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
Copy link

  • 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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor Author

talldan commented Jun 6, 2024

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
Copy link
Member

mtias commented Jun 20, 2024

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
Copy link
Contributor Author

talldan commented Jun 21, 2024

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
Copy link

Hello, I would say my suggestion also fits here.

#63878

@gziolo
Copy link
Member

gziolo commented Sep 9, 2024

Quoting the issue created by @liviopv:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

8 participants