Gutenberg: 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. https://github.com/WordPress/gutenberg/pull/11802#issue-230400013

[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

[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;