Pattern Insertion Flows

[priethor]

Insertion UI

• Highlight pattern directory patterns in the initial view of the pattern inserter #33046
• Prioritize patterns on quick inserter instead of blocks at the root of templates #36697
• Allow themes to surface specific patterns from the Patterns Directory #35364
• Inserter: Display patterns in a two-column masonry grid with improved category filtering #28312
• Display block pattern options in a modal rather than placeholder state #31033
  • Depends on: Add a full screen modal component #28574
  • Precedes: Create a UI that suggests patterns that are contextual to the currently selected block #28736)
  • Deprecates: Inserter: Expand view to view patterns in a larger overlay. #26905
• Add pattern search to the slash inserter  #26116
• Improve layout shift caused by pattern previews loading in the inserter menus. #27494
• Block patterns: hide sidebar when no patterns are registered #20867
• Improvements for Quick Inserter prioritizing patterns #40117

Discoverability

Pattern availability and restricting

• Patterns should not display if their blocks are not allowed #23275
• Support a postType property when registering patterns #41398
• Automatically remove block patterns if one or more of the blocks has been unregistered using unregisterBlockType #23803

Contextual suggestions (broader discussion in #27575)

• Suggest Patterns in block placeholder states #28735
• Block context: Create a UI that suggests patterns that are contextual to the currently selected block #28736, Patterns should be discoverable from block editor #28309
  • Design Patterns to work with with single pattern transforms #30631
• Container context: Semantic Patterns #28737
  • Size constraints: Make the block-pattern inserter spatially-aware #30210 (e.g. avoid large pattern in small columns)
• Template context: Site Editing: Increase prominence of contextual patterns when template editing #28739
• Template part context: Enable template part specific block patterns. #28802

Search

• Allow the registering of search synonyms for Patterns #38536

Connection with w.org directory

• Patterns: Combine local and w.org search results for Inserter #28248
• Block Patterns: Load patterns from wordpress.org API #28800

[ramonjd]

Looking for opinions here: would it make sense to be able to tell the block editor plugin not to register its own patterns or update core patterns?

Let's just say we want to be able offer our own library of patterns, or only those available in a WordPress install.

Other than keeping track of every block name that Gutenberg registers, and then manually unregistering them, how could we disable them?

I see two options (assuming the idea itself is sound):

1. Add an apply_filters( 'register_gutenberg_patterns', true ) and apply_filters( 'update_core_patternscheck', true ) for example
2. Standardize patterns names registered by the plugin so we can filter them out more reliably: currently we're registering query/* and social-links/shared-background-color.

I think it's especially important given the comment in the file:

 * Deactivate the legacy patterns bundled with WordPress, and add new block patterns for testing.

For experimental patterns, I think we should be able to opt-out.

[priethor]

Hi @ramonjd! Given this issue is more focused on the pattern insertion experience within post and template editors, I think it would be more effective to create its own issue to discuss this more in detail, as suggested in the related PR. In any case, I think your proposal makes sense, but I would love to hear @ntsekouras' opinion as well.

[ramonjd]

Thanks for the quick feedback @priethor! I'll do as you suggest, and create a new issue to direct discussion there. Sorry for hijacking this issue!