Shuffle content blocks when templateLock is contentOnly

[jameskoster]

When a container has templateLock is contentOnly applied, it would be neat to offer a way to cycle between patterns that utilise the same 'content' blocks.

Here's a demo:

Note how the layout / colors etc change, but the content blocks (heading, button, image) remain consistent.

[jameskoster]

I suspect the details of this one (the icon, it's position in the toolbar) can be ironed out during implementation. Marking as needs dev and sending a ping to @WordPress/gutenberg-design for feedback on those details :)

[javierarce]

This is neat!

If this is not going to be random I think that the reusable-block icon could be more appropriate to communicate the idea of cycling between patterns.

Maybe we could add the number of patterns on the label: "Cycle through 3 patterns"

[paaljoachim]

A very cool idea James!

Actually I would like to see this also apply for template parts. A cycle through to test out various headers and footers or other template parts as I experiment with various designs while in the Site Editing mode.

[richtabor]

A cycle through to test out various headers and footers or other template parts as I experiment with various designs while in the Site Editing mode.

Agreed. "Replacing" a template part is still a cumbersome exp.

[jameskoster]

If this is not going to be random I think that the reusable-block icon could be more appropriate to communicate the idea of cycling between patterns.

I agree, that icon can work well to begin with.

Actually I would like to see this also apply for template parts

Yeah that would be handy. I think the implementation would be slightly different though, so probably best to do that separately. Related: #44582

[javierarce]

@jameskoster after I published that comment I realized that if there are a lot of patterns, reaching the ones at the end of the list could take a while, and picking random patterns could actually be better.

[kevin940726]

Hi! I'm interested in giving this a shot! If I'm not mistaken, I think we should use the blockTypes field to search for matched patterns. I don't think most of the default loaded patterns have blockTypes set though?

[jameskoster]

after I published that comment I realized that if there are a lot of patterns, reaching the ones at the end of the list could take a while, and picking random patterns could actually be better.

Oh yes, I agree it should be random. I think the icon still works though.

If I'm not mistaken, I think we should use the blockTypes field to search for matched patterns. I don't think most of the default loaded patterns have blockTypes set though?

I'm not sure exactly how it works, but I believe blocks can be marked as having a content component? Ideally the shuffle functionality would count the number of content blocks in the container and cycle through patterns that include the same quantities. Any other block is ignored for the purpose of matching. IE a pattern with 1 heading and 2 paragraphs would cycle through other patterns containing 1 heading and 2 paragraphs.

[kevin940726]

Ideally the shuffle functionality would count the number of content blocks in the container and cycle through patterns that include the same quantities.

I tried this approach out but I don't think it worked out nicely in practice. We have this __experimentalRole field for each attribute, and they can be marked as content to allow editing in contentOnly mode. However, they don't have any semantic meanings, which means they will likely match very different patterns in result. For instance, a cover block pattern will match not only other cover block patterns but also any pattern that has a paragraph block. It could match a footer pattern or a text pattern. I'm not sure if that is what the user would expect?

Maybe we should use blockTypes instead, as that is defined by the block authors and can be conveyed their semantic meanings. Header patterns will only match their header patterns and footer patterns will only match their footer patterns.

Moreover, currently a navigation block (and some other blocks) is not considered a content block, but we should also provide the ability to shuffle to other navigation patterns as well. That is, a pattern with no content blocks should still have a list to shuffle.

[talldan]

@kevin940726 That's kind of where I came to when I thought about the problem in the past too. This was the past discussion and Matias' comment has links to related issues - #41397 (comment). They might be helpful for you to read through.

I also just saw this issue which looks related - #41606.

Using blockTypes as you suggest might be a decent start. Data loss might end up being a concern if the solution is too clever at finding other block types that aren't an exact match (although I guess there's always the undo button).

[kevin940726]

@talldan Thanks for the links! I was not aware of them. 👀

