Patterns: Allow for filtering of block patterns by source

[aaronrobertshaw]

Related:

• Reusable blocks: Rename to 'Patterns' and add option to also add a non-synced Pattern #51144
• Site Editor: Add Library for Template Parts & Patterns Management #51078

Backport PR for this change: WordPress/wordpress-develop#4697

What?

• Extends the REST API endpoint for block patterns to provide a new source attribute
• When registering core block patterns, the new source attribute

Why?

The Site Editor Library has been designed to allow users a more refined experience in managing their patterns. This requires the ability to filter out core block patterns which will not be editable by users.

How?

• Adds a new source attribute to the returned items from the pattern endpoint
• Sets the source attribute when loading core patterns
• This attribute will be used to filter patterns in Site Editor: Add Library for Template Parts & Patterns Management #51078

Testing Instructions

1. Test via Site Editor: Add Library for Template Parts & Patterns Management #51078
2. Open the Site Editor and navigate to the Library
3. Explore the library categories and ensure that only template parts, theme patterns, and reusable blocks are shown.

[github-actions]

Flaky tests detected in aac252d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5320797322
📝 Reported issues:

• [Flaky Test] shouldn't conflict with server-side autosave #35176 in specs/editor/various/autosave.test.js

[talldan]

Looks good so far. I think there are a few changes that would be good to address.

There should also be some documentation changes for register_block_pattern - https://developer.wordpress.org/block-editor/reference-guides/block-api/block-patterns/.

[talldan]

I think it should be more granular descriptive than just 'core' so that there are more options to use it for different things in the future.

Some suggestions based on the sources that I can see:

• 'core' (bundled with WordPress core)
• 'plugin' (plugins that register patterns can use this)
• 'theme' (I'm not sure if themes call register_block_pattern directly, but they could use this as the source if they do)
• 'pattern-directory/theme' (declared in the theme.json and pulled from the pattern directory)
• 'pattern-directory/core' (core patterns in the pattern directory)
• 'pattern-directory/featured' (featured patterns in the pattern directory).

Might be good to get some more opinions though, as I'm not too familiar with all the different places that patterns come from.

[aaronrobertshaw]

I've pushed a few more granular source values in 694f71d.

[aaronrobertshaw]

@TimothyBJacobs it was suggested you might have some wisdom to share regarding the proposed REST API changes in this PR. If you have the time to take a look at this, it would be greatly appreciated as we're trying to get this in for 6.3 🙏

[talldan]

I've pushed a commit that adds mention of source in the docs.

edit: rebased the PR to solve a conflict too.

[talldan]

This looks good to me.

There will be a PHP backport of this code to WordPress core, so that's a further opportunity to leave feedback, and we can replicate any changes back to the Gutenberg codebase.

I think the one thing missing right now is tests, so it'll be good to include some in the backport PR.

[glendaviesnz]

LGTM