Query Block - more advanced / multi select query options

[rmorse]

What problem does this address?

Just adding another perspective to the conversations going on around the query block UI / inspector.

I've been seeing a lot of potential UI options but most focus around the single select options:

• If you want to filter by post type, choose your post type.
• If you want to filter a taxonomy, choose your taxonomy, and choose your term.
• Author, same thing, probably (I didn't double check this one haha)...

I can't choose multiple terms, terms across multiple taxonomies, or multiple post types.

What is your proposed solution?

I like the idea of more control and power, but I realise that I'm trading this off for complexity when it comes to the UI.

Here is what I've built already:

This allows you to:

• Select multiple post types.
• After selecting a single post type, only that post types taxonomies appear
• After selecting mutliple post types, only taxonomies that are shared will appear
• You can always select multiple terms from any taxonomy available
• You can always select single or multiple authors

I realise that what I've made is far from perfect, but I would rather use this than the query block UI in its current format just because it allows for more control over the query - in the end, I hope the full "query block" would allow for even more customisability than this (the how though, I'm not sure).

If anyone wants to play with this to get a feel for it, find the "Custom Layouts" plugin in the repo.

Hopefully this can add to the conversation (even if its a - ruling this out as the way forward)

Thanks

Related: https://github.com/WordPress/gutenberg/issues/26668 https://github.com/WordPress/gutenberg/issues/26304

[hedgefield]

This makes a lot of sense to me! The Categories field in the Query loop currently already has this functionality, so let's extend that to the other fields too, like you describe.

You said you built this functionality already, does that mean you can create a pull request and complete the development? No worries if not, I'll add the Needs Dev label regardless so this can be picked up.

I think since you made this issue, the UI of the Query block has been updated a bit, but the idea still works. One extra thing I might add is some explanation text about what each of these fields means/does, but that might be a separate issue.

[rmorse]

Hey @hedgefield

I didn't fork/branch, I just re-made this in my own plugin (and probably not totally to standards)

Of course I'd love to contribute some of this work - I should be able to tidy some of this up and give it a go - my thinking is we'd need to get some more feedback on this first, A couple of questions I would pose:

1. What control types (ie. combobox features, like showing options on click / or waiting for text input before showing) would we want to use for the different instances? -
   • Author field
   • Taxonomy fields
   • Existing Tag + Category Fields
   • Any more?

My examples show a multiselect/combobox, which shows all the options available on interaction - which I believe does not exist in core yet (the category field requires text input before showing options and fetches its options via the rest api) - however , I don't think this solution is ideal just yet, I think this control still needs paging / rest api integration to fetch more options - after that I guess it would be a case of assigning different controls/features to the various inputs we need.

2. Also I think the conditional logic of showing / hiding taxonomies based on post type needs looking at, I feel there is some room for improvement (but haven't come up with anything else just yet) - and the way these fields then work - in that, when using multiple taxonomies the query logic combines them with the AND operator (does this need expanding?).

[sarayourfriend]

@mtias This would require the badge/tag component I believe, right?

[mtias]

Possibly! Not sure if it'd carry the same meaning as badges do in general, and whether the ability to remove one (the X) belongs in the component. We would need a proper design pass on these. I'm also not sure if it's the right use here.

[sarayourfriend]

Great, I've been asked to work on this so I'll wait until design takes a look.

[ndiego]

Just a quick thought on this... there are tons of uses for a mutli-select field component. Something akin to React Select would be awesome. I am using that in all my plugins at the moment, but styled to look more like core. It would great to be able to use a core component that was built explicitly for WordPress.

[sarayourfriend]

I think downshift is the perfect tool for this job actually especially for getting something that "feels" like WordPress.

[rmorse]

@ndiego I tweaked a core component (so it looks and feels native) to achieve this.

However, IMO core should ship with something like this (I've seen plenty of people requesting it), and I think that was going to be addressed in G2 Components but I've not seen much movement on that in a while.

Actually, @sarayourfriend, I just noticed you have been working on that too :)

[paaljoachim]

Here is another resource I came across: https://semantic-ui.com/modules/dropdown.html

Btw Hey Marco @ciampo I look forward to seeing what you can do with the multi select component to be used in Gutenberg and in core. Thanks.

[paaljoachim]

Associated trac issue. Which has some good discussions. (A few years have gone by though.) https://core.trac.wordpress.org/ticket/31696

What if we initially get the component in place. As there seems to be multiple places such a component can be used. Then begin to look at the design.

[carolinan]

It would be good to prioritize being able to do a query that finds both posts, pages and custom post types, especially for the search results.

[bradhogan]

Just want to throw my two cents in here that I think we really need a way for people to be able to exclude a taxonomy from a query in addition to the existing option of being able to only show posts from a certain taxonomy(ies).

[nekohayo]

It would be really nice to be able to combine different post/item types, just like the ability to mix and match conditions for categories, tags, etc. For example, someone may have a plugin that creates posts of a different type (i.e. they call them "projects", or "events", or "portfolio-item" or whatever, instead of making them normal blog post articles or pages), and you might want to be able to simultaneously display "post"-type articles and whatever else (ex: events) through the same query loop.

[cagrimmett]

+1

[ntsekouras]

There's a lot in this issue both in terms of design and functionality. I think what is needed for this 'umbrella' issue to move forward is to determine and prioritize smaller tasks and create new issues for them. An example would be to have a way to exclude taxonomies(categories, etc..).

[caseymilne]

I'd love to see a toggle switch to filter by current user. This would allow Query Loop blocks to be used on pages like a dashboard or account page where you have posts (usually custom posts) that are authored/owned by a user. For example I have a site where we have a ticket system and the ticket posts are created with the current user as the author. We can output all the tickets which is great for admin use, but we can't filter using Query Loop to show the user their own tickets.