WordPress
Term Query Loop Block
What problem does this address?
Currently you can create a tag cloud, and there's a post term list, but these options are limited, and come in 2 versions ( one for the current post, and one that's just general ). If I need to build anything that deviates from this I'm forced to build a new block.
E.g. if I want to display terms with their term descriptions, or add a graphic next to each tag, sort terms into columns, etc, I can't do that with core blocks. Or even spread terms out in a row the same way a group/row block can.
e.g. creating this type of category list automatically is not possible with the core blocks:
Politics
News articles about politics
Sports
The latest sports news
What is your proposed solution?
Instead, A term query block similar to the post query block would be very useful, with term title, term description etc blocks.
This way the existing core blocks could be constructed in any shape form or layout by the users choice without writing code. E.g. using headings for tags with descriptions, custom term featured image blocks in plugins, adding icons, etc
Variants of the block could be registered for each taxonomy too:
+1 on this. It's a very common pattern for themes that we can't really work around right now. A good example is the section By Topic on Blue Note, a community theme currently in development: https://github.com/WordPress/community-themes/issues/5
The query look actually allows for this already. You can filter the query loop based on a tag or a category:
@scruffian you've misunderstood, this issue is not about displaying posts in a term, it's about displaying the terms themselves!
E.g. it would not produce a post list, it could produce a tag list like this:
Or more complex items, e.g. a heading with a read more button underneath with a term description
+1 this! Are there any updates/decisions made about adding this new block?
We want it, we just need someone to build it!
Noting that this will need scoping out by an engineer to figure out exactly what needs to be done, it's not as simple as asking for it to be done then someone doing it.
For example, issues for at least these blocks would need to be created:
- Term Loop
- category and tag variants with the taxonomy preset
- term template block
- no terms block
- term name/title block
- term description block
People can probably think of more such as a term slug block but these seem to be the MVP, and each of those will require its own issue and dependencies.
I can also see API changes being desirable re: variations. Afterall if you use a category loop you don't expect a term template, you expect a category template, and a category name/title, making those blocks dependent.
There's also the possibility that because the terms are different entities that it might require taxonomy specific blocks be registered or variants for each taxonomy so that they know which entity type to access and can display the right information.
For those versed in agile, this is more like a spike than an implementation ticket, help/contributions needed for specification
+1 this! Are there any updates/decisions made about adding this new block?
This is pretty straight forward to answer. Unless you see PRs mentioned here then there has been no work done to build this. If you can't see any decision making then that means no decision making took place.
If there were a place were decisions were made related to this that didn't filter down it'd be the public weekly editor meetings, but someone would have to raise it on the agenda, and it's highly unlikely the info wouldn't filter over to here. Unless someone made another issue and that one got traction instead.
Punted for the same reason as before. This is going to take intentional effort to get done so if anyone is interested for 6.6, please speak up!
I'm working with term meta and terms for the first time in several years (or ever?) and came across this issue while reviewing what capabilities exist in Gutenberg in order to find a block that would display all terms that exist for a particular taxonomy across an entire website.
Even after some research about the current state of such a block; I was a bit confused and found this issue which heavily overlaps with https://github.com/WordPress/gutenberg/issues/33302 (This is cross-posted in #33302 as well).
I include some notes in case anyone else has the same issue or is trying to triage this issue:
Categories block - lists all terms that exist for the taxonomy 'category' across an entire website.
In the block inserter and list view, the block is called 'Categories List'
Block markup: <!-- wp:categories /-->
Only can select the 'category' taxonomy
Post Terms block - lists the terms that are assigned for a taxonomy (selected in the attribute field) on a particular post or page
In the block inserter and list view; these blocks are named "Categories" or "tags"
<!-- wp:post-terms {"term":"category"} /--> or
<!-- wp:post-terms {"term":"post_tag"} /-->
If you register a custom taxonomy, a block variation for the post terms block is registered. It appears in the block inserter and list view as "Name of your taxonomy(s)"
Tag cloud - lists all of the terms that exist for the taxonomy "post_tag" across an entire website.
in the block inserter and list view, the block is called 'Tag Cloud'; displays it in a cloud like format.
Only can select the taxonomies 'category' and 'post_tag'
There are a couple existing PRs https://github.com/WordPress/gutenberg/pull/58033 & https://github.com/WordPress/gutenberg/pull/26555 that modifies the categories block to select any taxonomy and displays all of that taxonomy's terms on the website.
Going forward in the long-term: I think a new flexible block(s) would probably be appropriate as Tom described at https://github.com/WordPress/gutenberg/issues/49094#issue-1625439496
There is a separate block under development - https://github.com/mattyza/terms-list-block but I haven't examined it.
@skorasaurus has perfectly described what we and doubtless thousands of other developers need as well - a block that would display all terms which exist for a particular taxonomy. (Ideally with some straightforward way to modify the query being run by that block, so we could filter it by children of a particular term, etc.) It's baffling to me that custom taxonomies are such a fundamental feature of WordPress, people have been asking for some variant of this request for years, and yet resources are being spent to building a real-time multi-user version of Gutenberg or whatever instead of creating this block. For now we are probably just going to hack this up in PHP and punt on the template being block-editor-friendly, since in the old world this is basically just a call to get_terms() that takes two minutes to write.
@aaroncommand he's only in charge of spending his own personal time that's contributed and volunteered here, there's no corporate decision delaying this from being built or product roadmap that punted this.
For this to move forward what's needed is for an engineer to scope out what has to happen so that others know what to do and where to do it. Building this for a single client/customer is easier than making sure this gets built properly for core as tiny engineering decisions can have huge ramifications.
Any support you can show will help here enormously even if it only answers part of the puzzle
Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.
Ran into this while creating a block theme. Definitely a big limitation. There's currently no nice way to create a section like this in a block theme:
Instead of a new block, could Categories and Tags be an option in the Query Loop block's settings? I suppose maybe not since there'd need to be an accompaniment of related inner blocks e.g. Taxonomy Title and Taxonomy Count.
Instead of a new block, could Categories and Tags be an option in the Query Loop block's settings? I suppose maybe not since there'd need to be an accompaniment of related inner blocks e.g. Taxonomy Title and Taxonomy Count.
We cannot use Query Loop. We'd need to update some existing term blocks and add new ones.
Came across this implementation of a Term query loop - elegant! https://brickslabs.com/how-to-list-your-posts-divided-by-categories/ Excited for this! 🔥
@kauaicreative that's using the bricks page builder not Gutenberg
Yes, bricks. I have not personally used Bricks - but the implementation may offer some inspiration:
- A single Query Block allows one to query either terns or posts e.g. Choose Terms as query Type and Categories as the taxomomy.
- It allows for nested query loops which is explained in the referenced tutorial link.
@cr0ybot I'll gladly help review & test your solution in case you plan on bringing them into core 👀 really cool to see some movement here 🤩
@fabiankaegy Thanks! That would be really helpful. My approach has basically been to duplicate the Query Loop block and modify it to work with taxonomy terms. I also had to cut out a bunch of stuff for the sake of my own time, like the pattern chooser.
~I got a bit stuck for a while trying to figure out why my bindings from block context weren't displaying properly in the editor until I discovered that custom binding sources still currently display placeholders in the editor!~ Oops, I see there are new editor APIs in 6.7 for rendering custom binding sources in the editor!
I have this plugin mostly working, ~though I haven't built any releases yet for easy download/install~ download via releases in the repo. It works in the general sense to list taxonomy terms with customizable child blocks and also can "inherit" the "query" so that you can list terms for a specific post or child terms on a taxonomy term archive.
https://github.com/cr0ybot/term-query
I'm handling the display of term info/meta using block bindings, which is simultaneously cool and somewhat difficult to work with. I've added variations of the heading, paragraph, and button blocks to attach the appropriate block bindings, but obviously these blocks are not scoped to the Taxonomy Terms block only. Not quite sure if there's a better way of handling this sort of thing yet, but I'm definitely not making the same mistake I've made before by adding a bunch of custom blocks for what amounts to some text and links.
👋 That plugin is looking great, @cr0ybot. I like how you've used block bindings rather than creating new blocks. Are you planning on opening a GB PR to include it in Core? I'd be happy to help test and review.
I've also had a go at creating a Terms Query block over in https://github.com/WordPress/gutenberg/pull/70682 (before I saw your plugin!). It's still a work in progress and at the moment I'm mostly testing out implementation ideas. I did create new inner blocks 😅, although only two so far, for the term name and count.
My plan at the moment is to keep tinkering and then eventually open smaller PRs, but I'd be happy to help with your solution instead if you plan to open a PR.
@mikachan I wonder if he is still working on the plugin. The last commit was quite long ago. Presuming that he is no more working on this issue I too have been working on this since a month. I guess we are gonna end up with a bunch of same stuff 😅
@sarthaknagoshe2002 Oh really?! Well, I'm also happy to help out there 😁 Do you have a PR?
We might be able to separate some parts of the work, e.g. it'd be nice to have the containing Terms Query and Terms Template blocks in place to build on top of, or we could work off a feature branch if that's easier. From working on this over the last few days, my rough plans were:
- Create the containing Terms Query block
- Create Terms Template block
- Add inner blocks, at least for Term Name and Term Count initially. (Or, try using block bindings so we don't need individual blocks.)
Once we have those new blocks, we can then look into expanding the functionality with things like:
- Include/exclude terms controls
- 'Show only child terms' option
- Allow inheriting the terms query from the current template
- More layout variations
I'm thinking about this block as one like the query loop where patterns will help a lot of users to build their layouts with this block. The main difference with the query loop is that we default inheriting the loop and that makes it really easy for a theme to provide a pattern that is content agnostic. This is way harder for a terms block, where the content can't be inferred by the theme as easily (one might have a specific term type that is very deeply nested, for example).
What I mean to say is that when we make decisions for this block, we need to think about how it will be used. The way I think about it for this block to be the most useful, it should have a state where a theme can provide a pattern without having to select specifics that are tied to a specific site's content and still be useful, so that the end user only needs to select those specifics to tweak what content to show. I don't know if I'm being clear here?
We're planning on adding an inherit setting similar to the Query block, so that the block inherits the current template's taxonomy context. And then users would still be able to overwrite this with specific settings if necessary. Do you think this would be enough for most patterns?
We're planning on adding an inherit setting similar to the Query block, so that the block inherits the current template's taxonomy context. And then users would still be able to overwrite this with specific settings if necessary. Do you think this would be enough for most patterns?
It's hard to say. Most patterns I have seen designed have one to three categories selected and showed (with a related picture) in the home page. I think ideally we want to add the ability to have a featured category image block that we could include in this new block. I understand that's an extra step after the basic foundations are already there, but it's probably what will give more flexibility for layouts given what I've seen designers design for themes so it's good to have in mind as to where we could be walking towards.
I think the inherit option is a good starting point for sure!
Yeah, I've seen images mentioned a bunch of times for categories. I'm thinking that allowing the block to handle inner blocks is a good step forward there, but maybe we could also include some variations that involve images, too. We probably need a new inner block, or this might be a good place to use block bindings on the existing image block.
Thanks, I'll keep these things in mind as we work through this!