It is not you, it is WordPress. I’ve just spent almost 2 hrs picking my hair debugging the same issue.
Turns out meta_box_cb
is only taken into account if the custom post type does NOT use Gutenberg editor – in your case if in the register_post_type()
call the 'supports'
array would not include 'editor'
.
Once Gutenberg is loaded, the metabox-es are not rendered by the meta_box_cb
, instead they are rendered by some React components whereas the contents and the config is loaded from the REST API. So that is two entirely different story, and they behave different.
It is rather disturbing that a standard WP PHP API function (register_taxonomy()
) produces two entirely different behaviour depending on a parameter somewhere in another call, but this is the case as of v5.6 apparently.
So, if you want to use custom rendering for your metabox for a post that uses the Gutenberg editor, you have to actually build a custom metabox for yourself and register it to your post type and set show_ui
to false
in the register_taxonomy()
parameters, to disable the default UI.
Alternatively you can remove the editor
support from the custom post type, and maybe use an other custom metabox based on the wp_editor
rich text editor, if you are fine with using regular rich text instead of the block editor.
Or you may disable Gutenberg for the given post type, and let it fall back to the Classic editor.
At least there is a bug about it: https://github.com/WordPress/gutenberg/issues/13816