Ability to create exclusive custom taxonomies

[benbalter]

Custom taxonomies should have the option of toggling exclusivity, meaning the user should only be able to select one term at a time.

Currently, developers wishing to implement an exclusive custom taxonomy (and thus would prefer radio buttons rather than check boxes on the add/edit post pages) must remove the existing taxonomy meta box completely and build their own, simply to change the input type. This not only duplicates code and development effort, but has the potential to create security vulnerabilities when plugin developers stray from best practices, for example, when recreating the AJAX add term functionality.

Exclusive taxonomies are not uncommon in every day life and are even more common when one thinks about typical custom post type implementations (e.g., students->school year, employee->department, car->color, ice cream->flavor).

While the best implementation is uncertain, I propose the function register_taxonomy accept an optional 'exclusive' argument (similar to 'hierarchical') that would change the check boxes within the taxonomy meta box to radio buttons and would handle the POST accordingly.

[nacin]

I see use cases for this, for sure. We've discussed radio buttons in the context of #14746.

We have checkboxes for the hierarchical meta box only, with the nonhierarchical taxonomies receiving the ad hoc tags box.

How would you handle hierarchy? Would "exclusive" be limited to nonhierarchical taxonomies using a derivative of the hierarchical meta box? Is hierarchy and exclusive .. mutually exclusive?

When I first saw this, my initial thought was that "exclusive" should be solely a property of the meta box, but obviously we would have to enforce that elsewhere, on save.

I think deciding on exactly how it should be enabled and enforced is the tricky part. The code should be easy.

[thenbrent]

My use case for this is a rating taxonomy (Excellent, Good, Satisfactory, Below Average, Poor). This needs exclusive types as an item can't be both "Excellent" & "Satisfactory".

However, there might be multiple dimensions each requiring an individual rating - 'Speed', 'Service, 'Quality' etc. These could be separated into distinct meta boxes or combined into the one hierarchy. If in the one hierarchy, it would need to be possible to choose one rating (child) for each dimension (parent). The advantage of this method being that it uses one meta box instead of three.

Unfortunately, these are probably atypical requirements. For most use cases, I imagine exclusive means on that taxonomy in it's entirety. So, I guess that would be the better option and I'll be left with 3 meta boxes. :)

[scribu]

Just having an 'exclusive' flag is kind of useless, since most use cases will also require defining a custom metabox.

We already have two distinct capabilites - 'assign_terms' and 'manage_terms' - which can be used to define exclusive taxonomies.

[nacin]

Reopening as I plan to take this in a modified direction. Will follow up.

[nacin]

#16708 marked as a duplicate.

Here's what I'm planning here. Basically, a taxonomy will be able to choose from a series of meta boxes.

• checkboxes (currently used for hierarchical taxonomies)
• input box (currently used for non-hierarchical taxonomies)
• radio buttons, based on the current checkbox meta box (exclusive)
• radio buttons, based on the current post format meta box (exclusive)
• a dropdown (exclusive)

There are possibly others, especially hybrids (like the current non-hierarchical taxonomy box, only with a dropdown, like the current Trac keywords box). Also possibly one other that escapes me, but I think I got the main ones covered. I'm not even covering sortable term orders here, which is a whole other idea.

Exclusive taxonomies (where you can enforce only one term being selected) will be enforced server-side. The post format stuff will be entirely abstracted into one of these meta boxes as well as the save handler.

This will also allow us to adopt a flag to turn off the popular terms support, particularly the functionality in #3130, making the existing hierarchical taxonomy box far more flexible. There will also be a flag, where appropriate, for the option to choose no term, in the case of exclusive taxonomies (otherwise you couldn't de-select the choice). There can also be a flag for the ability to add new terms (possibly based on permissions), the tag cloud as appropriate, etc etc.

I think this is also a perfect time to finally create a basic WP_Meta_Box class.

This (as well as the class) is something I'm willing to shepherd for 3.2. Support it during the scope sessions if you like it.

The ideas here have been bounced around a bit among other members of the core team (at Tybee), but I'd like to see where else this can go to grow a new API.

