Custom Taxonomy: Show in REST, Hide default Gutenberg Panel

[spwarner]

I’ve created a custom taxonomy for my custom post type, but I have built a custom interface for assigning the tax (a drop-down as I want only max 1 term assigned) as part of a metabox for the CPT. I want to show the taxonomy in the Admin UI so it’s easy to add/edit terms, but I want to hide the default chooser panel for the tax on the custom post type. In the classic editor, setting ‘meta_box_cb’ => false does the trick, is there any similar way to do this in Gutenberg? I want to show the taxonomy in REST so I can build my custom selector functionality so I set ‘show_in_rest’ => true, but then I get the default chooser in Gutenberg too (in its own panel under Document in the Inspector). How can I remove this - it would be good to have a filter or attribute that can be set to remove the default tax chooser.

[danielbachhuber]

Hi @spwarner,

You can use show_ui=false to disable the Gutenberg UI, see https://github.com/WordPress/gutenberg/blob/master/editor/components/post-taxonomies/index.js#L21

[spwarner]

Yes, but then it removes the tax management interface as well (which I want to keep). Is there any way to keep the admin interface to manage the tax, but hide the default tax chooser in Gutenberg? Here's the screenshot of the admin interface that I want to keep, but gets removed with show_ui=false:

[danielbachhuber]

Is there any way to keep the admin interface to manage the tax, but hide the default tax chooser in Gutenberg?

I don't have a good answer to this at the moment. We'll work something out in the near future. I've filed this against the Merge Proposal: Back Compat milestone so it has visibility.

[spwarner]

That'll do for now, thanks! I'd just like to have this functionality when 5.0 ships.

[Ipstenu]

It’s not uncommon for people to use taxonomies to extend custom meta boxes in cmb2 or acf. In doing so, they intend to limit the use of the taxonomy (such as make it a drop down to prevent people from adding to it in situ). While much of this will be adapted to Gutenberg blocks and templates, as it should, it will still be important to hide them from post content.

[jtsternberg]

FYI, in CMB2, we use remove_meta_box for this: https://github.com/CMB2/CMB2/blob/trunk/includes/CMB2_hookup.php#L519-L534

Not sure if there's a way to listen in to that de-registration and obey it in gutenberg (or if it'll require some other taxonomy config parameter).

[danielbachhuber]

@spwarner @jtsternberg Here's a workaround we found for a project:

/**
 * Disable display of Gutenberg Post Setting UI for a specific
 * taxonomy. While this isn't the official API for this need,
 * it works for now because only Gutenberg is dependent on the
 * REST API response.
 */
add_filter( 'rest_prepare_taxonomy', function( $response, $taxonomy ){
	if ( 'category' === $taxonomy->name ) {
		$response->data['visibility']['show_ui'] = false;
	}
	return $response;
}, 10, 2 );

[spwarner]

Thanks - that works for now. Keep us posted if an official method is developed for this.

[danielbachhuber]

Given the timeline for shipping 5.0, it's unlikely this particular enhancement will make it for this release. Reassigning to WP 5.1 Onwards to pick up in the future.

[mrwweb]

It appears that there is an existing JS solution for this. That worked for me. #11802 (comment)

[helgatheviking]

I've been able (with some big help) to replace an existing gutenberg taxonomy panel with an adapted version (swapping checkboxes for radio buttons). For anyone that may find it a useful starting reference: https://github.com/helgatheviking/Radio-Buttons-for-Taxonomies/blob/master/js/src/index.js#L24

[timnolte]

I am still hitting this issue, hopefully one of these custom code options will work. What is the priority on there being an officially handled way of making sure that Gutenberg follows the previous logic?

[ian-pvd]

First, thanks to Daniel for the work around posted Oct 2018. It's doing what I need it to for right now.

I did want to add to the concerns over losing remove_meta_box however, which also had the ability to specify post type. The current work around looks to remove the taxonomy component panel from all post types, which means I can't use it to say... have a "Difficulty" tags taxonomy using a custom single-select meta box on a "Trails" post type, but still use the WP default tags type-ahead multi-select for "Difficulty" on a "Parks" post type.
It looks like I would also have to implement two separate methods for removing taxonomy meta boxes if I encountered a situation where one CPT was using Gutenberg and another was not.

