Pattern Directory API: Provide Hook for Third-Party Directories

[justintadlock]

As more and more theme/plugin developers transition to using patterns, many will want to serve up custom patterns to their users and customers. While we certainly want devs putting their patterns into the official directory, that is not the only way they should be served to users.

In some cases, patterns rely on a theme's Block Styles, so they are not suitable for the directory. In other cases, devs may want to provide commercial upgrades. Sometimes, freelancers/agencies will need to provide patterns to multiple clients and keep them updated. The discussion and some initial code work has already started in one of the theme dev groups I am involved in.

I'm guessing that it will be commonplace to provide patterns in this manner.

Currently, the only way I see to do this is to hook into either pre_transient_wp_remote_block_patterns or transient_wp_remote_block_patterns. That really doesn't seem like the ideal method of handling this, but it is likely what devs will begin using. And, I really don't want this to turn into one of those situations where we wait 10 years to help out third-party vendors like we did for a proper plugin update hook.

There should be dedicated filter hooks for tacking extra patterns on top of core ones (or multiple vendors) or overwriting them wholesale.

[colorful-tones]

I would truly love to see the ability to filter the /pattern/ directory.

https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/block-patterns.php#L373

@justintadlock where are these mysterious transient_wp_remote_block_patterns or pre_transient_wp_remote_block_patterns hooks? Perhaps they were deprecated?

This should take precedence over projects like #49174 and #44611 in my view. 😄

[richtabor]

Eh, this is interesting but not high priority imo. Adding patterns to the patterns directory and loading via theme.json is simple enough to tack on extra patterns.

The bigger issue on that front is being limited to core blocks within the directory. It'd be nice if there was a way to use non-core blocks within patterns on the directory; may be a better front to focus on instead of third-party directories?

[ntsekouras]

I think this is very relevant to the direction of the pattern block.

[richtabor]

I think this is very relevant to the direction of the #48458.

How do you mean?

[justintadlock]

@justintadlock where are these mysterious transient_wp_remote_block_patterns or pre_transient_wp_remote_block_patterns hooks? Perhaps they were deprecated?

When the directory code was added two years ago, the response was stored as a transient (all transients have hooks). I'm not sure if that's still the case. I haven't dug into the code for a while.

Eh, this is interesting but not high priority imo. Adding patterns to the patterns directory and loading via theme.json is simple enough to tack on extra patterns.

The bigger issue on that front is being limited to core blocks within the directory. It'd be nice if there was a way to use non-core blocks within patterns on the directory; may be a better front to focus on instead of third-party directories?

For shops that have products outside of the official directory or even theme authors who prefer not to host patterns on DotOrg, these would be super useful. There are potential applications for hosting companies with custom offerings. Plugin authors could even use this to do contextual sets of patterns.

I agree that there are other things that are higher priority with Patterns. But, this enhancement is a simple, one-line filter hook addition, I'd imagine. It's low-hanging fruit that would be beneficial to the larger ecosystem that builds on top of WordPress. It's one of those easy wins that would make it easier to "sell" the idea of patterns to more and more creators.

[justintadlock]

Following up on the transient name and the places in the core code:

It looks like it's calling get_site_transient() here: https://developer.wordpress.org/reference/classes/wp_rest_pattern_directory_controller/get_items/

So, the hooks would be:

• pre_site_transient_{$transient}
• site_transient_{$transient}

But, the transient name is now 'wp_remote_block_patterns_' . md5( serialize( $query_args ) ), which you can find here: https://developer.wordpress.org/reference/classes/wp_rest_pattern_directory_controller/get_transient_key/

That's what I was able to find with a quick search.

[colorful-tones]

Awesome, thanks for the follow-up @justintadlock . I tried doing some Googling and GitHub searching and came up empty, and glad you shared this knowledge. 🤘

[justintadlock]

Sorry for the multiple responses. That's what happens when you try to catch up on a two-year-old ticket and are now realizing there are other options. :)

I will say that when I first wrote this ticket, the code was a bit different than it is today. I don't think there were featured patterns at the time, at least the transient wasn't based on the queried args. I'm certain quite a bit has changed.

