The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mikachan <mikachan@git.wordpress.org>
Co-authored-by: kmanijak <karolmanijak@git.wordpress.org>
Co-authored-by: cr0ybot <cr0ybot@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: skorasaurus <skorasaurus@git.wordpress.org>
Co-authored-by: paaljoachim <paaljoachim@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +3.99 kB (+0.21%)

Total Size: 1.94 MB

_{compressed-size-action}

@mikachan Are we sure that we want to utilize the query context key for the term query block? There are a number of overlapping parameters but ultimately these are not compatible with the standard query block/context and are going to end up hitting the taxonomy term REST endpoint and the WP_Term_Query class, so I wonder if termQuery or similar would be a more appropriate context key.

I'm also not sure how the query arg showOnlyTopLevel interacts with parent, since parent=0 is how the REST API/WP_Term_Query would handle that and it's currently set to 0 by default in the block attributes.

Are we sure that we want to utilize the query context key for the term query block? There are a number of overlapping parameters but ultimately these are not compatible with the standard query block/context and are going to end up hitting the taxonomy term REST endpoint and the WP_Term_Query class, so I wonder if termQuery or similar would be a more appropriate context key.

Ah I see, in that case I think something like termQuery would be more suitable. I'll update this, thanks!

I'm also not sure how the query arg showOnlyTopLevel interacts with parent, since parent=0 is how the REST API/WP_Term_Query would handle that and it's currently set to 0 by default in the block attributes.

Yes, these are essentially the same display option, and they can probably be consolidated. I was using showOnlyTopLevel for the option in the settings panel, but I'll change this to update the parent parameter instead.

why can we not just extend/improve the current Query block? As it would be really nice to make the Query block even more powerful. Having a Terms Query block in addition to the regular Query block sounds confusing.

@paaljoachim, I didn't take part in decision making but I'd vote against extending Query Loop. Block is already complex with multiple inspector controls dependant on each other. And adding terms to it would just increase the complexity by another order of magnitude. Don't get me wrong - I see similarities: query data and render them them in loop, similar layout options, etc. but there's also many nuances that makes them different, like for example, terms can be hierarchical. Even from implementation side, one uses WP_Query underneath and another WP_Term_Query both with different capabilities.

However, breaking changes will not be allowed once merged, so that needs to be addressed in this PR.

@t-hamano, does it also stand if block was merged as experimental?

However, breaking changes will not be allowed once merged, so that needs to be addressed in this PR.

@t-hamano, does it also stand if block was merged as experimental?

Yes. As I understand it, __experimental: true simply indicates that something will not be shipped into core, not that breaking changes are allowed.

The more stuff we include in your first PR, the higher the risk of introducing changes that break backwards compatibility, so I personally prefer to ship something minimal and robust. That's why I proposed removing the namespace attribute and placeholders.

That said, my understanding is that if we really want to ship a truly experimental block, we can include it in the following settings:

Yes. As I understand it, __experimental: true simply indicates that something will not be shipped into core, not that breaking changes are allowed.
...
That said, my understanding is that if we really want to ship a truly experimental block, we can include it in the following settings

Ah! I was convinced the block is behind this flag! So of course I agree @t-hamano, thanks for explaining.

@mikachan, I think it would be good to do mark the block truly experimental to include it in the setting for the time being. I'd like to buy a bit more time to make sure we can extend the query from WooCommerce side so we can display terms contextually (e.g. subcategories of currently viewed category).

This block, like the Query Loop block, is a bit more complex, so I'd like to ping the core team for visibility @WordPress/gutenberg-core. Any feedback is welcome.

In summary, this PR is shipping two blocks: the Term Query and Term Template blocks. The design is similar to the Query Loop block, but a notable feature is that it uses the Block Bindings API to display term data.

@mikachan, would you be open to merging "Order" and "Orderby" dropdowns? They occupy quite a lot of space while they can be easily combined into more compact single dropdown with options:

• Name: A → Z
• Name: Z → A
• Slug: A → Z
• Slug: Z → A
• Count, high to low
• Count, low to high

Also, I may be missing something but I don't see a use case for ordering by slug. How about removing it completely? I'm happy to provide a PR once someone confirms it's a good way to go. 🙌

As I understand it, __experimental: true simply indicates that something will not be shipped into core, not that breaking changes are allowed.

@t-hamano I also didn't realise this, I thought that experimental: true meant that the block was put behind the experimental blocks flag, and a user would need to enable experimental blocks to use it. What else do we need to do to ensure this block is behind the correct flag (truly experimental)?

would you be open to merging "Order" and "Orderby" dropdowns?

@kmanijak Yes, this sounds like a good idea. Are there other components that use a similar pattern to this?

Happy to remove ordering by slug too, sounds good!

That said, my understanding is that if we really want to ship a truly experimental block, we can include it in the following settings:

@t-hamano I've just been testing with the experimental block setting, and I'm seeing that any block that has __experimental: true is not available when the "Blocks: add experimental blocks" option is not checked. I believe they're the same setting, and this setting exists so that we can safely iterate on blocks before they're stabilised and included in Core. Let me know if I'm misunderstanding.

I think I've figured out the experimental setting issue with this block 👀 Looks like the block was being included in the main array for all blocks rather than the experimental list. Should be fixed with 6e45569.

@mikachan I'm having trouble with trying to create/edit patterns for #71528. I can't seem to create a hierarchical pattern. Upon insertion, parent: 0 is always added (even though I've left it out of the termQuery object), which turns hierarchical off, and the result is this locked-up UI situation:

Edit: Nevermind, I've found the culprit in my own code!

Note however that this does mean that setting both parent:0 and hierarchical:true will lock up the controls like this.

I think I've figured out the experimental setting issue with this block 👀 Looks like the block was being included in the main array for all blocks rather than the experimental list. Should be fixed with 6e45569.

That's right. If we want to include the Term Query block in the block experiment setting, we need to add the block inside the window?.__experimentalEnableBlockExperiments if statement.

By the way, I think that we also need to move the Term Template block.

That's right. If we want to include the Term Query block in the block experiment setting, we need to add the block inside the window?.__experimentalEnableBlockExperiments if statement.

In my testing, the block is now only showing when experimental blocks are enabled. Are you still seeing the block when the experiment is turned off?

By the way, I think that we also need to move the Term Template block.

I've moved the Term Template block now as well: 47423d4.

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin, New Block.
• Labels found: New Block, [Type] Experimental, [Block] Terms Query (experimental).

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.