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: cr0ybot <cr0ybot@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>

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

Tagging @mikachan, @t-hamano, and @ntsekouras for review since I can't request reviewers.

I'm wondering how can we make this scalable and what are the use cases we want to support. I'll just share initial thoughts..

Maybe it's fine for wanting to show one level more (children), but would that be common? Let's assume it is common, then do we think that for those use cases the desired design would be similar to terms list? If yes, should we do it?

In my mind this block aims to help with 'banner' type patterns in a site to showcase some terms for easier selection - and in that case the 'handpick' categories is really important. To add to that, a user could want to showcase in the same level a parent category and a specific child.

Let's assume again we go this way:

1. I think there shouldn't be any flag and instead check if it has a parent terms-query. If we don't do that, what use case could we have to duplicate the same content with the parent block, inside the block?
2. The nesting levels of categories is dynamic and this will make impossible to make the block work well, if a user would indeed want to show all child terms (they would have to insert too many nested Terms blocks). For that, this is not scalable.

It's a tough problem to solve and mostly because we don't know exactly what we should support yet. I'd love some more opinions on this. --cc @kmanijak @jasmussen

This feels like it could create a fairly complex block structure for what seems like a relatively simple use case of showing terms and their children. Nesting Terms Query blocks starts to feel like loops within loops (or functions within functions), which can quickly become tricky for theme authors to build and reason about.

From a design perspective, I wonder if it might be simpler to have the Term Template block automatically include child terms. If we need flexibility, we could add an option like “Levels to show” (defaulting to “All” or allowing 1-n). That might achieve the same outcome without requiring nested query blocks.

1. I think there shouldn't be any flag and instead check if it has a parent terms-query. If we don't do that, what use case could we have to duplicate the same content with the parent block, inside the block?

@ntsekouras That is essentially what I had in the previous nesting PR (#71916), but it was too big and complex so I started over (multiple times). The block would automatically detect an inheritance context and actively remove or change block attributes to a supported/minimal configuration (to varying degrees of success). It also required the parent Terms Query block to have it's own block context filter, because otherwise a Term Template block will only see the termQuery in context from it's own containing Terms Query block and not the one above that. The approach in this PR was an attempt to make this work in a very minimal way.

2. The nesting levels of categories is dynamic and this will make impossible to make the block work well, if a user would indeed want to show all child terms (they would have to insert too many nested Terms blocks). For that, this is not scalable.

I agree that this block doesn't scale well to all levels of a taxonomy, I just don't think that is important since we have a way to list all levels already. If a user really wants all levels it's hard to imagine a situation where they would want control over the design of each level anyways, and the Term List block should fit those needs.

Nesting inheritance enables a focused way to present a set of terms and their children in a designed layout. I could show the original issue's example image again but I'm pretty sure we're all familiar with it. You can interpret it many ways, but to me it shows a taxonomy called "Topics" with a top-level "Water" term and it's child terms listed in a horizontal list of links below. This is a way to allow a user to drill down into a more specific topic than having to click through multiple links.

Nesting Terms Query blocks starts to feel like loops within loops (or functions within functions), which can quickly become tricky for theme authors to build and reason about.

From a design perspective, I wonder if it might be simpler to have the Term Template block automatically include child terms. If we need flexibility, we could add an option like “Levels to show” (defaulting to “All” or allowing 1-n). That might achieve the same outcome without requiring nested query blocks.

@jasmussen It is in fact a loop within a loop, but this is a very common design pattern for WordPress sites. Another example I've seen over and over again is grouping posts in an "archive" by their taxonomy term—not something this PR handles, but I could see eventually supporting that kind of inheritance in the Query Loop block.

It would be simpler to just show nested child terms—in fact that's how this block worked in its initial iteration—but having no control over the layout of those additional levels makes no sense in the block editor context. It might look ok when displayed as a bulleted list, but how do you display nested terms when the template is in grid mode? It quickly breaks down into something unmanageable. We have the Term List block for simple nested term lists.

I agree that this block doesn't scale well to all levels of a taxonomy, I just don't think that is important since we have a way to list all levels already. If a user really wants all levels it's hard to imagine a situation where they would want control over the design of each level anyways, and the Term List block should fit those needs.

I'm starting to think we might not want to support this with this block. Besides scalability it seems that if a user would want all levels they should use Terms List block, as you also mention. They could use some css to achieve the shared screenshot from @cr0ybot already.

If we'd want to show the child terms of a single terms, we could do that with the parent prop and a control.

I'm not 100% sure what we should support TBH and if I'm missing important use cases and what would be the expected usage and value of this block. IMO this block is the most valuable for handpicking categories and the include functionality is the most important one, but 🤷 . I've also asked for more designers feedback.. @t-hamano @Mamaduka @jameskoster any thoughts?

I'm starting to think we might not want to support this with this block. Besides scalability it seems that if a user would want all levels they should use Terms List block, as you also mention.

Agreed. Nesting Query blocks just to get all levels of terms doesn't seem like an ideal solution. I don't think this is how someone would write the custom PHP queries for them.

P.S. The similar enhancement request is still open for the Query block - #68620.

I'm starting to think we might not want to support this with this block. Besides scalability it seems that if a user would want all levels they should use Terms List block, as you also mention.

+1

At least, I don't think it's a feature that's essential for the 6.9 release, or for stabilizing the block.

Nesting Query blocks just to get all levels of terms doesn't seem like an ideal solution. I don't think this is how someone would write the custom PHP queries for them.

I want to reiterate that I'm not advocating for nesting to display all levels. I'd also like to point out that this is exactly how lots of folks handle custom nested term queries in PHP, for example: https://stackoverflow.com/a/67316967

Without doing it this way it is possible to end up with orphaned terms in the flat list returned by WP_Term_Query, as I discovered here: #71596 (comment)

P.S. The similar enhancement request is still open for the Query block - #68620.

From #68620:

If the posts would be children of a singular post I could use the parents field. But for top level post don't have a parent and there is no way to set the parents field to 0.

Not sure that is relevant here, we already handle showing top level terms only.