Dynamically generate Query variations for registered post types

[jameskoster]

It was mentioned in #39837 (comment) that it would be good to dynamically generate Query variations based on existing post types.

In addition to generating the variations themselves, I hope that we can use the design concepts in #32268 to also dynamically populate those variations with the appropriate filter options, based on the taxonomies attached to the post type.

So if I register a "Recipes" post type with categories "Pizza Dough" and "Pizza Sauce", I should find a "Recipes List" block which includes options to filter the posts it displays based on those categories.

[ntsekouras]

👋 - I've been toying with this and was wondering what convention we should use for the variation name's. The main problem comes from pages, as we already have a Page List block and is navigation related..

In addition I was thinking that if we have such variations in place we should also hide at least the post type control. Then maybe add some block transformation options to switch the post type if someone wants to? 🤔

[jameskoster]

Good questions.

The main problem comes from pages, as we already have a Page List block and is navigation related..

An initial thought here is that Page List could have a different name, especially as it renders as a row rather than a list when placed in the Navigation block. "Page Links" perhaps?

Continuing that line of thinking, perhaps we should avoid "List" altogether here... Queries are often arranged into grids after all. "Pages", "Posts", "Products" might be too simple, but are probably a good place to start?

In addition I was thinking that if we have such variations in place we should also hide at least the post type control. Then maybe add some block transformation options to switch the post type if someone wants to?

I see this work as a precursor to simplifying the base Query block UX. I still believe that it should be a template-only block that always inherit from the template, and is most likely removal-locked. The variations should feel like discrete blocks, so transforming between them seems like a good idea 👍 Their use cases are more additive than foundational. E.g. "I want to display some featured products in this blog post" or "I want to list my 5 latest posts in my site footer".

[ntsekouras]

Their use cases are more additive than foundational. E.g. "I want to display some featured products in this blog post" or "I want to list my 5 latest posts in my site footer".

I'm exploring how extenders could make the most of it for specific use cases like that, but we still need to handle the 'plain' variations that would restrict results to just a specific post type.

An initial thought here is that Page List could have a different name, especially as it renders as a row rather than a list when placed in the Navigation block. "Page Links" perhaps?

That could be done independently.. Any thoughts @tellthemachines, @getdave, or any of the folks that have worked much in Navigation block and the Page List?

[jameskoster]

I'm exploring how extenders could make the most of it for specific use cases like that, but we still need to handle the 'plain' variations that would restrict results to just a specific post type.

Hm, aren't they the same thing? 🤔

"I want to display some featured products in this blog post"

Here I'm thinking that you'd insert the "Products" block, then configure the appearance, number of products, etc.

"I want to list my 5 latest posts in my site footer"

For this one you'd insert the "Posts" block, remove all the inner blocks except Post Title, and set posts-per-page as 5.

I don't think we need dedicated variations for these kind of use cases – that feels like a job for patterns.

That could be done independently

👍 cc @javierarce as well, I think you've been looking at navigation stuff?

[draganescu]

One thing we tried to communicate by using "Pages list" is that it is a discrete entity in the menu, which has it's own functionality and independent features. Using "Page links" feels as if we're adding a bunch of links, but it's not true, one has to click "Edit" to decompose the Pages List to a list of page links - losing auto updates in the process.

The challenge with using single words "Pages" "Products" is similar in that it removes the idea of self contained functionality. But, this may only apply to pages? A variation of the query block will be just a list of entities, however the Pages List block is meant to be the most basic self maintaining navigation, equal to the hierarchy of pages a user has. Not sure, but should we even treat it in the same group as other CPTs?

[ntsekouras]

I'm exploring how extenders could make the most of it for specific use cases like that, but we still need to handle the 'plain' variations that would restrict results to just a specific post type.

Hm, aren't they the same thing? 🤔

There might be some more nuances with complex meta queries(not supported yet), so extenders might need explicit variations and 'hide' the implementation details by using toggles maybe and not adding new complex filters. We'll see.. 😄

[jameskoster]

I think the Page List block is probably something to discuss separately. There may even be an argument that it should just be a pattern for the "Pages" query variation 🙊

For these variations can use a different nomenclature to begin with, and refine in the PR.