[scribu]

RE WP_Meta_Box: #15066

[sanchothefat]

This is something I really really wanna see in core.

Just my thoughts on the initial post here:

Where we have 'heirarchical' => true it would make more sense to me to have a 'type' argument which would accept one of:

• heirarchical
• exclusive
• flat

My reasoning here is that an exclusive taxonomy could not be heirarchical. If it's one term it shouldn't be in another. The value 'flat' would equate to the tag style taxonomy.

There's another benefit to this approach which is that core methods could be added to register valid taxonomy types. The register_taxonomy_type function would take the type id and a callback function for the metabox. It'd be a neater solution to creating custom taxonomy meta boxes as well.

An example pseudocode function:

register_taxonomy_type( $type, $meta_box, $editable = true, $terms ) {

    // add $type to valid taxonomy types

    // associate the meta box callback function with the $type

    // if $editable is false then don't show 'add new' links or main admin UI
    // and rescind manage_terms capabilities

    // if $terms is supplied these would be the default terms in the taxonomy
    // $terms should be required when $editable is false

}

So for post formats you'd have:

register_taxonomy_type(
    'post_format',
    'post_formats_meta_box',
    false,
    array( 'gallery' => __( 'Gallery' ), 'video' => __( 'Video' ), ...etc... )
);

With regards to backwards compatibility it would simply be a case of if the 'type' argument is not present the 'heirarchical' boolean is mapped to the 'heirarchical' or 'flat' taxonomy types.

This is probably what you had in mind already but wanted to get my ideas down in the appropriate place.

[sanchothefat]

Regarding the above you'd also have to be able to specify the save routine, probably in the register_taxonomy_type() bit. That would allow for having a dropdown style interface that could use the same saving routine as the radio button style exclusive type.

[husobj]

I agree with Nacin's initial list of UI options you may want to use.

Replying to sanchothefat:

Where we have 'heirarchical' => true it would make more sense to me to have a 'type' argument which would accept one of:

• heirarchical
• exclusive
• flat

My reasoning here is that an exclusive taxonomy could not be heirarchical. If it's one term it shouldn't be in another. The value 'flat' would equate to the tag style taxonomy.

I think you may want to have an exclusive hierarchical taxonomy. An example might be an employee > job title relationship where an employee can only be in one department, but job titles are hierarchical to denote structure within a company.

[benbalter]

