WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 9 years ago

#10122 closed task (blessed) (fixed)

create metaboxes for hierarchical taxonomies

Reported by: nicomollet Owned by: ryan
Milestone: 3.0 Priority: normal
Severity: minor Version: 2.8
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description (last modified by dd32)

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

Attachments (9)

hierarchical_metaboxes.patch (28.1 KB) - added by prettyboymp 10 years ago.
removed alert left from debugging
hierarchical_metaboxes-2.patch (12.3 KB) - added by prettyboymp 10 years ago.
10122.patch (28.6 KB) - added by prettyboymp 10 years ago.
latest patch
test-hierarchical-taxonomy.php (537 bytes) - added by prettyboymp 10 years ago.
simple plugin to test
10122-2.patch (28.6 KB) - added by prettyboymp 10 years ago.
Fixed typo causing checked parent categories to return unchecked after addition of sub-category
test-hierarchical-taxonomy.2.php (527 bytes) - added by prettyboymp 10 years ago.
changed taxonomy registration to fire on init instead of plugins_loaded after some users had issues with rewrite.php not being loaded yet
10122-3.patch (28.6 KB) - added by prettyboymp 10 years ago.
removed stray 'aaa' text in meta-boxes.php
wp_insert_post.diff (1016 bytes) - added by scribu 9 years ago.
allow clearing all terms
10122.diff (1.8 KB) - added by prettyboymp 9 years ago.
Clear hiearchical terms fix

Download all attachments as: .zip

Change History (65)

#1 @nicomollet
10 years ago

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.

#2 @Denis-de-Bernardy
10 years ago

  • Keywords needs-patch added
  • Milestone changed from Unassigned to 2.9

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

#3 @Denis-de-Bernardy
10 years ago

  • Milestone changed from 2.9 to Future Release

#4 @ryan
10 years ago

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

#5 @harrym
10 years ago

Any chance of this making it into 2.9?

#6 @dd32
10 years ago

  • Description modified (diff)
  • Summary changed from register_taxonomy only for tags, not for categories ? to create metaboxes for hierarchical taxonomies

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?

#7 @prettyboymp
10 years ago

  • Cc mpretty@… added

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.

#8 @prettyboymp
10 years ago

  • Keywords has-patch added; needs-patch removed

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
10 years ago

removed alert left from debugging

#9 @prettyboymp
10 years ago

Any chance we can have this added by 2.9?

#10 @prettyboymp
10 years ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 2.9

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.

#11 @pampfelimetten
10 years ago

+1 for 2.9! Could be quite handy.

#12 @ryan
10 years ago

  • Milestone changed from 2.9 to Future Release

#13 @epicalex
10 years ago

  • Cc epicalex added

#14 follow-up: @harrym
10 years ago

  • Owner changed from filosofo to ryan
  • Status changed from new to reviewing

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

#15 @strider72
10 years ago

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"

#16 @prettyboymp
10 years ago

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

#17 in reply to: ↑ 14 @markjaquith
10 years ago

  • Milestone changed from Future Release to 3.0

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.

#18 follow-up: @harrym
10 years ago

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?)

#19 in reply to: ↑ 18 @prettyboymp
10 years ago

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.

#20 @lloydbudd
10 years ago

  • Keywords early added

Testing current patch on WordPress.com

#21 @dd32
10 years ago

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.

#22 @sirzooro
10 years ago

  • Cc sirzooro added

#23 @ryan
10 years ago

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

#24 @scribu
10 years ago

  • Cc scribu@… added
  • Keywords changed from has-patch, needs-testing, early to has-patch needs-testing early

#25 @scribu
10 years ago

Related: #11576

#26 @hakre
10 years ago

  • Keywords has-patch removed

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?

#27 @dd32
10 years ago

  • Keywords needs-patch added; needs-testing early removed

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.

#28 @dd32
10 years ago

  • Keywords early added

removed the early tag.. adding it back

#29 @dd32
10 years ago

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

@prettyboymp
10 years ago

latest patch

@prettyboymp
10 years ago

simple plugin to test

#30 @prettyboymp
10 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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
10 years ago

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

@prettyboymp
10 years ago

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

@prettyboymp
10 years ago

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

#31 @rickybuchanan
10 years ago

  • Cc ricky@… added
  • Keywords tested added; needs-testing removed

#32 @rickybuchanan
10 years ago

Props to prettyboymp, this is sweet.

#33 @ryan
10 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

#34 @dd32
9 years ago

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

#35 @scribu
9 years ago

Related: #12911

#36 @scribu
9 years ago

  • Keywords needs-patch added; has-patch early tested removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

I found a slight problem.

Steps to reproduce:

  1. Register a hierarchical taxonomy
  1. Create a post and assign one or more terms in that taxonomy
  1. Uncheck all terms in the taxonomy metabox and save post

Result:

The terms remain checked.

@scribu
9 years ago

allow clearing all terms

#37 follow-up: @scribu
9 years ago

  • Keywords has-patch added; needs-patch removed

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

#38 in reply to: ↑ 37 @prettyboymp
9 years ago

  • Keywords needs-patch added; has-patch removed

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.

#39 @scribu
9 years ago

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;

#40 @dd32
9 years ago

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 );
	}

#41 @dd32
9 years ago

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.

#42 @dd32
9 years ago

(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

#43 @ryan
9 years ago

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

#44 @scribu
9 years ago

Related: #13153

#45 @prettyboymp
9 years ago

  • Type changed from feature request to enhancement

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.

#46 @prettyboymp
9 years ago

  • Type changed from enhancement to defect (bug)

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

#47 @nacin
9 years ago

  • Type changed from defect (bug) to task (blessed)

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.

#48 @dd32
9 years ago

$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
9 years ago

Clear hiearchical terms fix

#49 @prettyboymp
9 years ago

  • Keywords has-patch added; needs-patch removed

#50 @dd32
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#51 @prettyboymp
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#52 @dd32
9 years ago

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

#53 follow-up: @nacin
9 years ago

Fixed?

#54 in reply to: ↑ 53 @prettyboymp
9 years ago

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.

#55 @ryan
9 years ago

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.

#56 @ryan
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.