wp_dropdown_categories() uses $term->id instead of $term->name for taxonomies that are not categories

Description

I was excited to discover that wp_dropdown_categories() had been extended to support custom taxonomies but when I tried to implement it, the navigation failed because it always uses the $term->ID in the value attribute of the option tag for each term.

<option class="level-0" value="13">A Category</option>

This makes sense because WordPress category requests uses the term id: /?cat=13

Which works great for categories by does not work at all for other taxonomies.

/?cat=14

/?tag=my-tag-name

/?taxonomy=my-taxonomy-term-name

Categories are the only post taxonomy queried by id number, all others use slug. I reported this as a bug because I was looking through core and saw that wp_dropdown_categories() now allows the user to pass taxonomy as a key in the $args array.

This would be awesome to have fixed in core. Hopefully I have explained the issues well enough. You can see the changes that I needed to make to get my plugin functioning correctly here ​http://wordpress.pastebin.com/scckuBhp.

I want to move this to 3.1. I'm not really sure the best way to do restructure this. Ultimately, the categories widget still only takes categories. Ideally, we'd allow either a walker override, or the ability to use the slug instead of the ID.

The slug instead of the ID should probably be default for non-category taxonomies, which makes me want to revert taxonomy support for 3.0 from wp_dropdown_categories, or at least force a check in the walker to use the slug instead of the ID if it's a category. Then again, there are plenty of use cases (the JS functionality of the widgets not one of them) for the ID.

This bug also applies if a person wants to add a custom filter for taxonomies to edit.php . WP is expecting custom-taxes to have a slug as the query_var rather than the term_id and this means that the existing wp_dropdown_categories won't work for the custom filter. Like mfields, I have to create a custom dropdown function for the custom filter.

on wp-includes/category-template.php row 953 for all other taxonomies then $category (or even for category and change the default select name to category instead of cat), or add another option to wp_dropdown_categories e.g. 'values' with default 'term_id' and then do something like

In the meantime, its possible to replicate this by passing a custom walker which extends the Walker_CategoryDropdown class and replaces the start_el method. See this gist: ​https://gist.github.com/2902509

I use wp_dropdown_categories in a meta box to let the user pick a "primary" term from a custom taxonomy for a related custom post. Then, I filter get_posts in a shortcode to insert a list custom posts with that meta value. Only the dropdown still has the id values, so my shortcode query would by dependent on the order the custom terms were entered in the database.

adds a "show_last_update" argument that returns an error since no such argument exists

I fixed those two things and also tested the patch, but I am not sure it is in working condition yet. Issues I find

it will break if you don't set the "name" argument with the taxonomy's slug

it will break if you set value to "term_id" when using anything other than category (is the possibility of having an option really needed, or wouldn't it be better to just have it default to id for categories and slug for other taxonomies?)

Whoops, this was fixed with the introduction of the 'value_field' parameter in [31006]#30306. You can use 'value_field' to specific id, slug, or whatever other term field you want to serve as the "value" attribute of the dropdown options.

As for the precise issue that led to the opening of this ticket: The job of the category/term dropdown is to generate a dropdown. It does that perfectly fine. It so happens that, in the case of categories, the value of the dropdown can be used to concatenate a certain kind of URL (?cat=13), while the precise same thing can't be done in the case of other taxonomies. But this is not a bug. It just means that devs should be responsible for sanitizing data they get from form submits before generating URLs or any other user-facing data.