Directly filtering what WordPress is doing might not be the best route based on the changes since then (I'm not familiar enough with that part of the code to say so 100%).

However, there may be better alternative routes for third-party devs right now. Since WP 5.8.0, there's now a should_load_remote_block_patterns filter hook that can easily disable remote patterns. Then, just write your own callback for registering custom remote patterns.

add_filter( 'should_load_remote_block_patterns', '__return_false' );

add_action( 'init', 'jt_register_remote_patterns' );

function jt_register_remote_patterns() {

	// Check if custom patterns are stored in a transient.
	// If not, load remote patterns via the WP HTTP API.
	// Store response as a transient.

	// Register patterns.
}

This is just me thinking a bit on the fly, and I'd love to see some testing around this (might even be enough to close this ticket). It might still be better to have an "official" hook for overloading remote patterns, but I'm thinking that it's very much possible to at least control the core vs. custom patterns today.

[colorful-tones]

I think this is very relevant to the direction of the #48458.

@ntsekouras I agree. I believe allowing for the Pattern directory path to be filtered would be a wonderful addition for 3rd party plugins and builders and should very likely fall within the threshold of Phase 2: Customization work. Hence my comment here, but thinking I might follow up on 48458 too now.

Adding patterns to the patterns directory and loading via theme.json...

@richtabor Pattern directory is a whole other project that needs attention. Meanwhile, allow extenders to filter the directory.

The bigger issue on that front is being limited to core blocks within the directory.

Not a bigger issue, but certainly has the same relevancy.

It'd be nice if there was a way to use non-core blocks within patterns on the directory; may be a better front to focus on instead of third-party directories?

Why not both, but this Issue highlights one; whereas I'm sure there is another Issue that addresses the prior.

Directly filtering what WordPress is doing might not be the best route based on the changes since then

@justintadlock thanks for digging in and totally understand that things have changed, but still feel like allowing the directory path to be filtered seems like a reasonable request for 3rd party extenders.

[richtabor]

But, this enhancement is a simple, one-line filter hook addition

@richtabor Pattern directory is a whole other project that needs attention. Meanwhile, allow extenders to filter the directory.

I mean if it's a one-liner, and there are not privacy/security concerns, that's great — but otherwise, there are plenty of plugins that showcase how to add patterns via an external source. And further, its trivial to add patterns via a plugin.

but still feel like allowing the directory path to be filtered seems like a reasonable request for 3rd party extenders.

Are people asking for this? Or are they just doing it themselves anyhow via their own methods?

[richtabor]

It'd be nice if there was a way to use non-core blocks within patterns on the directory; may be a better front to focus on instead of third-party directories?

Not related to this particular issue, but we could potentially add a method for a pattern to require a plugin, or block, to be available in the inserter.

[colorful-tones]

there are plenty of plugins that showcase how to add patterns via an external source. And further, its trivial to add patterns via a plugin.

I must be oblivious. @richtabor what hook or filter are all these plugins using?

[richtabor]

there are plenty of plugins that showcase how to add patterns via an external source. And further, its trivial to add patterns via a plugin.

I must be oblivious. @richtabor what hook or filter are all these plugins using?

They're not using those, as they don't exist :). Extendify is one example of a plugin loading its patterns from an external source.

[colorful-tones]

@richtabor perhaps you can write a post for the community on how to do this if it is trivial and then the whole community will benefit and have a standard means of doing it. The Developer Blog would likely be a great venue for this.

Once it is published then we can likely close this Issue.

[Stephen-Cronin]

Having an official way to do this would be far better than everyone doing their own non-standard thing. We've often seen things get a little messy when everyone creates their own solution, whether it's notifications, or page builders, or whatever... Might be better to get in early(ish) and create an official way to extend this.

[colorful-tones]

Having an official way to do this would be far better than everyone doing their own non-standard thing. We've often seen things get a little messy when everyone creates their own solution, whether it's notifications, or page builders, or whatever... Might be better to get in early(ish) and create an official way to extend this.

@Stephen-Cronin yes, this is where the heart of the matter lies for me. I would love to see a filter for this and believe this was the original intent of the Issue. A consistent builder-specific hook for everyone to use and standardize on. 👍

[colorful-tones]

I've added this to the Gutenberg Phase 2: Customization board and assigned it a Priority: Normal, but feel like it could easily be High. Especially in contrast to #49174 , which would seem to take greater effort, but is hard to determine. They're both important. I would love to hear more feedback from the community.

I wonder if the @WordPress/block-themers might have feedback. 🤔

[richtabor]

A consistent builder-specific hook for everyone to use and standardize on. 👍

Well, that's the Pattern Directory yea? 🙃

[mikemcalister]

Patterns are a game-changing feature that will be a huge part of WordPress's future. We need to prepare for their growth and extensibility now rather than later.

There are going to be many instances where developers need to provide extra patterns to customers and clients, and many valid instances where it's not ideal or possible to use the pattern directory. A standardized mechanism would go a long way to providing a cohesive developer experience.

Currently, some of the rules around patterns submitted to the directory state:

• Patterns shouldn’t be designed for a single theme.
• A pattern shouldn’t be a full page or blog post.
• A good pattern is opinionated and has a well defined purpose.
• A good pattern keeps placeholder text to a minimum.

Limitations are fine for the directory, we need them to maintain quality control. But this places arbitrary limitations on developers and business owners by dictating that only a certain kind of pattern is meant for the directory. Many patterns created for commercial and client instances won't fit this mold.

In order to increase adoption and promote innovation, I would love to see a standardized hook here.

[caseymilne]

Sorry this isn't about the proposed hook, but could someone clarify if 3rd party block types are allowed in the patterns registry? I don't see it mentioned in the guidelines whether they are/not allowed.