Patterns: add categories to user created patterns

[glendaviesnz]

Overview

Currently, there is no way for users to categorize/arrange their synced and unsynced patterns, they all appear under the 'My patterns' category.

Proposed solution?

Add a WP custom taxonomy called wp_pattern_category for the wp_block CPT.

The .org and theme patterns have a category registry, but these categories are generated on load based on the .org and theme patterns that are currently available to the site. There is no way for users to add/save their own categories, or to assign them to the wp_block CPT.

Options were explored of adding the existing pattern slugs to the wp_block CPT postmeta, but there would be performance issues with retrieving all patterns with a given category with this approach, and this also does not allow users to add their own categories.

WP taxonomies are a standard way to allow categorization of custom CPTs, and all the add/update/search functionality already exists, so this seems like the best way to add this functionality.

N.B. Tasks 2-5 below should all go into the same release, so ideally should be merged only when all 6 are ready to go
#53835 is the parent PR
#53837 & #53933 are branched off #53835
#54007 is branched off #53933

so merge order should be #54007, #53933, #53837, #53835

Tasks

• 1. Add custom taxonomy - PR
• 2. Add UI to the create pattern modal to select a category - PR
• 3. Display the categories in the site editor patterns page - PR
• 4. Display categories in the post editor inserter patterns tab - PR
• 5. Merge the synced patterns into post editor inserter patterns tab - PR
• Once the above PRs are merge retest Quick pattern inserter doesn't include synced patterns or template parts #54180 to make sure it is resolved
• Add additional filtering options to site editor patterns list page, eg. 'My synced patterns, My unsynced patterns, Theme patterns, etc.
• Get the category to save in add pattern model if user doesn't hit enter or , - PR merged into Patterns: Add categories to user patterns, and allow filtering by these in site and post editor #53835
• Add ability to edit categories of existing patterns into site editor - PR

[glendaviesnz]

@aaronrobertshaw, @kevin940726, @youknowriad, @Mamaduka, @carolinan, @t-hamano let me know if you have any thoughts on whether a standard WP custom taxonomy is the best approach for this or not

[Mamaduka]

Agreed, taxonomies are more suited for this and are more performant when querying the items vs. post meta.

P.S. We should probably drop the custom from the name - wp_pattern_category. The entities that ship with WordPress are native.

[t-hamano]

I too think taxonomy is the way to go. The reason is that the template parts area is also registered as a taxonomy and I think the pattern should be able to have a similar design.

[glendaviesnz]

We should probably drop the custom from the name - wp_pattern_category. The entities that ship with WordPress are native.

Have made that change on the PR. In my mind I was thinking of custom as being the user's custom patterns as opposed to the theme/.org patterns, but I can see how that wording would be confusing.

[aaronrobertshaw]

+1 to pattern categories via a taxonomy.

The querying performance, consistency with template parts, and leveraging of existing features are all compelling reasons to me.

[mtias]

Taxonomy is correct — the thing I'm worried about is the overlap between semantic template parts and pattern categories, specially given they are separate objects (wp_template_part and wp_block). Which would render a term of "header" associated only with wp_block ambiguous. We might need to share the taxonomy.

[glendaviesnz]

Thanks for raising the concern about the crossover with template parts @mtias. This overlap was already an issue with the pattern categories that are assigned to .org/theme patterns. This is one of the main reasons the Template parts heading was put back in the Patterns section of the site editor as there were two entries of header and footer one for patterns and one for template parts, and no clear indication to users why they were duplicated.

In the short term giving users the ability to add their own patterns to a header or footer category won't add any additional ambiguity to what is already there (the user pattern categories will be merged with the .org/theme pattern categories).

I agree though that it would be good to have a shared taxonomy so users just see one Header or Footer category, which would then show them all the template parts & patterns related to headers and footers. Exactly how this might be achieved depends on how/when/if template parts might merge with patterns.

While we could reuse the existing wp_template_part_area taxonomy for patterns it is an odd fit name-wise, and I am not sure about the risks of a rename in terms of database migrations, backwards compat with plugins, etc.

It seems like the lower-risk option is to proceed with adding the wp_patterns_category. Then the first step of removing the ambiguity could be to merge the template and pattern category results in the patterns page. Once the future of template parts in relation to patterns is decided decisions could then be made on how taxonomies could be further merged, and based on recent changes it seems like this is more likely to be template parts merging to patterns rather than the other way around, so the wp_patterns_category is more likely to be the taxonomy that is still needed.

Let me know if you have any different views/thoughts on this.

[glendaviesnz]

This work has been completed and is in GB 16.7 which will be used in the 6.4 beta release