Agree with husobj that exclusive hierarchical taxonomies are possible (think organizing a patches CPT by WP version #, you'd have 3.2 as a top level term, and under that 3.2.1, 3.2.2, etc.).

Following up on the progress of #18179 per nacin's comment, it looks like the direction WP_Meta_Box went may make this easier in the long run, but in the near term doesn't natively support anything approaching the UI described.

Glad to take a first pass at this, to move things along, and if WP_Meta_Boxes becomes core, shouldn't be too hard to incorporate.

Either way, it sounds like the general consensus is adding an input to the register_post_type() args array, to accept check, input, radio, or dropdown?

[benbalter]

Rough 1st pass -- no JS, no quick-edit

[benbalter]

Plugin to create a radio and dropdown taxonomy with 3 dummy terms

[benbalter]

Uploaded 14877.diff​ which is an extremely rough first pass, but should at least help get things going. I tried to write it in such a way that could easily be converted over to class that extends WP_Meta_Box down the line. AJax adding of new terms isn't done yet, as is a quick-edit UI similarly lacking, but the basic concept/proposed approach/functionality is there.

I abstracted the native category and tags drop downs, and attached a plugin ( exclusive-taxonomies.php​ ) that creates a radio and dropdown taxonomy for testing purposes.

I can keep plugging away, but thought I'd check in before I went too far down the rabbit hole.

[scribu]

Why do we need both 'dropdown' and 'radio'?

[benbalter]

Hadn't thought of it when I originally opened the ticket, and was just going off of Nacin's specs above. Easy to code (just spits out wp_dropdown_categories()), and I assume you'd use it for the same reason you'd use a dropdown vs. radio buttons anyplace else (sequential stuff like year of birth, state, etc.)?

[scribu]

I don't follow. You can order radio buttons just as well as options in a dropdown.

[scribu]

Also, if you would want to save space, you would want to put multiple taxonomy dropdowns in a single metabox, which is outside the scope of this ticket.

[benbalter]

Replying to scribu:

I don't follow. You can order radio buttons just as well as options in a dropdown.

Sorry, meant I assume the logic would be to give developers the option to use either a dropdown or radios... the same decision they'd make anyplace else on the internet. Not sure what the rule/design decision is there, but, e.g., I've never seen year of birth or states represented with radio buttons. Again, was just going off of the comments above and since it's modular, easy to just pull out that one function if need be for simplicity sake.

[nacin]

Replying to scribu:

Why do we need both 'dropdown' and 'radio'?

Why not? Perhaps there are are expected to be dozens of items, or 3 items. One might want dropdowns in one case but radio buttons in another.

Why do both <input type="radio"> and <select> both exist? In both cases, the end result is take X items, pick one. It's because they have different user interface and experience uses.

[Viper007Bond]

+1 to both. If you have three items, radio is easiest. If you have 100, dropdown is a must.

[husobj]

+1 to both input styles from me too.

Radio buttons work well for a short set of options like post formats.

Dropdrown menu would be better if you had a big list of countries etc.

[scribu]

It turns out that exclusivity can also depend on the post type.

For example, you might want to be able to select a single category for a post, but multiple categories for a page.

[scribu]

So, the appropriate API would be something like this:

register_taxonomy_for_object_type( 'category', 'page', 'exclusive' );

Of course, things are complicated by the fact that register_taxonomy() demands an object type as well.

[MikeSchinkel]

Replying to scribu:

If you are going to add an occassionally used parameter it would be better as part of an $args array in case other parameters are ever needed which follows other register_*() function signature patterns:

register_taxonomy_for_object_type( 'category', 'page', array( 'exclusive' => true ) );

[wonderboymusic]

#14206 was moved to 3.7 and provides meta_box_callback as an arg to register_taxonomy() - seems like a new core meta box callback function could go a long way here?

This patch currently explodes against trunk, as expected

[helen]

I'm down with a few other core callback functions - radio, select, maaaaybe multi-select (horrible UX by default, but can be used with JS helpers). I don't see why checkboxes and input+suggest shouldn't also be choices for any taxonomy, hierarchical or not. Just have to do the right thing with ID vs. slug.

[helen]

Actually, I'm so down with it, I said so at WCSF and now I'm moving this to 3.7.

[helen]

Sad - gotta punt for now. Suggest that a patch do the following:

• Allows the current post_categories_meta_box and post_tags_meta_box to be used for both hierarchical and non-hierarchical taxonomies. Former expects IDs for save, latter expects slugs. This is probably going to take some running around inside other functions as well.
• Adds callback functions for radio, select, and multi-select.

This is operating on the assumption that #14206 will be landing in 3.7 shortly, adding the meta_box_cb arg to register_taxonomy().

[helen]

benbalter noted it way early on, but let's not forget to include inline edit. Related: #26948

[helen]

#27249 was marked as a duplicate.

[wonderboymusic]

Someone should look at this, could be fun

[Mte90]

I tried to refresh the patch but few things in the core are changed so require a check before try to refresh.

[helen]

I wanted to actually write some code for once, so 14877.2.diff​ is a fresh start that has an initial setup for a select dropdown. It works, but does not include "Add New" functionality. Much of the naming and markup are just to get something going and don't have to stay the same, and there are also a few todos in there.

I may not come back to this immediately, so if somebody else wants to continue from here, pipe up so we don't duplicate efforts. What I wrote in 49 mostly still holds true, except let's not chase multi-select just yet since default multi-select UI is terrible and the resulting data is no different from checkboxes.

[mrengy]

Looks as though this has been idle for a while. This feature would be really helpful. I came across [this workaround](​https://www.toptal.com/wordpress/wordpress-taxonomy-tutorial), but I couldn't get it to work on an attachment (rather than a post).