-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Categories List block: Add dropdown for taxonomies #65272
Conversation
Size Change: +1.75 kB (+0.1%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
@@ -92,8 +102,8 @@ function build_dropdown_script_block_core_categories( $dropdown_id ) { | |||
( function() { | |||
var dropdown = document.getElementById( '<?php echo esc_js( $dropdown_id ); ?>' ); | |||
function onCatChange() { | |||
if ( dropdown.options[ dropdown.selectedIndex ].value > 0 ) { | |||
location.href = "<?php echo esc_url( home_url() ); ?>/?cat=" + dropdown.options[ dropdown.selectedIndex ].value; | |||
if ( dropdown.options[ dropdown.selectedIndex ].value !== -1 ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an opportunity to refactor this block to use Interactivity API. @DAreRodz and @michalczaplinski, was it on the radar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me and addresses long-standing issues. I left some minor feedback about the fallback message presented on the frontend when no terms are available for the specific type. Should there be a customized message printed instead of "No categories". The next step would be to digest feedback from #64805 and see how it can be further improved to remove the ambiguity between core/categories
and core/post-terms
.
Ah yeah, that's a bit unfortunate 😕 I hope that's not going to pose a UX issue, but that's something we can maybe get some feedback on during the next couple of weeks and fix accordingly. I think the suggestion was to merge the Tag cloud block (
Ah, good spot! Under the hood, we're using We should also change the message in the editor, as it's kind of misleading (and... wrong? 😅 ) |
Looping in some design and product folks (👋 @jasmussen and @annezazu) for their feedback on the following discovery that @gziolo made:
Note that the "Categories" block seen in the inserter in the above screenshot is There are two known approaches to mitigate this problem, but they each have their own drawbacks (discussed in the respective PRs)
|
$show_label = empty( $attributes['showLabel'] ) ? ' screen-reader-text' : ''; | ||
$default_label = $taxonomy->label; | ||
$label_text = ! empty( $attributes['label'] ) ? $attributes['label'] : $default_label; | ||
$wrapper_markup = '<div %1$s><label class="wp-block-categories__label' . $show_label . '" for="' . esc_attr( $id ) . '">' . $label_text . '</label>%2$s</div>'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment from @peterwilsoncc WordPress/wordpress-develop#7226 (comment)
Escaping label text
It was a preexisting issue, though.
What?
Allow using the Categories List block for other taxonomies.
Alternative to #64805.
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 #33302.
Closes #26555 (which is quite outdated by now).
How?
By adding a
taxonomy
attribute to the Categories List block, and a dropdown to the block inspector to set that attribute.The principal choice here was to either use block variations -- or not. I originally filed a PR for the former case (#64805), but feedback indicated that folks preferred the latter.
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 "Terms List" block into a template of your choosing, and select "Project Type" from the Taxonomy dropdown in the block inspector. 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).
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