Add theme support config to disable the Core block patterns.

[youknowriad]

WordPress Core comes by default with a number of block patterns and a frequent request was to be able to opt-out of the Core block patterns.

Let's consider adding a theme support flag to avoid registering Core block patterns. Something like:

add_theme_support( 'disable-core-block-patterns' )

Trac ticket: https://core.trac.wordpress.org/ticket/50669

@desrosj That's a good point, that said, this is a pattern already used for several theme supports, I fear the inconcistency a little bit.

I pushed a commit with your proposal.

Ya, I'd prefer to not add more disable-* features if possible. It looks like there are currently 2 supported. Looking at deprecating those in favor of more clear options may be worthwhile.

Looking through Core, there are currently no theme features added by default without a related function being called (​`add_editor_style()` and ​`register_nav_menus()` are examples of that pattern). Not sure if there is a way to use this pattern instead.

A third option we have is using a short-circuit filter.

$filter_result = apply_filters( 'support_core_block_patterns', true );
if ( ! $filter_result ) {
    return;
}

Returning any "falsey" value will disable the function. This is also a pattern used throughout Core (​`wp_maybe_load_widgets()` is one example). This would mean changing the function to wp_maybe_register_block_patterns(), but it wouldn't necessarily help inform theme developers declare support for block patterns.

I think the current pattern applied on this PR is growing on me. Something like add_editor_style() would work if the "support" applied to all patterns, not just core ones. And the filter solution doesn't look semantic enough.

About the current "disable-" theme supports, hopefully, these will be replaced with theme.json file when global styles land.

About the current "disable-" theme supports, hopefully, these will be replaced with theme.json file when global styles land.

As an aside, I'd love to see examples of this and how the server would remain aware of support for various features.

I think the current pattern applied on this PR is growing on me. Something like add_editor_style() would work if the "support" applied to all patterns, not just core ones. And the filter solution doesn't look semantic enough.

What if we just removed core- from the feature name? ~Thinking out loud, we could also allow the specific block patterns supported to be passed to the theme support feature similar to how the HTML5 and custom logo features accept arguments,~ actually, this would just replicate the register_block_pattern() function.

:wave: I gave this a spin:

• I wonder if there's a need to selectively enable patterns instead of an on/off switch? If so, we could provide a filter others can hook into:
  • Want to disable all patterns? Return an empty array from the filter.
  • Want to enable a few of them? Return an array with the patterns you want to be enabled.

• I can't get this patch to work. The patterns aren't registered so they aren't shown in the inserter. Perhaps when the block-patterns.php file loads it's too late to declare theme support? I'm not familiar with how that works, but I also haven't seen any example of using theme support outside the theme's functions.php file (even functions that use add_theme_support like register_nav_menus are meant to be called within the theme's functions.php) so thought I'd mention it.

I can't get this patch to work. The patterns aren't registered so they aren't shown in the inserter.

it worked well on my testing but i'll give it a second check to confirm.

I wonder if there's a need to selectively enable patterns instead of an on/off switch? If so, we could provide a filter others can hook into:

This is already available as you can register/unregister patterns selectively. What was missing is for themes that don't want core patterns entirely and want to provide their own.

Want to enable a few of them? Return an array with the patterns you want to be enabled.

This solution also has a downside of making it harder for Core to remove existing patterns in the future. While it's already delicate, I think we shouldn't be making it harder for backward compatibility.

@nosolosw Good catch on the bug, the condition was actually inverted (lingering from the initial implementation). It should be better now.

Ah, I see, so the goal is to provide a mechanism that opt-outs from current and future block patterns provided by core (instead of doing it selectively like unregister_block_pattern( 'core/pattern-name-1' ); etc. Got it :+1:

[youknowriad]

In 48492:

Block Editor: Add theme support flag to opt-out of Core Block Patterns.

WordPress Core comes by default with a number of block patterns and a frequent request was to be able to opt-out of the Core block patterns.
You can now opt-out using remove_theme_support( 'core-block-patterns' )

Props desrosj, nosolosw.
Fixes #50669.

[youknowriad]

Dev note published here ​https://make.wordpress.org/core/2020/07/16/block-patterns-in-wordpress-5-5/

[SergeyBiryukov]

Is it intentional that the strings in wp-includes/block-patterns.php have the gutenberg text domain? It looks like they won't be translated if the plugin is not installed.

[youknowriad]

Good catch @SergeyBiryukov

I think this was an error on a previous ticket but I'll fix it quickly.

[youknowriad]

In 48494:

Block Editor: Remove the gutenberg domain name from the block-patterns.php file

Props SergeyBiryukov.
Fixes #50669.

[desrosj]

I'm thinking that the add_action() should probably be moved to the wp-includes/default-filters.php file.

@SergeyBiryukov what do you think?

[SergeyBiryukov]

In 48531:

Block Editor: Move the add_action() call for _register_core_block_patterns_and_categories() to wp-includes/default-filters.php.

Follow-up to [48492].

Props desrosj.
Fixes #50669.

[SergeyBiryukov]

In 48533:

Block Editor: Move the add_action() call for _register_core_block_patterns_and_categories() above check_theme_switched().

Follow-up to [48492], [48531].

See #50669.

[SergeyBiryukov]

In 48598:

Docs: Add a mention of core-block-patterns as a possible value for add_theme_support().

Follow-up to [48492].

See #50669.