create metaboxes for hierarchical taxonomies

[nicomollet]

edit by dd32:

The posts page only contains metaboxes for flat taxonomiese (non-hierarchical ones). It should also support custom taxonomies which are parent-child(hierarchical).

---

original desc from nicomollet:

WP2.8 new taxonomy features make us create new taxonomies. Example in ​http://justintadlock.com/archives/2009/05/06/custom-taxonomies-in-wordpress-28

You can make new taxonomy tags "Animals" with this simple line of code :

register_taxonomy( 'animals', 'post', array( 'hierarchical' => false, 'label' => 'Animals' ) );

But it seems possible to create new taxonomy categories, like "Rating" (G, PG, PG-13, R, NC-17) with :

register_taxonomy( 'rating', 'post', array('hierarchical' => true,  'label' => 'Rating') );

This last line of code does nothing at all. It is supposed to work ? Maybe it needs to be implemented.
Thanx

[nicomollet]

I may precise that the last line of code

register_taxonomy( 'rating', 'post', array('hierarchical' => true,  'label' => 'Rating') );

does not create "automatic meta boxes" and "manage screens" like "hierarchical => false" does.

[Denis-de-Bernardy]

I suspect it's by design - the hierarchical attribute would imply that the rating can't be added as a tag.

[ryan]

This is by design. Support for categories will be added later.

[harrym]

Any chance of this making it into 2.9?

[dd32]

Any chance of this making it into 2.9?

I'm working on something like that, but no guarantee's if it'll make it into any version.. Is anyone else even attempting that?

[prettyboymp]

I've been trying to get to creating a patch for this all week but haven't been able to get to it. Hopefully I'll get something together over the weekend. I don't see why the categorie's meta box couldn't be altered to handle custom taxonomies. Once the basic meta_box handling is done. We'll probably need to alter the category management pages to work with custom hierarchical taxonomies as well.

[prettyboymp]

This patch took me down quite a rabbit hole. Its going to need a lot of testing since the changes were pretty wide spread. One issue I do know about that I wanted some feedback on is that there is no default term for custom taxonomies built in by default. This causes issues if the user wants to uncheck all terms since the $_POSTinput_tags?[$taxonomy] is empty.

[prettyboymp]

removed alert left from debugging

[prettyboymp]

Any chance we can have this added by 2.9?

[prettyboymp]

I hope I'm not stepping out of bounds by setting a new milestone, but I'd really like to see this make it into 2.9.

[pampfelimetten]

+1 for 2.9! Could be quite handy.

[harrym]

@ryan -- Any particular reason this isn't going to make it into 2.9? Is there anything a willing volunteer could do to help?

[strider72]

Right off the top of my head (and first things I saw in the patch) is check your spelling. The function name is misspelled.

"hierarchical" not "heirarichal"

[prettyboymp]

Thanks strider72. Not the easiest word to spell, or say for that matter. Fixed patch submitted.

[markjaquith]

Replying to harrym:

@ryan -- Any particular reason this isn't going to make it into 2.9? Is there anything a willing volunteer could do to help?

We were in beta by then, and are in beta 2 now. Unfortunately, it's just too late. But I really like this idea, so don't give up — let's work on getting this finished and in, early in the 3.0 cycle. We should be branching soon.

As part of this, we should consider redoing our default post categories widget to use this code.

[harrym]

That sounds like a plan -- though this patch will need some more work now as it's quite old and merging it into the current trunk is a big job (we gave up).

(Unless, of course prettyboymp has already done that in the fixed version?)

[prettyboymp]

Replying to harrym:

That sounds like a plan -- though this patch will need some more work now as it's quite old and merging it into the current trunk is a big job (we gave up).

(Unless, of course prettyboymp has already done that in the fixed version?)

The latest patch is from HEAD as of this morning.

@markjaquith -- I'd like to suggest that we go ahead and make generic handlers (functions/classes) for all of the ones that are currently category taxonomy specific and just make the category specific functions use those. This would also include wp-admin/categories.php and the Walker_Category. I have no problem adding additional patches (probably under a new ticket) for these as long as it fits the roadmap.

[lloydbudd]

Testing current patch on WordPress.com

[dd32]

Closed Ticket #11522 (Add admin support for hierachical taxonomies) as Duplicate of this.

A comment made in the other ticket:

sirzooro: +1 for this. Also remember about front-end category widget - update it to support custom taxonomies too.

[ryan]

(In [12509]) Add hierarchical taxonomy handling to wp_set_post_terms(). Props prettyboymp. see #10122

[scribu]

Related: #11576

[hakre]

Reviewed: Patch does not apply clean any longer.

For testing, please provide some details how to test. Is there need to manually register a special taxonomy to test this?

[dd32]

I think we need to get this into 3.0, To go along side the custom post types. Should also expose the management pages for it in the Menu.

[dd32]

removed the early tag.. adding it back

[dd32]

See Also #11838 for adding the Taxonomy menu and edit screen.

[prettyboymp]

latest patch

[prettyboymp]

simple plugin to test

[prettyboymp]

I've added a new patch that should apply cleanly (for now) and also created a simple plugin to use to test a custom hierarchical taxonomy with.

[prettyboymp]

Fixed typo causing checked parent categories to return unchecked after addition of sub-category

[prettyboymp]

changed taxonomy registration to fire on init instead of plugins_loaded after some users had issues with rewrite.php not being loaded yet

[prettyboymp]

removed stray 'aaa' text in meta-boxes.php

[rickybuchanan]

Props to prettyboymp, this is sweet.

[ryan]

[12798]

[dd32]

(In [12966]) update wp_popular_terms_checklist() to handle custom taxonomies. See #10122

[scribu]

Related: #12911

[scribu]

