Patterns: provide a way to opt-out of Gutenberg patterns

[ramonjd]

The proposed feature

The proposal is that we provide a way to tell the block editor plugin to neither register its own patterns nor update core patterns.

At present, Gutenberg registers new patterns and overwrites/reregisters existing core patterns.

What would this feature address?

This feature would help in the following scenarios:

1. A consumer of the plugin wishes to offer their own library of patterns exclusively, or limit default patterns only to those available in a WordPress install.
2. A consumer does not wish to be exposed to any updates/experimentation that occurs in the Gutenberg patterns directory, but still wishes to maintain the latest plugin version. For example, it is expressly stated in the comments that we // Deactivate the legacy patterns bundled with WordPress, and add new block patterns for testing. (Emphasis added)

Where a consumer does not wish to include patterns, they must keep track of all registered patterns and filter them by name (unless there's an easier way?). With varying names such as core/*, query/* and social-links/shared-background-color however, the task becomes more complex.

What is your proposed solution?

To allow consumers of the plugin to opt-out of experimental, or preferably all patterns.

Assuming the base proposal is sound, I see two options:

1. Add apply_filters( 'register_gutenberg_patterns', true ) and apply_filters( 'update_core_patterns', true ) checks around register_gutenberg_patterns() and update_core_patterns()
2. Standardize patterns names registered by the plugin so we can filter them out more reliably, for example, core/query-large-title-posts or core/social-links-monochrome
3. Or both 😆 ?

What do folks think?

[ramonjd]

I was toying around with a proof of concept here: #31924 just to see what works. Thanks!

[simison]

Related #28800 cc @ryelle

[ramonjd]

We might not need this now that Gutenberg checks for theme support for core-block-patterns.

There used to be no checks before loading patterns:

https://github.com/WordPress/gutenberg/blob/v10.5.4/lib/block-patterns.php

Thankfully, later versions now only add patterns where there is theme support for core-block-patterns. For example:

https://github.com/WordPress/gutenberg/blob/release/10.7/lib/block-patterns.php#L244

To prevent both core WordPress and Gutenberg loading/overwriting patterns, it's possible to fire off a call to remove_theme_support( 'core-block-patterns' ); before running any custom hooks.

The effect is broad however.

It might therefore still be useful to have fine-grained controls over whether Gutenberg overwrites core blocks and/or loads its own, so I think a discussion of the relevant of #31924 could still be in order.

[ryelle]

There's a new filter in WordPress core to disable just the remote patterns, should_load_remote_block_patterns:

https://github.com/WordPress/wordpress-develop/blob/f5ca52c61794eb6a2082b1aec647de56344f2481/src/wp-includes/block-patterns.php#L64

[mkaz]

This is documented here: https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-support/#disabling-the-default-block-patterns

And an additional PR adds documentation for how to remove the remote call is here: #33930

I'm going to close this issue then as it has been addressed, if I missed something please reopen with additional details. 👍