Term Name block

[cr0ybot]

What problem does this address?

The Terms Query block comes with built-in block bindings, allowing for things like term name, slug, and URL to be used in blocks that support bindings. This is useful, but for core patterns being worked on in #71596, having only the Button block for including a link is very limiting. Plus, it is a little tedious to just display the term name and count, because you have to create a row and either buttons (if you want a clickable link) or just paragraphs for both the name and count.

What is your proposed solution?

Adding a new Term Name block would allow for easy creation of layouts with a linked term name and count beside it, similar to the Term List block output. It would be swell if it had options for a link, tagname, and showing the term count.

[kmanijak]

I'd strongly advocate for separate blocks for:

• Term Name
• Term Count
  so they can be easily arranged into various layouts like:

Also, I want to propose a Term Card block. This is something I consider missing in Query Loop/Post Template setup. Basically, a wrapper for the single Post (and here Term) instance that could become a link. This is a common and expected behaviour that the whole area of some item is clickable rather than just a text. In the above example would be great if the whole product category (including image area) was clickable.

As a nice to have, we can consider adding a Term Parent block that would allow for even more advanced use cases and layouts:

[cr0ybot]

@kmanijak I'm not opposed to separate blocks, though I still think that a Term Name/Title block should include the option to show the count. If there is a separate Term Count block, that one could be more useful if it included prefix and suffix attributes so that you don't need to add a row block just to put "products" next to it. I'd recommend opening a separate issue for the Term Count block, and if you want to pursue a Link Block (seems like it should ideally be able to handle all cases, not just term or post links) that definitely deserves it's own issue!

[kmanijak]

@kmanijak I'm not opposed to separate blocks, though I still think that a Term Name/Title block should include the option to show the count.

I don't think options to enable/disable content in block are really following a block-first approach. If toggle to "show count" can be implemented with block that you either insert/remove I think it's the way to go.

If there is a separate Term Count block, that one could be more useful if it included prefix and suffix attributes so that you don't need to add a row block just to put "products" next to it. I'd recommend opening a separate issue for the Term Count block

Great idea with prefix/suffix! #71954.

if you want to pursue a Link Block (seems like it should ideally be able to handle all cases, not just term or post links) that definitely deserves it's own issue!

Yeah, making it generic would be ideal. I feel it's a trap though, as I'd expect a Link block being already available in Gutenberg while for some reason it's not. Or at leasts discussed somewhere: #62262.

[ntsekouras]

I don't think options to enable/disable content in block are really following a block-first approach. If toggle to "show count" can be implemented with block that you either insert/remove I think it's the way to go.

I'd echo that.

[t-hamano]

If there is a separate Term Count block, that one could be more useful if it included prefix and suffix attributes so that you don't need to add a row block just to put "products" next to it. I'd recommend opening a separate issue for the Term Count block

Note that this may cause problems in terms of localization.

• The order of prefixes and suffixes may vary depending on the locale.
• The treatment of singular and plural forms may differ depending on the language.

As an example, this is one reason why we didn't introduce prefixes and suffixes into the Time to Read block. This discussion may be helpful: #43403 (comment)

If we were to introduce the Term Count block, I think it should purely display numbers.

[cr0ybot]

If we were to introduce the Term Count block, I think it should purely display numbers.

@t-hamano I'm struggling to see the point of such a block when we already have block bindings in place to do just that without adding another separate block to maintain. Can we at least have options for displaying the count in parenthesis or is the user expected to place the Term Count block in a row with a paragraph on either side? Not trying to be hyperbolic but the block editor has a serious paragraph-itis problem when it comes to situations like this.

I don't think options to enable/disable content in block are really following a block-first approach.

@kmanijak @ntsekouras Options for customizing specific chunks of dynamic content has loads of precedence:

• Image block has the option to show the caption
• Excerpt block has customizable read more text and you can change the length
• Author block has option to show bio
• Search results has option to show the search term

And there are others, but the most direct example is that the Term List block has an option to display counts!

My suggestions are coming from the perspective of usefulness and not necessarily from a philosophy of blocks perspective. We have to draw a line somewhere before granularity makes editing too complex, especially when the block editor doesn't really handle inline content.

[kmanijak]

@kmanijak @ntsekouras Options for customizing specific chunks of dynamic content has loads of precedence:

True but it doesn't necessarily mean it's the way to go.

And there are others, but the most direct example is that the Term List block has an option to display counts!

I think that's exactly the point. Term List is pretty limiting and my understanding was that making block more flexible (including breaking the content into inner blocks) was supposed to be the answer to those limitations.

My suggestions are coming from the perspective of usefulness and not necessarily from a philosophy of blocks perspective. We have to draw a line somewhere before granularity makes editing too complex, especially when the block editor doesn't really handle inline content.

I see what you mean, but I consider it limiting in terms of layout. I think it's important to provide users good defaults to choose from including inline Term Name - Count layout that they can modify easily if necessary (for example by removing Count). That's how I see we should proceed. But I don't agree we should sacrifice flexibility.

Term Name and Term Count separation is one of the requirements from Woo side that makes Terms Query a good base for Category Collection block.