[Block Library - Post Terms]: Add dynamic variations of custom taxonomies #39837
Conversation
ntsekouras
added
[Type] Enhancement
ntsekouras
requested review from
Mamaduka,
aristath,
gziolo,
jasmussen,
paaljoachim and
carolinan
ntsekouras
force-pushed
the
add/post-terms-dynamic-variations
branch
from
84cc9ac
to
d768487
Compare
|
Size Change: +3 B (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
|
This is really helpful! Thank you @ntsekouras I am using a dev site where I am updating various tutorials that also use the custom post type "Tutorial". Finding post terms. Or I could also have written Post categories or Post tags. Post Tutorial Categories:
Post Tutorial Tags:
Adding some text. (backend) Frontend: Backend shows the layout just a little different compared to the frontend. |
|
This works great, Nik. The in_array( 'post', $taxonomy->object_type, true )It would be nice if we could limit variations based on the post-type context in the future. |
For me the --cc @mtias @jasmussen for any thoughts about the names. |
|
I'd remove the prefix and honor the label name. For posts, "tags" and "categories" would be easier to read. |
Without any prefix we will end up with duplicate block names. For example the |
Alternatively I guess we could update the other blocks to show |
|
Should we get this into WordPress 6.0? |
|
@adamziel @gziolo @youknowriad |
Could another option would be to prohibit placing the Categories block inside a Query? If we're going to include the post type in the block name we should probably update the placeholder content as well, IE this should read 'No product tags':
That said, it would be interesting to eliminate all the prefixes. I've said this before but "Post Title" is kind of odd to see when working with a Product query, or a Page query for that matter. Like Titles, concepts such as categories and tags are universal, so I'm not sure they ever need prefixes? If we used generic block names they could behave agnostically. IE the Categories and Tags blocks could theoretically adapt based on the selected post type. Whereas with the current implementation, if you swapped the Query to display |
Yes, I just ran into something like this recently, such as inserting a Post Title on a Page template, or looking for "Archive Title" in all blocks when in fact the one I should've picked was "Query Title". There are probably some cases were we can't unify all these; indeed there's that curious case on the archive template where you want to show both the title of the archive, and individual item titles inside a query loop. Finally there may be a benefit of being able to style these individually in the Global Styles → Blocks panel, and give them different fonts, sizes, treatments, etc. So those are some of the thoughts to balance, but definitely agree that there's some simplification to have here. |
In that case I think 'Archive title' is okay because it doesn't lean in to any particular post type. It will behave consistently placed in either For a while I've thought that a good rule of thumb could be to look at the underlying function name for guidance around these non-custom blocks. IE |
I think it can create confusion because we will end up with different blocks with the same name. Also outside a Query Loop block we will have these different blocks exposed in the inserter - think of a single post content or template. |
|
Good point. In that case I like your idea above:
|
ntsekouras
force-pushed
the
add/post-terms-dynamic-variations
branch
from
d768487
to
f245e83
Compare
|
By rebasing I have lost (temporally) the change of icon introduced here: #40096. I'll probably need to add a filter for assigning different icons. |
|
I pushed an update that changes:
|
|
Maybe for WP 6.1, we should propose new arguments for taxonomy registration:
|
ntsekouras
force-pushed
the
add/post-terms-dynamic-variations
branch
from
62d741c
to
a142c17
Compare
|
Should post types also do this automatically as Query variations? (i.e. a Films query block if I have a Films custom post type, etc) |
Yes, we can do this in a follow up. |
mburridge
added
the
Needs Dev Note
|
Added the Needs Dev Note label in case a dev note is needed for 6.1 release. |
I'm not sure if one is needed.. This PR just creates some dynamic variations of Post Terms block and are available in the editor for users.. |
mburridge
removed
the
Needs Dev Note
|
Okay, thanks @ntsekouras. I've removed the label. |
|
Could we reconsider a prefix for the Post Terms block, perhaps something like "Terms:"? I think that changing the original "Categories" block to "Categories List" is fine, but I'm concerned about giving its name to another block (at least in English). Selecting a block named "Categories" does something very different now, and that can surprise people who like to add categories lists in their sites. Confusion would be less common than I originally thought because the Post Terms block is not available in the Widget editors, yet it can happen in the Site and Post editors. And maybe this discussion belongs in a new issue. |
|
I believe this issue would be interesting to know about: |
What?
Resolves: #32924
This PR defines
Post Termsblock variations dynamically and registers them server side, available since 5.8.Why?
Now we can display a list of all eligible taxonomies(built ins and custom ones).
Testing Instructions
post {your taxonomy name}.Alternatively just install a plugin with custom taxonomies already like
WooCommerceand test with the product categories and product tags.Screenshots or screencast
Screen.Recording.2022-03-29.at.10.38.05.AM.mov