Categories List block: Add variations for taxonomies #64805
Conversation
ockham
added
[Type] Enhancement
|
Size Change: -91 B (-0.01%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
ockham
requested review from
ajitbohra,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @skora-cpl, @MikeB8s, @sophiegyo. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Thanks for your work on this @ockham
I really appreciate the descriptions made by block_core_categories_build_variations
As of 752c993 :
I am able to successfully display all terms registered for a few different custom taxonomies.
From a functionality perspective, I noticed that when the showHierarchy attribute is marked as true and a variation for a taxonomy that does have a hierarchy (I believe that's controlled by hierarchical => false (as shown in https://gitlab.com/cpl/citation-manager/-/blob/72c2638d9827dea5d465be0db5d3ba41dfe3ae88/register-taxonomies.php#L47 & https://gitlab.com/cpl/citation-manager/-/blob/72c2638d9827dea5d465be0db5d3ba41dfe3ae88/register-taxonomies.php#L135); the list of terms did not display within the editor (and there was no message in the editor or the console) but the list of terms displayed on the frontend.
|
Flaky tests detected in 1ba1c00. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10679375583
|
|
Thank you very much for testing this, @skorasaurus!
Ah right, I see what's going on here. Hierarchical terms are "category-like", whereas non-hierarchical ones ("flat terms") are tag-like. The Categories List block (and underlying code, cf.
However, this option makes no sense for flat terms, since there is no hierarchy -- and thus, no nesting to be rendered. (The way it's implemented resulted in an empty list being rendered if that attribute was set for a non-hierarchical terms list block.) I've pushed some code to conditionally remove that toggle (and the Note to self: Add testing with flat terms (tags) to Testing Instructions 😅 |
ockham
force-pushed
the
add/categories-list-block-variations-for-taxonomies
branch
from
c791e50 to
1ba1c00
Compare
ockham
force-pushed
the
add/categories-list-block-variations-for-taxonomies
branch
from
1ba1c00 to
b4e20f1
Compare
|
I would prefer the route taken in #26555. A dropdown for the taxonomy would be more consistent with the existing Tag Cloud block (which is more similar to this block in functionality than Post Terms):
I've also seen where moving this sort of thing to variations creates issues for extenders who are creating their own variations. I'd need to test, but I'm wondering how this might play out when a user chooses a theme/plugin variation for this block but then wants to change the taxonomy. Tying the taxonomy setting to a set of variations doesn't feel like the best route. |
I see it the same. This settings feels more suitable for a dropdown, whereas the variation is more for changing the appearance. #33302 asks for 1 universal Terms block, and that's what I think makes most sense. Not variations on the categories block. I would even go as far and say the tag cloud block should be deprecated in favor of a tag cloud variation on this Terms blocks. |
|
I agree with @swissspidy and @justintadlock in preferring a single Terms block with selection of the desired taxonomy. I think that having block variations be based on the data source rather than the appearance is confusing and unexpected. Having a cloud presentation as a variant makes sense to me - that's a change that's more presentation oriented. |
|
Thanks for weighing in, folks! Seems like there’s overwhelming sentiment against using variations. I’m still somewhat concerned about the inconsistency with the Post Terms block. In day-to-day use of the Site Editor, I’d expect people to use those blocks much more alongside each other than e.g. the Tag Cloud block. One other thing to note is that some of the toggles in the blog inspector are only displayed for hierarchical (i.e. category-like) taxonomies (but not for flat — tag-like — ones). This means that if the block is switched from a hierarchical taxonomy to a flat one, those toggles will disappear. I’d wager a guess that this might be slightly less confusing to the user if it’s coupled to transforming the block to a different variation (which might feel like a "bigger" change) than if coupled to a "simple" dropdown that might be perceived as kind of on the same level as the toggles, information architecture-wise. — Anyway, since #26555 is heavily outdated, I’ve spun up a branch (so far without PR) for a version of the block with a block inspector dropdown (and no variations). Here’s two screencasts to compare them:
I’ll also ask designers to weigh in. This is the kind of decision I’d like to run by at least one of them before we commit to either direction :) |
I've only had some preliminary feedback via a private Slack channel so far, but that also favored the dropdown version over the block variations. As a consequence, I've now filed #65272 for that version. Please leave your reviews there when you have a moment! 😊 |
ockham
force-pushed
the
add/categories-list-block-variations-for-taxonomies
branch
from
b4e20f1 to
7175f11
Compare
|
I've merged #65272 (i.e. the version without variations), and I'll thus close this PR. |
ockham
deleted the
add/categories-list-block-variations-for-taxonomies
branch
What?
Create block variations of the Categories List block, one for each existing taxonomy.
Why?
There's been some demand for a "Terms List" block that would render a list of existing taxonomy terms for a given taxonomy -- much like the Categories List block has so far done for categories.
Fixes #51388.
How?
By adding a
taxonomyattribute to the Categories List block, and registering a block variation for each publicly visible taxonomy.The principal choice here was to either use block variations -- or not. In the latter case, we would have needed to add some sort of control (probably a dropdown) to the block inspector. There is already at least one open PR that do just that: #26555.
However, for consistency with the Post Terms block, I decided to go with block variations instead. (In fact, the code that generates the block variations for this block is largely copied from the Post Terms block.) Note that this still gives us a comfortable UI to easily switch between variations (and thus, taxonomies).
What is this not?
A full-fledged "Terms Query" block, as requested by #49094.
However, there's been a few issues and PRs floating around for a while for just a "simple" Terms List block (e.g. #58033, #26555), and I recently found myself working on a project where I could've used a "Terms List" block myself. I concluded that it might make sense to add such a block after all; this doesn't preclude us from adding a more powerful (and complex) Terms Query block later.
Testing Instructions
Add the following code (e.g. to your theme's
functions.php) and use the "Project Types" panel in the block inspector to create a number of "Project Type" terms and assign them to a given post.Code
Then, navigate to the Site Editor and insert the "Project Types List" block into a template of your choosing. Save the template, and verify on the frontend that the block does indeed render a list of project type terms.
Furthermore, make sure to test with built-in taxonomies, both hierarchical (Categories) and flat (Tags). Verify that creating those blocks works both if done from scratch, and if done by transforming an existing instance of the block that was created for a different taxonomy.
Finally, test the toggles in the block inspector. Specifically, change the block's appearance to a dropdown, and verify that it's rendered correctly both in the editor, and on the frontend. Also verify that selecting individual items from the dropdown on the frontend causes WordPress to navigate to the corresponding taxonomy term's archive page.
Screenshots or screencast
TODO
FixUncaught TypeError: t.toString is not a function(at ae.stringifyFunction (page.bundle.js:1:1448)).