Block patterns: Remove the block that filters out core blocks from the patterns inserter

[ramonjd]

Changes proposed in this Pull Request

This PR tests out unleashing core patterns in WPCOM. By "core" we mean patterns shipped with WordPress and not those added or overwritten by Gutenberg (See https://github.com/WordPress/gutenberg/blob/trunk/lib/block-patterns.php#L11)

Testing instructions

Apply this ETK patch to your sandbox

install-plugin.sh etk add/core-patterns-to-inserter

and open up the editor in a sandboxed site.

Check the patterns inserter for core block patterns.

You can verify that core blocks exist in the inserter by looking at the core block files, e.g., https://github.com/WordPress/gutenberg/blob/trunk/lib/block-patterns/two-buttons.php and then finding the corresponding pattern/category in your editor.

Here are the core buttons:

Switch you site language to Swedish and see if some of the core patterns are translated. 🇸🇪
Think of meatballs and cranberry sauce!

Check that Gutenberg patterns, e.g., query/* patterns are not present.

Related to https://github.com/Automattic/view-design/issues/267

[github-actions]

Test live: https://calypso.live/?branch=add/core-patterns-to-inserter

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[ianstewart]

I haven't had a chance to test with the instructions above but wanted to check in on how categories are working. Are they correctly merging? Including in our FSE test flow?

[ramonjd]

Forgot to add that I haven't tested i18n yet. There might be further work to import core translations.

[ramonjd]

I haven't had a chance to test with the instructions above but wanted to check in on how categories are working. Are they correctly merging? Including in our FSE test flow?

Thanks for raising this. On our list to check 👍

[ramonjd]

So there are some thing we need to look at for this. I might create some separate issues.

Full site editor

The block's theme styles (and maybe others) aren't being applied in the inserter in the site editor. This is an example from the TT1 theme:

Site editor	Block editor

I can replicate this phenomenon in core as well. A quick search reveals that there are no related issues/PRs, so we should log one. See: WordPress/gutenberg#30680

Translations

The patterns are translated, for example a Gutenberg block and its WPCOM translation.

WPCOM patterns are translated through the patterns API. Core patterns are not.

Core patterns are already registered however, so I can't yet see why they're not picking up the locale.

This is also happening in core, so we might need to log another issue there?

One, quickish way around this would be to:

1. modify this PR to only allow core patterns for our patterns sources sites, then
2. add core blocks to our block patterns source sites and
3. finally have them delivered to the frontend via the Patterns API.

I think adding core patterns to dotcompatterns might be a good short-term approach. It would have the benefit of allowing us to properly test updates to core patterns before we allow them onto WPCOM, and also have full control over the categories cc @andrewserong

The only, in my opinion minor, downside would be that we'd have to curate them. We might look into automating updates however.

Categories

Core categories don't always line up with with ours.

For example, the core quote pattern has a category of array( 'text' ).

WPCOM on the other hand has a dedicated "Quote" category.

This is another argument for adding core patterns to dotcompatterns I think.

[andrewserong]

@ramonjd I just gave this a test, and I think a lot of the translations haven't come back yet for the core patterns.

The patterns are translated, for example a Gutenberg block and its WPCOM translation.

For that one, it looks like it's only been translated into Romanian?

I looked up another string (Our Work) from the two buttons pattern. From the "Other locales" tab (click details on "Our work" to open it up), it looks like it's been translated into Romanian and Swedish. I tested out variously switching my site's language to Swedish and my user account's language to Swedish. It seems it's picking up the translations based on the user's language settings (whereas in the ETK we're using the site's language). If you set them both to the same language it looks pretty good: 😅

I think adding core patterns to dotcompatterns might be a good short-term approach. It would have the benefit of allowing us to properly test updates to core patterns before we allow them onto WPCOM, and also have full control over the categories

Good point, that would give us full control over the categorisation and testing. On the other hand, we then introduce a bit of duplication that might add slightly to our workload if and when we want to revisit loading core patterns, too. If we don't want to make manual copies of the existing patterns in dotcompatterns, but we do want to recategorise, we could do that manually in the ETK I suppose, around where we're currently sorting pattern categories?

I'm glad to see that the core patterns get registered into the existing categories when there's a match, though!

Getting back to translations, I'm curious to see if we can get the languages playing nicely — with the untranslated strings, I'm not sure of the workflow for getting Gutenberg strings translated... I imagine they get sent for translation when a new Gutenberg release is pushed? It's possibly a similar situation as to patterns provided by themes for us — they too should be translated, and I wonder if they're using the site or user language?

While I like the logic we used in picking which language to use for the wpcom patterns in the ETK (it's site content, so the pattern translations should be in the site's language), I wonder if we need to revisit that if it's at odds with the approach in Gutenberg? (Or propose switching the behaviour in Gutenberg?)

[ramonjd]

Thanks for the feedback! And for asking these questions: I think we need to answer them to understand the best way forward

From the "Other locales" tab (click details on "Our work" to open it up), it looks like it's been translated into Romanian and Swedish. I tested out variously switching my site's language to Swedish and my user account's language to Swedish.

Well, that's a relief. Thanks for double checking. Next time I'll test more than German, French and Spanish 😄

I'm not sure of the workflow for getting Gutenberg strings translated... I imagine they get sent for translation when a new Gutenberg release is pushed?

Yep, I think they get sent to https://translate.wordpress.org/ for community translation, though I cannot see any translations in GlotPress (.org) yet 🤷

I wonder if they're using the site or user language?

This is a good point. On WPCOM it's using user language.

I would expect it to be the same on WordPress sites in general, however Ttsting in Gutenberg on a plain 'ol WordPress site, the patterns aren't translated. I can't see them in translate.wordpress.org.

So it seems that so long as we can send the core patterns off for translation on WPCOM it should be okay 👍

We can confirm with Global that the wp-includes/block-patterns dir is being sent off for translation.

If we don't want to make manual copies of the existing patterns in dotcompatterns, but we do want to recategorise, we could do that manually in the ETK I suppose, around where we're currently sorting pattern categories?

Curating a dictionary to map core categories to our own would be some maintenance, but yes, probably less maintenance than keeping on top of our own copies of core patterns (unless we can automate creating posts based on the patterns).

If we want to try this then we could loop through core patterns, check their categories and reregister the patterns with any edited categories. It would still require us to keep abreast of new/update core patterns.

This list is pretty small though 😄

If we ever needed full control over how we load/translate/categorise core patterns, I was thinking it would be fab to be able to check the current crop of registered core patterns and dynamically create/update post content on dotcompatterns.

[ianstewart]

Curating a dictionary to map core categories to our own would be some maintenance, but yes, probably less maintenance than keeping on top of our own copies of core patterns (unless we can automate creating posts based on the patterns).

One thing to consider is that later this year (not sure of timelines) we'll likely be consuming a Core Patterns dir on Dotcom. I don't think it'll replace our Pattern Library off the hop but … there'll be even more patterns and even more categories.

Is it possible to share a quick video or demo link internally in Slack for testing it out?

I'm glad to see that the core patterns get registered into the existing categories when there's a match, though!

This is pretty darn cool. Just wanted to note that. :D

[andrewserong]

If we ever needed full control over how we load/translate/categorise core patterns, I was thinking it would be fab to be able to check the current crop of registered core patterns and dynamically create/update post content on dotcompatterns.

That would be pretty neat. Shouldn't be too hard to do if we can store an external reference somewhere on the pattern (either in a pattern meta tag or post_meta) so we can match existing patterns and avoid creating duplicates. Maybe an additional patterns WP CLI sub-command to do it?

[ramonjd]

I've been looking at this today, trying unregister core patterns, then reregister them with WPCOM categories.

I've hit a couple of speed bumps.

Pattern translations and category registration are based on the site language. We need therefore, translations for core patterns and their categories to also match this.

To re-register core patterns using WPCOM categories, the WPCOM categories must also be registered first.

This will probably entail switching to the site language in get_patterns.

And re-register core patterns later.

I also thought about trying to return registered core patterns from the ptk endpoint, but haven't managed to this successfully yet.

In summary, I haven't yet found the best way forward to:

1. re-register core patterns to use WPCOM-friendly categories
2. sync the locale while doing so

[ramonjd]

That would be pretty neat. Shouldn't be too hard to do if we can store an external reference somewhere on the pattern (either in a pattern meta tag or post_meta) so we can match existing patterns and avoid creating duplicates. Maybe an additional patterns WP CLI sub-command to do it?

It would be! Now that I've spent the morning unsuccessfully trying to hack core categories into WPCOM, it might be worth looking into.

[ramonjd]

I've updated this PR with the following changes:

• Include core patterns shipped with WordPress only. We're filtering out all Gutenberg added or overwritten patterns. These either don't work in WPCOM or are in stages of testing.
• Add a dictionary of core -> WPCOM categories so, if required, we can recategorize core patterns so they sit under existing pattern categories.

For now we're still adding core categories, e.g., "Columns", so we can discuss if we'd like to leave it in there or consolidate.

[andrewserong]

Thanks for working on this one @ramonjd! I was just trying to work out why applying this PR to my sandbox didn't appear to be working right (it was missing changes). It looks like the ETK build is failing due to PHPCS errors (you might have already seen it) but just in case:

[andrewserong]

It looks like the blockTypes array is used to declare which blocks a pattern is associated with, rather than categorising the pattern itself as core. At the moment, since blockTypes appears to be an experimental feature, using this to target Gutenberg patterns sounds like it should work since they're the only patterns that are using that array. At some point, though, we'll probably want to use this in wpcom patterns so that we can link our patterns with different block types. And plugins might do the same, so could this section unintentionally end up unregistering patterns we don't mean to?

This probably doesn't affect anything right now, though, and I can't quite think of another way to target those Gutenberg patterns. So it might not be a blocker... should we add a "todo" item somewhere to revisit it? Or propose in Gutenberg to flag the experimental ones in some way so that they can be more easily excluded?

[ramonjd]

Thanks for flagging this.

I can't quite think of another way to target those Gutenberg patterns.

It seemed too unruly to add exceptions for query/* and other Gutenberg pattern names, especially if WPCOM wishes to add its own too.

should we add a "todo" item somewhere to revisit it

You bet. Will do.

Or propose in Gutenberg to flag the experimental ones in some way so that they can be more easily excluded

Both I think sound über reasonable. Great idea. 🙇

[ramonjd]

I've found a patterns tracking issue. I've asked there whether it's worth creating an issue.

[andrewserong]

Sounds good, thanks for that!

[andrewserong]

Do we need to switch back to the current locale again after doing this? And is there a performance penalty for switching locales? I imagine it's fine since we're only doing it once, but just thought I'd double check.

[ramonjd]

It's probably safer if we do, thanks. I'll throw a restore_previous_locale(); in there.

And is there a performance penalty for switching locales?

Yes, I believe there is. Every time we switch locales we load the textdomain files.

I'm not sure how much of a hit it'll be here, since we're switching to the site locale, which I guess we'd have to load elsewhere too anyway?

[andrewserong]

Nice work, this is testing well for me now @ramonjd!

No Query category 👍	Translations use site locale 👍

Core patterns are showing in the inserter 👍

And translations are working on my test Atomic site, too 👍

LGTM!

[andrewserong]

Sounds good, thanks for that!