Patterns: allow overriding of theme patterns as well as duplication

[glendaviesnz]

What problem does this address?

Currently, it is only possible to duplicate a theme pattern in the site editor pattern library. This creates a completely new pattern that lives in the pattern library in conjunction with the original theme pattern, and changes to it do not impact the places where the original theme pattern is used.

What is your proposed solution?

It would be useful to have another option that replaces the theme patterns with the new custom copy, and changes to this pattern are reflected everywhere that the theme pattern is used in the site. It should also then be possible to revert the pattern back to the original theme version. This would be similar to how template modifications currently work, with any edits to a theme template overriding the original theme template, but with an option to revert the customisations:

[talldan]

There's a similar conversation happening on this issue - #55469

[glendaviesnz]

There's a similar conversation happening on this issue - #55469

It is a little broader in relation to the lock icon, etc. so I think it is worth keeping this issue for the specific functionality of overriding rather than duplicating, but feel free to close if you don't think we need both.

[richtabor]

Yes, I'd expect these to work exactly like template parts.

[talldan]

I think this has been discussed in other places, but I have some thoughts on the technical solution for this.

The first steps would be to make the wp_block post type support slugs, and have the pattern (wp:block block) reference those post types via the slug (instead of the id).

When you customize a bundled pattern, a wp_block post type would use the same slug, and that's how we'd tie the two things together. It's the exact same way that template parts work, so it helps with the unification effort - #57011. It also means bundled theme patterns can be 'synced' from the start as described in #59272, the same way template parts are.

@getdave has already been exploring a similar change for wp_navigation post types:

• Use slug instead of id for ref in Navigation block #42809
• Nav block - find menu by slug using existing core data API #45443

So it'd be good to try getting that merged first and then explore using the same approach for patterns. The gist of it is:

• Pattern Block: A new slug attribute would be introduced, with the old ref attribute soft deprecated (it would still work for back compat, but any new usage uses the slug).
• REST API: No/minimal changes, a query is used to fetch by either slug or id depending on the reference the block has (e.g. wp/v2/wp_block?slug=twentytwentyfour/header.
• Core data: Would need some adaptation to know when to use the right approach for getEntityRecord dependent on slug or id being used.
• Client side permissions checks: There's a tricky issue that permissions checks for individual records wouldn't be able to work the same way. canUser( 'edit', 'wp_block', 'twentytwentyfour/footer' ) wouldn't work out of the box, as it translates to OPTIONS /wp/v2/wp_block/twentytwentyfour/footer which the REST API doesn't know how to handle.
• Migrating old wp_block posts: Avoid a one-time migration, instead add slugs to records when the user saves and prefer slugs for any new records.

(In the future it might be an option to move to a /wp/v2/patterns endpoint that returns bundled patterns, template parts and wp_blocks all in one go and uses slugs as part of the unification work. I'm not sure if that's something that's worth bringing forwards for this)

[getdave]

Core data: Would need some adaptation to know when to use the right approach for getEntityRecord dependent on slug or id being used.

Just a note to say that in exploring this for Navigation I did consider extending the Posts Controller for Navigation and adding a slug endpoint. It worked well but required overloading a few methods.

However the feedback from REST maintainers was that we shouldn't do this just for Navigation and instead we should utilise the existing collections endpoints to fetch by slug and get the 0th record.

However, if we have other uses cases perhaps we could explore being able to fetch other posts by slug.