Post Hierarchical Terms Block #24091
Conversation
Copons
added
[Feature] Full Site Editing
[Block] Post Terms
Copons
requested review from
ajitbohra,
nerrad,
ntwb,
Soean,
spacedmonkey,
talldan and
TimothyBJacobs
as code owners
|
Size Change: +601 B (0%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
|
Should we limit this to Posts (to exclude e.g. pages?) See #24082 for some relevant discussion. |
|
I would think that a Post Categories and Page Categories would just be the same block exposed as two different block variations using the block variations API. |
That's not what I meant, apologies for being unclear. We should be able to use the same block for both posts and pages -- it's just that AFAIK pages normally don't have categories, which is why I was suggesting to hide the block from the inserter when editing a page. See #24082 where we're discussing essentially the same question for tags. |
|
@ockham By passing the context's We could improve the messaging, by checking if the post type actually supports the taxonomy, but in my opinion it would go beyond the scope of this PR (which, yes, I haven't specified it, but it's in the context of having styling parity between FSE blocks and normal blocks, see #21087). |
That's fair enough, but it'd be nice to have the Categories and Tags blocks somewhat consistent in their messaging and behavior (since they're so similar in nature, and both currently under development) 😬 @jeyip has asked for design input there. Anyway, I don't mean to block this. This is probably good enough for a first iteration -- all I'm saying is we should keep close track to avoid the Categories and Tags blocks to diverge too much in terms of UX. |
Copons
force-pushed
the
add/post-categories-block
branch
from
6418c3b
to
0714e45
Compare
|
There was already a similar PR started here #22471, but it didn't receive updates since May. Should we close that one out with a note? There were also some possibly relevant discussions there. |
|
What if we try to help @carolinan and update her PR to rename the block "Post Hierarchical Taxonomy" or something like that and add a variation for categories? Potentially we could hide the default block (without any variation) from the inserter. |
My bad, I should have checked for duplicates before opening this. 🤦
Cool! and it makes lots of sense!
I'm totally ok with keeping either! |
|
There's already a way for plugins to register new block variations: |
|
This is looking good and is decent for an initial merge I think. I added the design label to get some thoughts on the design and on potential follow-ups to add customization options. |
Nice! |
Copons
force-pushed
the
add/post-categories-block
branch
from
3f9845b
to
7005a2a
Compare
|
Removed the now unnecessary CSS class from the PHP render, as suggested by @Addison-Stavlo. Also finally took the time to test this with custom taxonomies, and I'd dare say it works just fine. 😄
I've built a super simple plugin to test this, in case you want to try it yourselves. Code hidden below for clarity
<?php
/**
* Plugin Name: Test Hierarchical Taxonomy
*/
function copons_register_hierarchical_taxonomy() {
register_taxonomy( 'copons_hierarchical_taxonomy', [ 'post' ], [
'labels' => [
'name' => 'Test Hierarchical Terms',
'singular_name' => 'Test Hierarchical Term',
'search_items' => 'Search',
'all_items' => 'All',
'parent_item' => 'Parent',
'parent_item_colon' => 'Parent:',
'edit_item' => 'Edit',
'update_item' => 'Update',
'add_new_item' => 'Add New',
'new_item_name' => 'Name',
'menu_name' => 'Test Hierarchical Terms',
],
'rewrite' => [ 'slug' => 'copons-test-hierarchical-taxonomy' ],
'public' => true,
'show_ui' => true,
'show_admin_column' => true,
'hierarchical' => true,
'show_in_rest' => true,
] );
}
add_action( 'init', 'copons_register_hierarchical_taxonomy' );
function copons_enqueue_hierarchical_taxonomy_block_variation() {
wp_enqueue_script(
'copons-test-hierarchical-taxonomy',
plugins_url( 'block-variation.js', __FILE__ ),
[ 'wp-blocks' ]
);
}
add_action( 'enqueue_block_editor_assets', 'copons_enqueue_hierarchical_taxonomy_block_variation' );
( function( blocks ) {
blocks.registerBlockVariation( 'core/post-hierarchical-terms', {
name: 'copons_hierarchical_taxonomy',
title: 'Test Hierarchical Terms',
icon: 'category',
attributes: { term: 'copons_hierarchical_taxonomy' },
} );
} )( window.wp.blocks );(Note: #24547 is my proposed fix for the variations labels misalignment) |
@youknowriad I'm not sure how to do it. 🤔 |
Did you try adding the "support" with the flag set to true on the variation? I'm actually not sure it works but it might be something we explore later if it doesn't. |
Yup, I've tried that and it doesn't seem to work. |
|
Ok, let's keep this visible for now and figure it out later. |
Copons
force-pushed
the
add/post-categories-block
branch
from
7005a2a
to
11a42f7
Compare
|
This is great, thanks! It's a great way to test variations as well — let's make sure to follow up on being able to hide the source block and only show variations. We might also need to expand the API to support something like "hidden" if it makes sense. |
Description
Add a new Post Hierarchical Terms Block block with a single variation that displays the current post's categories, if any, in a list of links separated by a vertical bar.
The block already supports: text, background, link colors; font size, line height, and text alignment.
Note: the text color is applied to the vertical bar separator, which only appears when the post has at least 2 categories.
As a follow up, we could add a way to customize the separator string
How has this been tested?
Tested in Post, Page, and Site Editor, on Chrome 83 on macOS 10.15.5.
Screenshots
(The variation label misaligned issue is unrelated to this PR; taking care of it in #24547)
Variation loaded and customized.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: