Editing Toolkit: Load patterns from the rest API endpoint

[apeatling]

Remove block patterns from within the codebase, and load them via the new rest API endpoint.

Testing instructions

• Load the editor and the patterns inserter and confirm you see all the following categories:

• Try inserting a pattern and confirm this works as expected.
• Switch your blog to a different language (settings->general)
• Confirm that you can still see patterns in the pattern inserter
• Some patterns may be translated (still confirming this).

[matticbot]

Test live: https://calypso.live/?branch=add/patterns-toolkit-rest-api-support

[matticbot]

Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

D50169-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2

[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.

[glendaviesnz]

This worked well for me ... I didn't see the 'Seedlet' category at the top of the list though, was this category removed?

Also, what is the plan with the pattern transient cache invalidation? Currently it looks like it will only be invalidated when the editing toolkit plugin is updated, but do we want a way of triggering an update without have to publish a new version of the plugin? eg. would it be better to trigger it via detection of some update of data on dotcompatterns.wordpress.com?

[andrewserong]

This is working pretty well for me in testing, thanks for putting it together so quickly! I left a few comments of small things to change. The main things were that the .org patterns are currently being shown and they weren't previously (wasn't sure if that's intended), and we probably want to add the 'categories' => 'pattern' param to the API call to hide the full page layouts (unless they're intended to be shown, too). Also one of the contact patterns is showing up in the Uncategorized category, so this one might need to be fixed up on the source site.

Nice idea pulling in transients so that we don't have to make the API call on every request, that seems like a solid approach, and I like that updating the plugin or a time period being elapsed will clear the cache. My only concern here is ensuring that we can easily invalidate the cache if we need to, I'm too sure what the risk is there, though. Would setting the expiration time for the transient to a shorter period help, say 6 or 12 hours instead of a full day?

Also, this is my first time testing out the pattern categories drop-down — nice addition! Makes the browser performance of the pattern inserter so much nicer.

The final concern I have is just the same one about doing so much on the initial page load. I think this is mostly mitigated by using transients here, and hopefully adding object cache at the endpoint will help us for speeding up getting the translated patterns. Before this PR is merged, I think it'd be good to do a check on initial editor load time difference between before and after the PR, just so that we can have a clear idea of the potential performance impact. Longer-term, 🤞 we can move to loading patterns via JS in the editor.

[apeatling]

The main things were that the .org patterns are currently being shown and they weren't previously (wasn't sure if that's intended)

I wasn't sure about hiding dotorg patterns, this seemed odd to me. @ianstewart could you chime in here and let me know if you want that to continue?

[ianstewart]

We previously had, I think, an inconsistent subset of them hidden. Some showed, some didn't. It was an intentional choice, partly because they weren't translated, partly because I think they were just a placeholder set. I'd probably keep hiding them for the former reason if they won't be automatically translated.

[apeatling]

This worked well for me ... I didn't see the 'Seedlet' category at the top of the list though, was this category removed?

@glendaviesnz This will only show with Seedlet theme activated. I'm seeing the category, can you confirm you can't see it with that theme active?

[apeatling]

Thanks for the reviews. I've fixed up everything I can on this PR, once I get some more feedback on the conversations above I'll fix up the rest. 👍

[glendaviesnz]

@glendaviesnz This will only show with Seedlet theme activated. I'm seeing the category, can you confirm you can't see it with that theme active?

🤦 Doh, that makes sense, yeh, shows for me once the Seedlet theme is activated.

[glendaviesnz]

This tests well for me still after latest changes.

[apeatling]

The updates have been made to support the new API changes. I think this is ready for a final review.

[andrewserong]

The code's looking good to me now @apeatling, thanks for following up with all the changes! Tested manually on a simple site, and I haven't been able to detect a performance impact with the change, which is great.

I noticed one pattern appeared to render a block validation error in the preview in the inserter, as well as when I add it, but I'm not quite sure what's going on there. It's one of the "Call to Action" patterns (id 1638):

I might need to do some more digging on Monday, as it's opening fine for me in the source site's wp-admin. 🤔

Lastly, because we're still running GB 9.0.0 on simple sites, we don't have the block pattern category drop down you put together, so I haven't really been able to test the patterns down the bottom of the inserter list. I think we should wait until GB 9.1.0 lands in simple sites before merging this one. I'm happy to do another round of testing once the upgrade has gone through.

[apeatling]

Sounds good, happy to wait for 9.1, I've posted a happiness heads up. For the block validation issue, I haven't seen that. Do you have coblocks installed? Some of the patterns need it.

[andrewserong]

Thanks Andy! This was on a simple site, so the Dotcom-flavour of coBlocks should be there. I was having trouble applying the diff in my sandbox today (I think possibly because there's been a backend deployment of the editing toolkit plugin since this PR was opened?) so I've given the PR a rebase. I'll do more testing when we've got GB v9.1 in place :)

[apeatling]

@andrewserong I've done some extensive testing on my sandbox and things look good. I think this is ready to go.

[apeatling]

Going to merge this to catch the 2.7 editing toolkit release.

[apeatling]

Reverting this PR because when the API is called needs to be more specific (on the editor screen only). Also need to check on endpoint caching.

[apeatling]

Will open a new PR with fixes to make the API call more specific.