[wp-trac] [WordPress Trac] #30865: $tax_query_defaults is hardcoded with "slug" as the field in the parse_tax_query function

WordPress Trac noreply at wordpress.org
Tue Dec 30 20:12:31 UTC 2014


#30865: $tax_query_defaults is hardcoded with "slug" as the field in the
parse_tax_query function
--------------------------+----------------------
 Reporter:  jhned         |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Taxonomy      |     Version:  trunk
 Severity:  normal        |  Resolution:  wontfix
 Keywords:                |     Focuses:
--------------------------+----------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 > when submitting data from wp_dropdown_categories with a custom taxonomy,
 you get a tax_query that has a term_id for the term, but it's trying to
 match it against a slug, which results in a 404 page.

 This sounds like a legitimate issue, but we can't solve it by doing
 `is_numeric()` checks. Terms can have numeric slugs, so that a term with
 slug=45 would clash with a term with term_id=45. Currently, a
 `my_custom_taxonomy=45` query var is interpreted as a slug; and changing
 it to be a term_id would break existing implementations. Moreover, even if
 we didn't have to worry about backward compatibility, doing this kind of
 invisible swapping-out of defaults is something that we should avoid doing
 except in cases where there's no possibility for ambiguity, because any
 bugs that arise from this sort of ambiguity are exceedingly hard to debug.

 As you note, #30306 should solve the problem for the specific case of
 `wp_dropdown_categories()`. For the broader issue of ambiguous custom
 taxonomy query vars, one possible solution is to add support for query
 vars of the format `my_custom_taxonomy_field=slug`, which would be used to
 populate `$tax_query_defaults` in `parse_tax_query()`. But this seems like
 a lot of overhead to add if the only problem is with
 `wp_dropdown_categories()`.

 Marking as wontfix for the time being. If problems persist that aren't
 resolved by #30306, feel free to reopen with details.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30865#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list