A new patterns Library for WooCommerce

[nefeline]

One of the initiatives of the next phase of the Customize Your Store project and its implementation on core involves migrating all WooCommerce patterns to a shared library, ensuring all patterns are served from an external API. This discussion describes in detail the proposed implementation plan, giving an opportunity for folks to share their thoughts and make suggestions.

Why migrate the WooCommerce patterns to a separate library?

The primary goal is to facilitate sharing patterns across multiple different projects. With this migration, we can rely on the dedicated API to fetch WooCommerce patterns and other external curated patterns for usage within our plugin.

Additionally, the size of the WooCommerce plugin will be significantly reduced, considering all images required for patterns will be migrated to this dedicated API.

Implementation plan

The implementation plan can be broken down into 5 steps:

1. Create a new design source site

Create a new design source site.

2. Patterns Registration

Within this newly created site, create one post for each one of the patterns we have on WooCommerce.

3. Ensure the migrated patterns are accessible via API

In this case, we can either create a new API Service from scratch or rely on a pre-existing one for this purpose, ensuring it's possible to fetch each one of the patterns from the site you created via API.

4. Ensure the migrated patterns are displayed in the editor preview and can be inserted

Ensure WooCommerce patterns are fetched via API, registered, and available in the editor preview and inserter the same way they used to be when patterns were still living within the WooCommerce plugin. To help with this implementation, the following PR on Jetpack can be used as an example of how to achieve this quickly:

https://github.com/Automattic/jetpack/pull/34162/files

5. Enable support for content substitution for AI-generated content

Use Template Substitution to replace the default content in patterns with AI-generated content. This implementation can be made as follows:

This code should live within the plugins/woocommerce/src/Blocks/AIContent directory.

Text Substitution

• Open the patterns dictionary (plugins/woocommerce/src/Blocks/AIContent/dictionary.json)
• Parse the received HTML for the pattern via API, looking for the default texts as registered in the patterns dictionary.
• Replace the default content in patterns with the AI-generated content.

Images Substitution

• Add the default image URLs to the patterns dictionary so they can be cross-referenced like the texts.
• Parse the received HTML for the pattern via API, looking for the default image URLs as registered in the patterns dictionary.
• Replace the default image paths in patterns with the AI-selected images from Pexels.

Conclusion

That's a wrap! Looking forward to hearing folks' opinions regarding the proposed implementation, especially @nerrad , @danielwrobert , @albarin , @gigitux

[gigitux]

Thanks, Patricia, for this investigation! Everything LGTM. Even in a second iteration, do you think we should allow the possibility of changing the endpoint easily for extenders/adopters who want to have a customized set of patterns?

[nefeline]

Even in a second iteration, do you think we should allow the possibility of changing the endpoint easily for extenders/adopters who want to have a customized set of patterns?

Thanks for the feedback @gigitux! If we follow this route, IMO, it might make sense to allow some extendability, but honestly, I'm not sure what level of customization we want to provide. Certainly, something for us to discuss in more detail if we identify we can follow this route.

[albarin]

Thanks @nefeline!
The proposed implementation looks good to me 👌

Just a small doubt regarding step 3.

3. Ensure the migrated patterns are accessible via API
   In this case, we can either create a new API Service from scratch or rely on a pre-existing one for this purpose, ensuring it's possible to fetch each one of the patterns from the site you created via API.

If we successfully achieve steps 1 and 2, the existing API should work for our patterns as well, we shouldn't need to create a new API, right? Or do you anticipate we'll need different features that will force us to implement a new one? 🤔

Thanks!

[nefeline]

If we successfully achieve steps 1 and 2, the existing API should work for our patterns as well, we shouldn't need to create a new API, right? Or do you anticipate we'll need different features that will force us to implement a new one? 🤔

Thanks for your feedback @albarin ! That's true, in practice, all patterns would be accessible via the posts endpoint on WordPress (as the proposal is for each one of the patterns to be saved as posts), but ideally, I would say it makes sense for us to have an endpoint dedicated to patterns either way for the sake of having a clear nomenclature across the board.

[danielwrobert]

We will want to be sure to confirm the current policy on wp.org around hosting assets externally.

When we initially started working on Patterns, we wanted to host all of the default pattern images as an external resource to keep the plugin package size down. I did some exploration and discovered that it was not allowed. See this (internal) post for context: p6q8Tx-39F-p2.

With patterns becoming more prevalent and the fact that the patterns shipped with WP Core use images that are hosted on the wp.org CDN, perhaps this has changed. 🤞

[nefeline]

We will want to be sure to confirm the current policy on wp.org around hosting assets externally.
When we initially started working on Patterns, we wanted to host all of the default pattern images as an external resource to keep the plugin package size down.

That's a great point indeed, very important to check with folks on .org ahead of time.

[beaulebens]

We will want to be sure to confirm the current policy on wp.org around hosting assets externally.

This is a very good call-out; as far as I'm aware, this has not changed, and so explicit consent from the user would be required before we could request/download a pattern (or images) in this way.

[nefeline]

This is a very good call-out; as far as I'm aware, this has not changed, and so explicit consent from the user would be required before we could request/download a pattern (or images) in this way.

Could we consider extending the pre-existing .org Block Pattern Directory to include WooCommerce's patterns whenever the plugin is installed on a website? If we are open to exploring this idea, we could reach out to folks and ask.

https://make.wordpress.org/meta/2022/03/16/coming-soon-block-pattern-directory-submissions/

[nefeline]

Registering here for future reference that we are moving this discussion to #pluginreview channel on .org to gather additional feedback (the outcome of that discussion will be registered here as soon as we have more information).

[danielwrobert]

I started the DotOrg discussion in Slack here. Feel free to chime in with any thoughts/clarifications/etc.