I tried the blockTypes approach but quickly ran into another problem: we have no way to obtain the blockTypes field from a set of blocks. Once a pattern is inserted (either from the pattern library or by pasting it from elsewhere), only the blocks data are preserved, all the other information about the pattern is lost. That is, we can't reverse-engineer the blockTypes from any given inserted patterns in the editor.

#30469 uses an approach to search for all available patterns locally and try to find a match. Unfortunately, that only works for simple blocks with no innerBlocks. Footers can only have a single core/paragraph block but we're not able to determine its semantic meaning from that. Furthermore, patterns pasted from elsewhere won't be recognized as well. I can't think of a way to solve this without having to introduce breaking API. 🤔

[talldan]

I tried the blockTypes approach but quickly ran into another problem: we have no way to obtain the blockTypes field from a set of blocks. Once a pattern is inserted (either from the pattern library or by pasting it from elsewhere), only the blocks data are preserved, all the other information about the pattern is lost. That is, we can't reverse-engineer the blockTypes from any given inserted patterns in the editor.

In this situation I think it'd be checking a container block's contents (i.e. group block) and comparing it to a pattern to see if it's a like for like swap. Would you be able to determine the block types that have the content role within a group and then check for the same block types in a pattern?

[jameskoster]

For instance, a cover block pattern will match not only other cover block patterns but also any pattern that has a paragraph block. It could match a footer pattern or a text pattern. I'm not sure if that is what the user would expect?

The footer example would be strange, although if the footer pattern only contains a paragraph it might be visually appropriate. In practise, a footer will likely contain a site title, site tagline, navigation, or some other content block which should prohibit it from appearing.

[annezazu]

@kevin940726 wanted to check in here! What do you need to get unblocked? We're coming up on two weeks since you were jumping in so I wanted to ensure you had the support you needed to keep this work going :)

[kevin940726]

@annezazu I'm working on a draft PR for a partial implementation so that we can discuss it further with a working branch. I'll polish it a bit and open it tomorrow ;)

[kevin940726]

I opened #45618 for further discussion on one of the approaches mentioned here 🚶

[ellenbauer]

I really like this. I wonder if it could even be extended to entire templates? E.g. if we have an About page and the user can shuffle the patterns to show variations?

We could create a similar result like AI tools are exploring (like durable.co) but with a bit of curation from the theme/pattern builder. Is this something this is explored already?

If we could define the patterns more precisely, for instance using categories, it could be a powerful experience for users.

[jameskoster]

A key principle of the shuffle mechanic is that the constituent content blocks remain the same every time. In that light I feel it's best suited to smaller patterns. That's not to say your suggestion isn't a good one, it is! But it feels like something we can explore more as a part of the page / template creation flows. You may be interested in #42325 which is somewhat related.

[paaljoachim]

I am adding a comment which might not fit in here. Anyhow here goes. I can always add it to another issue as well.

I believe a pattern block has been suggested in another issue. I find that an interesting idea.
Anyhow adding a pattern could include a cycle icon in the toolbar so that one can easily select the pattern group toolbar to cycle through available patterns for the specific category one selected it from.

Perhaps adding a pattern should have it add as a pattern group option. Kind of like a new Group block option along with the various other options that currently exist for the Group block.

More brainstorming.
Let's say that I change a standard Group block into a Pattern block. It now can be saved as a Pattern. I would need to select the category and select to Save it as a pattern. It would also need to be selected as a synced or not synced block (Reusable or not). This way the flow between a Group <-> Pattern would be much smoother experience. Because all patterns exist inside a Group block.

This means a Pattern is a kind of special Group block which currently exist in the pattern categories.

---

Actually one more thing came up while I was doing the latest call for FSE testing.
Adding in a pattern I had no way to change the pattern into a template part.
Adding to the above brainstorming.
Let's say that I add in a Pattern Group block. As long as I use this pattern option in the Group block I could have a way through the sidebar options to select which template part this should replace. Be it Header, General or Footer.

[annezazu]

Marking this as a backlog item at this point with this work being impacted by larger wp:pattern efforts #48458 yet being lower priority in comparison.

[jameskoster]

The full scope of pattern shuffling will likely be identified during #27575.