Surface community-contributed patterns from the Pattern Directory in the editor (opt-in)

[ugyensupport]

The block editor's Patterns inserter loads remote patterns from the WordPress.org Pattern Directory, but only two curated slices:

• _load_remote_block_patterns() — the core keyword (id 11)
• _load_remote_featured_patterns() — the Featured category (id 26)

The much larger pool of community-contributed patterns — the ?curation=community view on wordpress.org/patterns (~90k patterns) — is never exposed in the editor. To use one today, a user has to leave the editor, browse the directory on wordpress.org, and copy/paste the pattern back: a broken flow for what is otherwise a first-class inserter feature.

The omission is deliberate — the community collection is large and unmoderated, so core curates what it surfaces. This enhancement preserves that default while giving themes, plugins, and site owners a supported, first-class way to opt in.

Approach

Add a third remote loader, _load_remote_community_patterns(), alongside the two existing ones, registering results under a new community block-pattern category.

Because loading the uncurated collection by default would regress both performance and the out-of-the-box quality bar, it is opt-in and disabled by default, behind a new filter:

<?php
// Surface community patterns in the inserter.
add_filter( 'load_remote_community_block_patterns', '__return_true' );

With the filter off (the default), behaviour is byte-for-byte unchanged and no extra directory request is made. The change is inert until explicitly enabled — the key point for review.

Why here

The three remote loaders are invoked lazily, once, from WP_REST_Block_Patterns_Controller::get_items() — the REST call the editor makes to populate the inserter. Adding the community loader in the same block gives it the exact same lifecycle, caching, and should_load_remote_block_patterns gate as the existing loaders. No new hook, no front-end cost, no change to the non-editor request path.

Changes

wp-includes/block-patterns.php

• Register a new community pattern category (label "Community"), next to featured.
• Add _load_remote_community_patterns(), mirroring _load_remote_featured_patterns(): honours should_load_remote_block_patterns, adds the opt-in load_remote_community_block_patterns filter (default false), requests the general directory collection (no keyword/category), and registers each result under the community category with a pattern-directory/community source and a community/ name prefix.

wp-includes/rest-api/endpoints/class-wp-rest-block-patterns-controller.php

• Call _load_remote_community_patterns() in the existing lazy-load block in get_items().

tests/phpunit/tests/blocks/loadRemoteCommunityPatterns.php (new)

• Covers: no directory request when the filter is off; registration under the community category with the pattern-directory/community source when opted in; and the should_load_remote_block_patterns gate still winning when opted in. Uses a registry-swap fixture and a pre_http_request mock (mirroring rest-pattern-directory-controller.php tests), so it never hits the network. Passes locally — OK (3 tests, 6 assertions).

Testing

Default (filter off) — no behaviour change

1. Add no filter.
2. Open the editor and the Patterns inserter.
3. Confirm there is no "Community" category and the inserter behaves exactly as on trunk (optionally, that no directory request is made for the community collection).

Opt-in (filter on) — community patterns appear

1. Add the load_remote_community_block_patterns → __return_true filter shown above.
2. Reload the editor and open the Patterns inserter.
3. A "Community" category appears, populated from the directory.
4. Insert one; confirm it inserts as editable blocks (not rendered HTML) matching the directory pattern.

Remote-load gate still respected

1. Keep the opt-in filter on and also add:

   <?php
   add_filter( 'should_load_remote_block_patterns', '__return_false' );
   

2. Reload the inserter. The "Community" category should be absent — the master remote-load gate wins, consistent with core and featured.

Open questions / notes

• Opt-in vs. UI toggle. This lands the plumbing as an opt-in filter. Whether the end goal is opt-in only, or a surfaced UI toggle, is a product call for the Editor component — the inserter UI itself lives in the Gutenberg repo, so a companion issue there may be warranted.
• Grouping. Results are grouped into the community category for a predictable inserter section; preserving each pattern's own directory categories instead is a reasonable refinement to discuss.
• Batch size. per_page is capped at 24 to keep the first uncached inserter load responsive; pagination / lazy fetch is a natural follow-up.
• @since is currently 7.2.0 and should be adjusted to whatever version this lands in.

## What

Adds a third remote pattern loader, _load_remote_community_patterns(), alongside the existing _load_remote_block_patterns() (core keyword) and _load_remote_featured_patterns() (featured category), registering results under a new community block-pattern category.

Loading the uncurated community collection is opt-in and disabled by default, behind a new load_remote_community_block_patterns filter. With the filter off, behavior is unchanged and no extra directory request is made.

Enable it with:

add_filter( 'load_remote_community_block_patterns', '__return_true' );

## Why

The inserter only exposes the curated core/featured slices; the larger pool of community-contributed patterns is not reachable from the editor. This provides a supported, first-class opt-in without regressing the default out-of-the-box experience.

## Testing

• New: tests/phpunit/tests/blocks/loadRemoteCommunityPatterns.php (OK (3 tests, 6 assertions)), covering: no request when disabled, registration under community when enabled, and the should_load_remote_block_patterns gate still winning.
• Manual: with the filter enabled, a "Community" category appears in the inserter, populated from the Pattern Directory; inserting yields editable blocks.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request.

[ugyensupport]

Before

[ugyensupport]

After

Tested locally on a fresh WordPress install with this patch applied and the opt-in filter enabled:

add_filter( 'load_remote_community_block_patterns', '__return_true' );

Before/after of the block editor's Patterns inserter:

Before — stock behaviour: the category list goes *Call to action → Contact*, with no Community category.

After — with the filter enabled, a Community category appears (between *Call to action* and *Contact*) and is populated with patterns pulled live from the WordPress.org Pattern Directory.

With the filter off (the default), the category does not appear and no extra directory request is made — behaviour is unchanged. The bundled test Tests_Blocks_LoadRemoteCommunityPatterns passes: OK (3 tests, 6 assertions).

Cross-linking a follow-up for the browsing experience: the on-demand *search + load-more* over the full Pattern Directory (including the community collection) is proposed as a Gutenberg feature in WordPress/gutenberg#81771, since that UI is client-side (the inserter renders only registered patterns today).

This PR remains the minimal server-side opt-in — registering a community category. If the Gutenberg browsing UI in #81771 lands, this can be reduced to just the category registration, or superseded by it.

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