Patterns should not display if their blocks are not allowed

[chrisvanpatten]

Describe the bug
In the current version of Gutenberg (8.3.0) and several earlier versions, block patterns display even if the blocks they are composed of are not "allowed" on the post type (via the allowed_block_types filter). Patterns should be hidden if they are composed of disallowed blocks.

To reproduce
Steps to reproduce the behavior:

1. Create a post type
2. Use allowed_block_types filter to limit blocks down to one or two
3. Observe patterns displaying

Expected behavior
Patterns should only display if all their constituent blocks are available.

Screenshots

[chrisvanpatten]

There might also be an intersection with template_lock; if you have the inserter open at the top level of a post which is template locked, the inserter displays "No results found" for the blocks inserter, but the pattern inserter displays all the registered patterns. Then, it still allows you to click to insert but in fact the pattern is not inserted because of the lock. It's a bit of a confusing UX.

[chrisvanpatten]

Here's a brief/blurry demo of what I see:

[chvillanuevap]

This issue also applies to Reusable Blocks.

[jeremyfelt]

I needed to solve this for a custom post type of mine and spun off the solution into a standalone plugin: https://github.com/jeremyfelt/unregister-broken-patterns

I don't have enough familiarity with "allowed" vs registered/unregistered block types and how to account for that in thinking of where a solution should be implemented. My guess is that WP_Block_Patterns_Registry::get_instance()->get_all_registered() could be passed a block types array, but it could also go further down in edit-form-blocks.php. 🤷🏻

All in all, +1 for fixing this. :)

[justintadlock]

I literally just came across this issue while testing your Shortnotes plugin, @jeremyfelt. Came here to create a new issue.

[jeremyfelt]

@justintadlock If you haven't found it yet, this is a plugin in the repo now too: https://wordpress.org/plugins/unregister-broken-patterns

I'm still behind on documenting the quirks. :)

[jeremyfelt]

Via #30300:

This implementation only works for top-level blocks in patterns. If a pattern contains a block deep inside somewhere in its block tree, then it will still show up in the inserter. We need to recursively check for all blocks in the pattern.

@ntsekouras @david-szabo97 This ticket was auto-closed when #30300 was merged. Can it be reopened until a more complete solution is in place? Thanks!

[melcarthus]

I move my comment here -> #31706 (comment)