WordPress.org

Make WordPress Core

Opened 4 weeks ago

Closed 3 weeks ago

Last modified 3 weeks ago

#50669 closed task (blessed) (fixed)

Add theme support config to disable the Core block patterns.

Reported by: youknowriad Owned by: youknowriad
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch has-dev-note
Focuses: Cc:

Description (last modified by 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' )

Change History (22)

#1 @youknowriad
4 weeks ago

  • Description modified (diff)

This ticket was mentioned in PR #407 on WordPress/wordpress-develop by youknowriad.


4 weeks ago

  • Keywords has-patch added

#3 @prbot
4 weeks ago

youknowriad commented on PR #407:

@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.

#4 @prbot
4 weeks ago

youknowriad commented on PR #407:

I pushed a commit with your proposal.

#5 @prbot
4 weeks ago

desrosj commented on PR #407:

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.

Last edited 4 weeks ago by dd32 (previous) (diff)

#6 @prbot
4 weeks ago

youknowriad commented on PR #407:

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.

#7 @prbot
4 weeks ago

youknowriad commented on PR #407:

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

#8 @prbot
4 weeks ago

desrosj commented on PR #407:

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.

#9 @prbot
4 weeks ago

nosolosw commented on PR #407:

: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.

#10 @prbot
4 weeks ago

youknowriad commented on PR #407:

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.

#11 @prbot
4 weeks ago

youknowriad commented on PR #407:

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.

#12 @prbot
4 weeks ago

youknowriad commented on PR #407:

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

#13 @prbot
4 weeks ago

nosolosw commented on PR #407:

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:

#14 @youknowriad
4 weeks ago

  • Owner set to youknowriad
  • Resolution set to fixed
  • Status changed from new to closed

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.

#16 @SergeyBiryukov
4 weeks ago

  • Keywords has-dev-note added; needs-dev-note removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#17 @youknowriad
4 weeks ago

Good catch @SergeyBiryukov

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

#18 @youknowriad
4 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 48494:

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

Props SergeyBiryukov.
Fixes #50669.

#19 @desrosj
3 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

@SergeyBiryukov what do you think?

#20 @SergeyBiryukov
3 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#21 @SergeyBiryukov
3 weeks ago

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.

#22 @SergeyBiryukov
3 weeks ago

In 48598:

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

Follow-up to [48492].

See #50669.

Note: See TracTickets for help on using tickets.