Open rodrigoantonanasantex opened 5 years ago
The meta_box_cb
argument is ignore by Gutenberg ( for every post type ).
This is due to the fact that this argument don't show up in the REST API.
I found a small fix to hide the metabox when meta_box_cb
is set to false
:
add_filter( 'rest_prepare_taxonomy', function( $response, $taxonomy, $request ){
$context = ! empty( $request['context'] ) ? $request['context'] : 'view';
// Context is edit in the editor
if( $context === 'edit' && $taxonomy->meta_box_cb === false ){
$data_response = $response->get_data();
$data_response['visibility']['show_ui'] = false;
$response->set_data( $data_response );
}
return $response;
}, 10, 3 );
if you want to have your own metabox you should have a look a the editor.PostTaxonomyType filter
@ArnaudBan thanks for the response, I will try it.
Hello! Is there any plan to make the 'meta_box_cb' parameter work again in register_taxonomy even if the post type is a custom one?
I tried to check the Custom Taxonomy Selector as specified by @ArnaudBan but the way to use it is not so obvious (for me at least) after reading the documentation. Is there maybe a better exemple?
Thx!
This is also a problem if you want to change which UI the terms are shown in, despite it's hierarchical nature. Core conflates hierarchical taxonomies with being a fixed list of terms that should be selected with checkboxes, when in reality the two aren't necessarily connected, they just happen to be for tags and categories.
https://core.trac.wordpress.org/ticket/27249 https://core.trac.wordpress.org/ticket/14877
It's possible to have a non-hierarchical taxonomy where the checkbox UI is more appropriate than the text input UI. For example, the tracks in a conference schedule. The track corresponds to a physical room, and in most cases it doesn't really make sense to have a hierarchy.
In that use case, I'd register the taxonomy like this:
'hierarchical' => false,
'meta_box_cb' => 'post_categories_meta_box',
...so that I don't have a hierarchy, but still get the checkbox UI. That works fine in the Classic Editor, but Gutenberg still displays the text input interface.
...in the previous example, I think post_categories_meta_box
should probably be mapped automatically to HierarchicalTermSelector
, rather than rendering that panel in PHP using post_categories_meta_box
. Same for post_tags_meta_box
/ FlagTermSelector
.
Related: #17476
'meta_box_cb' does not work when registering custom post type with custom taxonomy. Whether it is set to false or callable function it does exactly nothing, neither on quick edit in admin menu, nor in Gutenberg editor UI. No change in meta box.
In my example, I set 'meta_box_cb' to 'post_categories_meta_box', but metabox remains text editor for non-hierarchical items.
// register taxonomy register_taxonomy( 'Stories', 'story_map_posts', array( 'label' => 'Story', 'description' => 'Taxonomy separates different stories', 'public' => true, 'show_in_rest' => true, 'hierarchical' => false, 'meta_box_cb' => 'post_categories_meta_box', 'show_admin_column' => true ) ); } add_action('init', 'story_map_custom_post_type');
Try adding this line of code:
'show_in_rest' => true,
Here it solved just adding this line of code
Try adding this line of code:
this doesn't seem to work for non-hierarchical taxonomies
I'd register the taxonomy like this:
'hierarchical' => false, 'meta_box_cb' => 'post_categories_meta_box',
...so that I don't have a hierarchy, but still get the checkbox UI. That works fine in the Classic Editor, but Gutenberg still displays the text input interface.
same here. I'd love to separate the display from the logic - to me it makes far more sense to use checkboxes for a limited selection list - some awesome stuff here https://github.com/WordPress/gutenberg/tree/trunk/packages/editor/src/components/post-taxonomies#custom-taxonomy-selector
seems the easiest way to get checkboxes no matter what editor is being used is still 'hierarchical' => true
the related tickets #6912 #17476 have had some progress (: any timelines on resolving this? thanks 😃
Enqueuing a script in your admin with
wp.data.dispatch( 'core/edit-post' ).removeEditorPanel( 'taxonomy-panel-[your taxonomy key]' );
works for hiding the "metabox".
Is there any reason why @ArnaudBan 's solution isn't implemented yet, even after 4 years? Are there any negative/unexpected effects using that fix?
I found that comment because I'm using ACF and I could not hide custom taxonomy meta boxes in the sidebar when I was using Gutenberg editor. However this filter fixed the problem and now I can hide meta boxes in Gutenberg with the "No Meta Box" settings in ACF, and everything seems to be working well.
Use 'show_in_rest' => false
and metabox is gone.
Ran into this. $reasonsWhyWordPressSucks++
This works with categories. Add in theme's functions.php: add_filter('rest_category_query', function ($prepared_args, $request) { if (strpos($request->get_route(), '/wp/v2/categories') === 0) { if (isset($prepared_args['number']) && $prepared_args['number'] === 100) { $prepared_args['number'] = 100000; } } return $prepared_args; }, 10, 2);
Describe the bug Register a taxonomy for a
post
with a custom panel UI doesn't work with Gutenberg editor but yes with the classic editor. Also, it works with another custom post type.To Reproduce Steps to reproduce the behavior:
Register Taxonomy:
Go to the edit/create post page: The panel UI is not properly:![image](https://user-images.githubusercontent.com/44847008/52574925-12af5600-2dfc-11e9-8e78-bc7a1bc86226.png)
If I create a new post_type and go to the edit/create the new custom post type, the panel is showing properly:![image](https://user-images.githubusercontent.com/44847008/52575135-720d6600-2dfc-11e9-84c9-033f7f25f85b.png)
Desktop (please complete the following information):