I found a slight problem.

Steps to reproduce:

1. Register a hierarchical taxonomy

2. Create a post and assign one or more terms in that taxonomy

3. Uncheck all terms in the taxonomy metabox and save post

Result:

The terms remain checked.

[scribu]

allow clearing all terms

[scribu]

wp_insert_post.diff makes wp_insert_post() sets terms for all taxonomies, not just for those that have terms.

[prettyboymp]

Replying to scribu:

wp_insert_post.diff makes wp_insert_post() sets terms for all taxonomies, not just for those that have terms.

I don't know that that will work since it isn't guaranteed that all taxonomies will be on the edit post screen. I don't see it in my submitted patches, but I thought I had originally had the following above the checkboxes:
[<input type="hidden" name="tax_input[$taxname]" value="" />?

This would provide an empty tax_input for a taxonomy that had no terms selected. I'm not 100% sure on browser compatibility for that though. Another alternative might be to use your patch, but have it check against a hidden input that specifies that the taxonomy was actually on screen before clearing it out.

[scribu]

Note that the patch works with hidden metaboxes.

We could check the 'show_ui' parameter:

if ( isset($tax_input[$tax_name]) ) 
    $term = $tax_input[$tax_name]; 
elseif ( $tax_obj->show_ui ) 
    $term = array();
else
    continue;

[dd32]

I was originally going to add this to the metabox:

$name = ( $taxonomy == 'category' ) ? 'post_category' : 'tax_input[' . $taxonomy . ']';
echo "<input type='hidden' name='{$name}[]' value='0' />"; // Allows for an empty term set to be sent. 0 is an invalid Term ID.

That'd have worked and done the job..

But handling it properly in wp_insert_post() is probably better.

if ( isset($tax_input[$tax_name]) ) 
    $term = $tax_input[$tax_name]; 
elseif ( $tax_obj->show_ui ) 
    $term = array();
else
    continue;

I dont like that for one particlar reason, tax_input will only be set by show_ui, if a plugin sets it itself with a custom div, then they'll have to hack around this bug themselves by including a 0 term_id.

Its probably best to have a clear-cut working functionality, Any automatically added metaboxes will work as expected, but if a plugin adds a custom taxonomy div, they'll have to handle all the term saving..

This is a version i've come up with based off scribu's patch:

	// new-style support for all taxonomies
	$tax_names = get_object_taxonomies( get_post($post_ID) ); 
	foreach ( (array)$tax_names as $taxonomy ) {
		$taxonomy_obj = get_taxonomy($taxonomy);
		if ( !current_user_can($taxonomy_obj->show_ui) )
			continue;
		if ( !current_user_can($taxonomy_obj->assign_cap) )
			continue;

		$tags = isset($tax_input[$taxonomy]) ? $tax_input[$taxonomy] : array();
		wp_set_post_terms( $post_ID, $tags, $taxonomy );
	}

[dd32]

updated code:

	// new-style support for all taxonomies
	$tax_names = get_object_taxonomies( get_post($post_ID) ); 
	foreach ( (array)$tax_names as $taxonomy ) {
		if ( 'category' == $taxonomy ) // Handled seperately.
			continue;
		$taxonomy_obj = get_taxonomy($taxonomy);
		if ( !current_user_can($taxonomy_obj->assign_cap) )
			continue;
		if ( !current_user_can($taxonomy_obj->show_ui) )
			continue;

		$tags = isset($tax_input[$taxonomy]) ? $tax_input[$taxonomy] : array();
		wp_set_post_terms( $post_ID, $tags, $taxonomy );
	}

Previous code was causing all Categories to be striped from posts.

[dd32]

(In [14230]) Allow edit posts page to save a empty set of terms for a custom hierarchical taxonomy. Props scribu for initial patch. See #10122

[ryan]

(In [14247]) Revert [14230]. Broke menu save. see #10122

[scribu]

Related: #13153

[prettyboymp]

The more I think about this, the less I like having wp_insert_post use permission checks against assign_cap and show_ui being with the wp_insert_post() method. These checks should probably be propagated up into the edit_post and write_post methods since wp_insert_post is used in a lot of places.

I'm heading out for WCSF and have a 5 hour flight tomorrow. I'll try to work on a new patch then.

[prettyboymp]

oops, didn't mean to change the type to enhancement.

[nacin]

I agree, cap checks here are not a good idea.

This ticket is going to run the gauntlet right now -- feature request to enhancement to bug to task.

[dd32]

$name = ( $taxonomy == 'category' ) ? 'post_category' : 'tax_input[' . $taxonomy . ']';
echo "<input type='hidden' name='{$name}[]' value='0' />"; // Allows for an empty term set to be sent. 0 is an invalid Term ID.

might be the better way to go here then, That way, the list of taxonomies in the request WILL be set in every case.

[prettyboymp]

Clear hiearchical terms fix

[dd32]

(In [14426]) Handle $_POST containing an empty term array, Fixes saving of deselecting all hierarchical terms. Fixes #10122

[prettyboymp]

The fix doesn't check against the user's ability to assign to the taxonomy. A user without correct capabilities could alter the tax_input data to set terms when they shouldn't.

[dd32]

(In [14431]) Remove accidental code. See #10122

[nacin]

Fixed?

[prettyboymp]

Replying to nacin:

Fixed?

The bug with not being able to clear the terms is fixed. However, the patch I submitted (ticket:10122:10122.diff​) did more than just add an empty input array because that didn't check against user's permission to assign to the taxonomy. That patch would be a better fix than what was committed.

[ryan]

Looks like wp_insert_post() does taxonomy cap checks for tax_input. We don't usually put cap checks that low in the stack, however.

[ryan]

I guess that cap check in wp_insert_post() is good enough for now.