Make WordPress Core

Opened 12 years ago

Closed 8 years ago

#12629 closed feature request (duplicate)

function to remove custom taxonomies and all their terms

Reported by: sillybean Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Taxonomy Keywords:
Focuses: Cc:


I think there should be an easy way for plugins that create custom taxonomies to clean up after themselves on deactivation. I went over taxonomy.php pretty thoroughly and didn't find anything that does this directly.

The function below removes the custom taxonomies and terms from the various tables while leaving the built-in taxonomies alone.

assuming taxonomies for actor, director, and genre have been created on plugin activation...

function remove_taxonomy($taxonomy) {
	if (!$taxonomy->_builtin) {
		global $wp_taxonomies;
		$terms = get_terms($taxonomy); 
		foreach ($terms as $term) {
			wp_delete_term( $term->term_id, $taxonomy );

function deactivate_custom_taxes() {
	remove_taxonomy('post_tag');  // this will fail silently
	// do we need to flush the rewrite rules? 

register_deactivation_hook( __FILE__, 'deactivate_custom_taxes' );

If you like the idea, the remove_taxonomy() function could go into taxonomy.php, and then we'd document the deactivation procedure.

Change History (12)

#1 @nacin
12 years ago

Data should generally be removed on an uninstall hook, not deactivation.

#2 @sillybean
12 years ago

  • Cc steph@… added

#3 follow-up: @sillybean
12 years ago

FWIW, I've never actually seen a plugin use an uninstall hook.

#4 in reply to: ↑ 3 @scribu
12 years ago

Related: #11058

Replying to sillybean:

FWIW, I've never actually seen a plugin use an uninstall hook.

I use it all the time in my plugins.

#5 @sillybean
12 years ago

Oh, it makes perfect sense, and it's certainly better to nuke a lot of data on uninstall rather than deactivation, especially if a user is just being conscientious about upgrading. I'm just adding uninstall hooks to my mental list of plugin-related docs that need improvement. (It's a long one.)

#6 @nacin
12 years ago

  • Milestone changed from Unassigned to 3.1

We still don't have unregister_taxonomy() (#11058) and unregister_taxonomy_for_object_type(), so I'm thinking those would need to come before this one. Setting to 3.1.

#7 @filosofo
12 years ago

  • Owner filosofo deleted
  • Status changed from new to assigned

#8 @kevinB
11 years ago

  • Cc kevinB added

#9 @F J Kaiser
11 years ago

  • Cc 24-7@… added


#10 @nacin
11 years ago

  • Milestone changed from Awaiting Triage to Future Release

#12 @wonderboymusic
8 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

Duplicate of #11058.

Note: See TracTickets for help on using tickets.