I'm curious why you chose to apply this content filtering at the pattern level, rather than somewhere else.

It seemed to be the best place for it, for our use case. On WordPress.org, the content is output via patterns, not post content (so that it can be translated and publicly version-controlled).

For example, the front page template has just a header, footer, and pattern. The pattern contains all the page content.

The same process is true for all pages on wp.org — About page template, content pattern; Features page template, content pattern; etc.

This way, the same theme can be used to render all the Rosetta sites: https://es.wordpress.org/, https://fr.wordpress.org/, and so on.

So hooking into render_block_core/pattern was an easy way to run these content filters only once on the page content. Possibly the only way, as looking through the code I don't see any place where the block content can be filtered once it's rendered for the template-canvas.

Thanks, that helps. Is it possible to apply these content filters on get_block_templates instead? I've been wondering for a while if we don't actually need a separate filter for post-processing the entire template content, that is separate from post-processing of post content (i.e., the_content ) as the current state of things is causing some filters to run twice (See https://core.trac.wordpress.org/ticket/55996).

Is it possible to apply these content filters on get_block_templates instead?

It looks like that applies to the template content before the blocks are parsed and rendered, so it wouldn't catch the markup from any of our server-side blocks. The nice thing about render_block_core/pattern was that it ran after everything else was built.

I've been wondering for a while if we don't actually need a separate filter for post-processing the entire template content

Yeah, that's pretty much what I'm looking for. In fact, the_block_template_html from WordPress/wordpress-develop#5188 would be great.

I've refreshed the filter approach in WordPress/wordpress-develop#6533.

There's also #61212 which proposes a filter for the entire HTML response (down to the html tag), which may be needed for the Interactivity API.

Just came here to note that this has broken a conditional/visibility system that I have in place, which I use when calling <!-- wp:pattern /-->.

Just came here to note that this has broken a conditional/visibility system that I have in place, which I use when calling <!-- wp:pattern /-->.

Could you elaborate?

I commented on my own PR here about running the filters: #61711 (comment)

I don't understand how this isn't a problem already: once you load patterns in the editor, they'll be resolved, and disappear on the next save.

It sounds like you want to preserve these patterns on the front-end. Maybe there's a way to only replace them when getting patterns for the editor? Maybe we need to remove the resolving from get_block_templates and get_block_template and only resolve for the REST API endpoint(s).

Here's my new proposal: #61757

@ellatrix - The new proposal looks like it'd resolve the issue.

Yes, this is for a system that's on the front end only when used for patterns. Templates in this case are not saved in the database. I can work around it by adding the conditional feature to a wrapping Group block around the pattern, but my main concern is for folks who have deployed it on existing sites using the Pattern block.

I don't understand how this isn't a problem already: once you load patterns in the editor, they'll be resolved, and disappear on the next save.

For my case, these are patterns that are not enabled in the editor. They're only called from templates, which are never generated from the database, only theme files. The pattern hooks were just a convenient place to run some code.

That said, I believe we've moved away from switching out pattern slugs in favor of filtering the template hierarchy (which seems more in line with how it "should" work). For the other things we've attached to the pattern render hook, the_block_template_html from WordPress/wordpress-develop#6533 works even better.

However until that merges, #61757 looks good and should let wp.org update gutenberg again.

There's also the potential for the wp/block (old reusable/new pattern block) to reference bundled patterns via slugs in the future (like template parts do), but the difference is the block wouldn't auto-remove itself. Not sure if that would help with any of the issues being mentioned.

It sounds like we should go ahead with that fix. Could anyone approve?