Add slug field to user created patterns

[goodpenguins]

What problem does this address?

This allows you to safely use reusable blocks in patterns.

The Real Challenge: More than 70 posts will use a set of blocks consisting of three static (headings and texts) and one dynamic block.

The easiest way to solve this problem is to create a pattern with synced pattern for static elements. It's convenient to store the generated pattern in the theme's "patterns" folder instead of including it in the theme's code.

The problem is that synced pattern blocks only have an id. In the HTML code of the pattern, they are called via ref={id}. But with a high probability in the development and production environments you will have different id of the same reused blocks. To solve the problem, one could set up different pattern folders depending on the environment variable ( WP_ENVIRONMENT_TYPE ). Unfortunately, I did not find a hook to change the path to the patterns folder.

What is your proposed solution?

Add a slug field to the reusable blocks and enable linking by this field (ref={slug}).

[talldan]

@goodpenguins It'd be good if you could expand a bit more about your use case. I'm not fully understanding why a reusable block in a pattern solves the problem for you.

[carlomanf]

@talldan I think the point is being able to keep a section of the pattern in synchronisation after the pattern is inserted. The question I have is why a template part would not suffice for this purpose.

[talldan]

I guess if it needs to be inserted into the middle of post content, it might be tricky to use a template/template part. But yep, my first thought was also the same.

There is also some upcoming work on patterns that may help solve this issue.

[goodpenguins]

OMG, you all are right. I thought of template parts more like large sections. Indeed, the tempate part can solve this problem. Thanks for the reminder.

[goodpenguins]

I'm closing this issue. Thanks you.

[goodpenguins]

I reopened the issue because the template parts don't solve the issue. I confirm that the point is, as @carlomanf aptly pointed out, to keep the pattern in sync after it has been inserted.

Example to explain the situation.

Imagine that in a large number of posts you need to have a preset set of blocks of 2 columns with static and dynamic content.

Static content (orange) you will obviously want to make reusable blocks. But according to the situation, the dynamic block has its own local context (for example, a list of Query Loop posts for the taxonomy selected here).

In other words, you cannot use the global post context, so template-parts and a reusable block containing these nested reusable and dynamic blocks are not appropriate here. You also cannot place a child Query Template on columns added to a Query Loop.

There are two approaches to the solution.

1. Write your own parent block that sets the context for nested blocks. This is only appropriate if your child dynamic block can recognize this context.

2. Make a pattern.

<!-- wp:columns -->
<div class="wp-block-columns"><!-- wp:column -->
<div class="wp-block-column"><!-- wp:block {"ref":110} /-->

<!-- wp:query {"queryId":14,"query":{"perPage":3,"pages":0,"offset":0,"postType":"post","order":"desc","orderBy":"date","author":"","search":"","exclude":[],"sticky":"","inherit":false,"parents":[]},"displayLayout":{"type":"list"}} -->
<div class="wp-block-query"><!-- wp:post-template -->
<!-- wp:post-title {"level":6,"isLink":true} /-->
<!-- /wp:post-template --></div>
<!-- /wp:query --></div>
<!-- /wp:column -->

<!-- wp:column -->
<div class="wp-block-column"><!-- wp:block {"ref":111} /-->

<!-- wp:block **{"ref":112}** /-->

<!-- wp:block {"ref":113} /--></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->

And here is the original problem {"ref": reusable block ID }. Reusable blocks do not have slugs. If your environments do not have full object ID synchronization, you will need different patterns for the same needs. As I wrote in the initial post in Wordpress there seems to be no hook for the path to the "patterns" folder, so there is no way to specify the path to the patterns via an environment variable.

[carlomanf]

Why don't template parts solve the issue? As you pointed out, reusable blocks don't have slugs, and as I pointed out, template parts do. In your example, you have reusable blocks 110, 111, 112 and 113, which could each be a template part with a slug instead. 111, 112 and 113 could even be merged together into a single template part, surely?

Or is the issue that you need to be able to centrally control the attributes of the columns block as well?

[goodpenguins]

@carlomanf you are right. It will work.

pattern:
  columns:
     column:
         template-part 1
         dynamic block
     column:
         template-part 2
         template-part 3
         template-part 4

I don't think it's a 100% good idea to create a template part for a piece of content, but yes, it will work.

In this case, I did not set the task of managing the layout, but in real life it is necessary. It seems the ideal solution would be a reusable block with slot for undepended dynamic blocks.

[carlomanf]

It seems the ideal solution would be a reusable block with slot for undepended dynamic blocks.

I agree that the "slot" concept is the ideal long-term solution, which I vaguely suggested a year ago and someone else described more clearly in the issue that @talldan linked to. It would be good to open a new issue to specifically discuss the "slot" concept and how it might be implemented.

[goodpenguins]

@carlomanf thanks a lot for the provided pointers. Everything seems to be moving in the right direction, including blocking those template elements that should stay in sync and leaving others free. It seems to implement the concept of slots, although it does not call it that. I haven't explored everything yet, but it's very interesting. I will follow.

[jordesign]

Just looping back to this issue - @goodpenguins does the new introduction of synced and unsynced patterns help resolve this issue?

[goodpenguins]

Hey, thanks for getting back to the problem. It seems to me the new synced pattern does not solve the problem. I just checked it and find no slug or slot (((.