Add unregister_taxonomy()

[scribu]

There should be a function that unregisters a certain taxonomy after it has been registered.

Reviewed the patch, I think it should return true on success and false on failure. Can benefit from a better docblock.

Replying to hakre:

Reviewed the patch, I think it should return true on success and false on failure. Can benefit from a better docblock.

Agree. Also, the changes done to the rewrite globals aren't reverted.

return bool, improve doc

if ( empty($wp_taxonomies[$taxonomy]->object_type) ) 
 	222	                        unset($wp_taxonomies[$taxonomy]); 

I dont see the need to remove the taxonomy when it has no object types assoc. with it, I mean, With the functions to add a object type to a taxonomy after its registered, it makes sense that plugins could be removing, and then replacing the object types.

I'm +1 for this, so i'll get it in later sans that block, unless someone has a good arguement against that?

After looking at this closer, I think a single function is going the wrong way.

unregister_taxonomy() should remove the taxonomy all together, and cleanup any query vars which it may've registered

unregister_taxonomy_for_object_type() should remove a object type from a taxonomy.

While we're at it, the Documentation for register_taxonomy() probably needs updating, IT doesnt modify taxonomies, It mearly replaces them..

Moving to 3.1 as this is an enhancement, and no ideal patch is available.

My outlined ideas there may require extra changes to query parsing as well.

What use-cases are there for unregistering taxonomies? Given that they need to be registered every page load..

The trouble was with built-in taxonomies. The best we can do currently is remove_action('init', 'create_builtin_taxonomies', 0); which I guess isn't so bad.

Related: #12629

I added a proposed implementation for unregister_taxonomy_for_object_type on #14482 (Which has been closed as a dupe of this bug). There was an issue with the patch I provided on that bug, so revised patch is attached here.

Replying to dd32:

What use-cases are there for unregistering taxonomies? Given that they need to be registered every page load..

I want to unregister a taxonomy registered by a plugin, without modifying the plugin code.

what's the status of this? would be great to see it in 3.2.

I've been using @leewillis77 implementation as a function and it works flawlessly.

Can someone with more recent Taxonomy experience comment here? I can't think of anything this would break, although if it's being used to remove a taxonomy that a plugin adds, it could cause issues for rewrite rules perhaps?

There are two distinct patches on this bug. One implements unregister_taxonomy(), and mine implements unregister_taxonomy_for_object_type(). The second one is on here because the original bug was closed as a dupe of this, but it seems that it's not, and there doesn't seem to be traction where there are two different things going on (For example disassociating a taxonomy from an object type shouldn't affect rewrite rules AFAIK?).

Should I log that separately? Re-Open the original?

To re-iterate, I am using the patch by leewilliis77 on many live sites and it works without problem and doesn't break anything. We've even included it in this plugin: ​http://wordpress.org/extend/plugins/sld-custom-content-and-taxonomies/ for others to use. I still think this should make it to core.

(For example disassociating a taxonomy from an object type shouldn't affect rewrite rules AFAIK?

That should be fine, I can't think of any case that would break.

Should I log that separately? Re-Open the original?

I wouldn't bother, both of these functions go hand in hand.

Patch updated, and re-rolled against 3.4.1

Agreed. This should definitely be in core.

A unregister_taxonomy() function needs to un-roll quite a bit:

• Remove the query var from the WP class, if one was registered.
• Remove any rewrite tags and permastructs.
• Remove the callback for handling the meta box.

A separate unregister_taxonomy_for_object_type() function needs to remove items from object_type.

An unregister_taxonomy() function should disallow the unregistration of 'post_tag' and 'category' until core does not assume they exist in many, many locations. The same block might also need to be in place in unregister_taxonomy_for_object_type() for the 'post' object type until core no longer breaks under any existing assumptions as well.

'unregister_taxonomy' is unquestionably a hot mess (and what we should probably strive for is an early hook in register_taxonomy that can prevent taxonomy registration, particularly for something like posts, rather than unloading it all after the fact).

Not sure that this applies to unregistering the taxonomy for an object type, however, even for "core" taxonomies against post. I've used this somewhat extensively, even before this patch, and never encountered any serious glitches, and none that would count as a legitimate "bug." There's a certain... "weirdness" to lingering references to Categories and Post Types in the admin ("Right Now", permalink settings, etc) when no objects are actually using them (probably because we ideally want to get to unregister_taxonomy...), but nothing breaks, since any "retrieval" of individual object terms - even core ones - all goes through the abstracted taxonomy functions, and the taxonomy still exists, protecting against any direct taxonomy references (e.g. core category / tag archives).

Any idea where there might be something more subtle lurking that would break?

I should add that one of the peculiar behaviors - core taxonomy and objects or not - when unregistering a taxonomy against an object is that objects previously assigned terms in those taxonomy retain those terms.

So even in ideal circumstances when you register a custom post type and taxonomy, assign some post objects some terms in that taxonomy, than unregister the taxonomy against the post type object (but don't remove the taxonomy), queries against those terms still return posts assigned terms against that taxonomy (without any GUI to unassign them).

If we care about this (pretty questionable path), we'd need to modify queries against taxonomy terms to limit its results to post types assigned those taxonomies... I wonder if we should do this anyways...

In reply to:
"The same block might also need to be in place in unregister_taxonomy_for_object_type() for the 'post' object type until core no longer breaks under any existing assumptions as well."

Just to echo Jake's comments for what it's worth - I've been using the patch for unregister_taxonomy_for_object_type() on several sites, and haven't seen anything "break". I haven't particularly noticed any weirdness either. Happy to test specific scenarios if you have something in mind?

Replying to jakemgold:

So even in ideal circumstances when you register a custom post type and taxonomy, assign some post objects some terms in that taxonomy, than unregister the taxonomy against the post type object (but don't remove the taxonomy), queries against those terms still return posts assigned terms against that taxonomy (without any GUI to unassign them).

Related: #21290

Replying to leewillis77:

I've been using the patch for unregister_taxonomy_for_object_type() on several sites, and haven't seen anything "break". I haven't particularly noticed any weirdness either. Happy to test specific scenarios if you have something in mind?

Related: #19590

Replying to SergeyBiryukov:

Replying to leewillis77:

I've been using the patch for unregister_taxonomy_for_object_type() on several sites, and haven't seen anything "break". I haven't particularly noticed any weirdness either. Happy to test specific scenarios if you have something in mind?

Related: #19590

#19590 relates to unregistering taxonomies, and would be an issue for unregister_taxonomy(), but shouldn't affect the implementation of unregister_taxonomy_for_object_type(). Indeed, having unregister_taxonomy_for_object_type() available provides a way for people to "hide" the taxonomy without having to deal with any issues in core that would be exposed by removing the taxonomy entirely.