Patterns categorized as Headers and Footers should only be available in related Template Parts

[ianstewart]

Current status:

When using the pattern inserter you'll see a category of patterns labelled as "Headers".

Example:

Desired status:

These patterns should only be available when you are editing the matching template part in the site editor. In the case of headers, when you're editing your header template part. For footers, the footer template part.

When registering a pattern via a plugin one can formally declare this relationship:

https://developer.wordpress.org/block-editor/reference-guides/block-api/block-patterns/#semantic-block-patterns

'blockTypes' => array( 'core/template-part/header' ),

This may need to be adapted to how Patterns are delivered to the inserter on Dotcom through the Editing Toolkit.

[dsas]

These patterns should only be available when you are editing the matching template part in the site editor. In the case of headers, when you're editing your header template part. For footers, the footer template part.

@ianstewart, I'm struggling to find where that behaviour is documented upstream. Looking at the PR that introduced template-part specific patterns, it appears that it just limits the pattern selector when replacing a template part. Nothing prevents the header/footer patterns being used in other places.

ETK is already set-up for blockTypes support, and testing it, it works! The pattern meta from the API is parsed for block types and these block types are then used when registering the pattern. I can see block types in the response when using the API console.

I can see that the dotcom footer patterns don't have the proper pattern meta.

trim_SRb0or.mp4

[dsas]

Had a further poke through the Gutenberg block inserter and couldn't find any code that implements "patterns should only be available when you are editing the matching template part" but that might be down to my Gutenberg skillz :).

Testing on gutenberg upstream using the 2022 theme, I can see that the header patterns are registered with a blockType and they appear in the selector when using replace on the header template-part but I can also insert the same patterns into a page

[dsas]

Spoken to Matias and blockType only makes blocks appear in the relevant template part, it doesn't filter blocks out of the sidebar. This matches my testing above. There's an ongoing conversation to clarify the requirements: p1660842575737849/1660679319.921149-slack-C02M88KJ684

[dsas]

There are two parts to this issue:

1. Ensure blockTypes are used on appropriate dotcom patterns

This is done by setting block_type_core/template-part/header and block_type_core/template-part/footer pattern meta appropriately on the patterns site.

This looks correct for all published posts except two footers. I've checked for potential issues here and depending upon feedback, will make the change later. See p1660903274984409-slack-C02M88KJ684

2. Prevent such patterns from appearing in the sidebar inserter

block_type_core/template-part/header and and block_type_core/template-part/footer patterns shouldn't appear in the sidebar, they should only appear when replacing the header / footer template part.

This work might happen in Gutenberg directly, so we ought to wait and see.

[alaczek]

patterns shouldn't appear in the sidebar, they should only appear when replacing the header / footer template part. This work might happen in Gutenberg directly, so we ought to wait and see.

One thing to note is that we publish patterns on our source site as posts. That means they are required to be assigned a category. I removed them from Header/Footer categories, but that just means it fallbacks to "Uncategorized", which is not great, as it's now surfaced in the inserter. Would it make sense to hide the "Uncategorized" category from the inserter on our end? That would patch the issue in the short term.

If not, I think I'll just go over header/footer patterns and assign them to Header/Footer categories so that uncategorized doesn't show up anywhere.

[dsas]

Would it make sense to hide the "Uncategorized" category from the inserter on our end? That would patch the issue in the short term

So far as I can tell, there's no facility for us to customise this from outside of Gutenberg - no hooks, config or similar. The pattern must still be registered so that we can display it when editing template parts. If a pattern doesn't have a registered category, then an Uncategorised category is created on-the-fly. This category list is then passed to the various sidebar components that know about categories, with no way of changing them.

We could maybe do it serverside by defining the postTypes property to just be ['wp_template', 'wp_template_part']. This functionality was released in Gutenberg 13.6 though I can't actually get it to work with dotcompatterns on current Gutenberg 🤔. It wouldn't solve the issue for patterns sourced from core or themes either.

[alaczek]

Alright. Does it make sense for me to use the Header / Footer categories for now? I think it looks better than having them as Uncategorized...

[dsas]

Yeah I think using Header / Footer categories is best for now

[dsas]

This functionality was related in Gutenberg 13.6 though I can't actually get it to work with dotcompatterns on current Gutenberg 🤔. It wouldn't solve the issue for patterns sourced from core or themes either.

Looks like this (unmerged) PR is needed too will be required too, along with some ETK changes to set postTypes => ['wp_template', 'wp_template_part'] for patterns with block_type_core/template-part/*

[dsas]

The previously mentioned PR is now merged and should be in WP 6.1 to boot, this is now unblocked.