WordPress.org

Make WordPress Core

Opened 16 months ago

Closed 15 months ago

Last modified 15 months 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
16 months ago

  • Description modified (diff)

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


16 months ago

  • Keywords has-patch added

#3 @prbot
16 months 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
16 months ago

youknowriad commented on PR #407:

I pushed a commit with your proposal.

#5 @prbot
16 months 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 15 months ago by dd32 (previous) (diff)

#6 @prbot
16 months 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
16 months 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
16 months 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
15 months 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
15 months 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
15 months 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
15 months 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
15 months 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
15 months 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
15 months 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
15 months ago

Good catch @SergeyBiryukov

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

#18 @youknowriad
15 months 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
15 months 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
15 months 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
15 months 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
15 months 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.