It is a relief though that I am still able to do this somehow in PHP, where I am defining my CPTs, Taxonomies and custom Metabox configs, and don't need to rely on a separate JS solution.

[tomjn]

For reference, this call will remove a panel for a taxonomy named session in the browser console:

wp.data.dispatch( 'core/edit-post' ).removeEditorPanel( 'taxonomy-panel-session' );

Likewise with wp.data.dispatch('core/edit-post') you can also use toggleEditorPanelEnabled to open and close panels. You might also use useSelect and useDispatch hooks in a component to do this:

const hasTaxonomyPanel = useSelect( select => undefined !== select( 'core/edit-post' ).getPreferences().panels['taxonomy-panel-session'], [] );
const { removeEditorPanel } = useDispatch( 'core/edit-post' );

if ( hasTaxonomyPanel ) {
	removeEditorPanel( 'taxonomy-panel-session' );
}

You can discover the names of panels using this:

wp.data.select( 'core/edit-post' ).getPreferences().panels;

[paaljoachim]

What is still needed in this issue?

[tomjn]

@paaljoachim an official way to disable the Gutenberg panel for a taxonomy that doesn't involve hiding it from the REST API.

E.g. if I wanted to add a custom panel that replaces the one the block editor adds. There's aa way to do this with the classic editor, but not in the block editor

[paaljoachim]

I will ping
@youknowriad @gziolo
As they might have some thoughts on this issue.

[tomjn]

A taxonomy registered similar to this:

add_action( 'init', function() {
        register_taxonomy( 'custom_ui', ['post'], [ 'show_ui' => true, 'show_in_rest' => true, 'label' => 'customtax', 'meta_box_cb' => 'custom_tax_ui' ] );
} );
function custom_tax_ui( \WP_Post $post, array $box ) {
        echo "hello world"; 
} 

Will replace the metabox in the classic editor with hello world. However, in the block editor, an unwanted default tags taxonomy panel appears.

A good example of this in the wild is the Publishpress Authors plugin, which registers a metabox with a custom UI, as well as a default panel that Gutenberg adds, resulting in duplicate panels

[paaljoachim]

Somewhat associated issue:
#7960

[TrovenTrip]

@spwarner @jtsternberg Here's a workaround we found for a project:

/**
 * Disable display of Gutenberg Post Setting UI for a specific
 * taxonomy. While this isn't the official API for this need,
 * it works for now because only Gutenberg is dependent on the
 * REST API response.
 */
add_filter( 'rest_prepare_taxonomy', function( $response, $taxonomy ){
	if ( 'category' === $taxonomy->name ) {
		$response->data['visibility']['show_ui'] = false;
	}
	return $response;
}, 10, 2 );

Does this work for other metadata options and custom taxonomies? The 'category' works great for me but I can't get any of the other options or my custom taxonomies to work. Thanks

[paulschreiber]

I ran in to this problem as well. Can we get this in to 5.8? Three years is a long time.

[paulschreiber]

Related: #13816

[eros23]

I ran in to this problem as well. Can we get this in to 5.8? Three years is a long time.

a lot of people that us this problem

[2ndkauboy]

I've just came across the same issue and found a way to achieve this. I've set the assign_terms capability to do_not_allow:

register_taxonomy(
	'custom_taxonomy',
	[ 'custom_post_type' ],
	[
		// ...
		'show_ui'            => true,
		// ...
		'capabilities'       => [
			'manage_terms' => 'edit_posts',
			'edit_terms'   => 'edit_posts',
			'delete_terms' => 'edit_posts',
			'assign_terms' => 'do_not_allow', // Hides the sidebar plugin to assign/add terms.
		],
		'show_in_rest'       => true,
		// ...
	]
);

It had the following effect:

• You can manage (add/update/delete) terms for the CT in the menu entry at the CPT
• You can assign terms to a post programmatically (e.g. using wp_set_post_terms())
• You cannot assign terms using "quick edit" or "bulk actions"
• You cannot assign terms in the block editor sidebar (the panel is hidden)

[urukai]

• You cannot assign terms in the block editor sidebar (the panel is hidden)

In this case you are also not able to assign terms to a post in a custom block editor sidebar panel since you are not allowed to do it, eg with editPost()