WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 months ago

#16677 reopened enhancement

wp_dropdown_categories() shows the wrong name/id when $taxonomy argument is set

Reported by: ramiy Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.1
Component: Taxonomy Keywords: has-patch
Focuses: Cc:

Description

when using wp_dropdown_categories() the code result is:

<select name='cat' id='cat' class='postform' >
<option class="level-0" value="1">item 1</option>
<option class="level-0" value="2">item 2</option>
<option class="level-0" value="3">item 3</option>
</select>

The name='cat' id='cat'.


When using wp_dropdown_categories( array( 'taxonomy' => 'channel' ) ) the code result is:

<select name='cat' id='cat' class='postform' >
<option class="level-0" value="1">term item 1</option>
<option class="level-0" value="2">term item 2</option>
<option class="level-0" value="3">term item 3</option>
</select>

The name and the id did not changed to channel.

Attachments (2)

16677.patch (477 bytes) - added by ramiy 3 years ago.
16677.2 (478 bytes) - added by ramiy 3 years ago.
changing the = to !=

Download all attachments as: .zip

Change History (10)

comment:2 follow-up: ocean903 years ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

It's expected behaviour. cat is the default value.

If you want your own name and id you must use this:

wp_dropdown_categories( array( 'taxonomy' => 'channel', 'name' => 'channel' ) )

(id will be the same as name if id isn't set.)

comment:3 in reply to: ↑ 2 ramiy3 years ago

  • Cc ramiy added
  • Keywords needs-patch added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Summary changed from wp_dropdown_categories() shows the wrong name/id when $taxonomy arg is present to wp_dropdown_categories() shows the wrong name/id when $taxonomy argument is set

ocean90, Thank you for the quick response.

The "Expected behaviour" is not always the "Right behaviour".

I know that i can change the "name" and the even the "class" arguments. But i think this should be done automaticly by the system/function.

When i use the category taxonomy, i expect to see name='cat' id='cat'. And when i use custom taxomony, i expect it to be name='term' id='term'.

Furthermore, when using taxonomy=cat we don't need to set name=cat, its done automaticly. The same behaviour shold be in custom taxomony.

When $taxonomy argument is set (and $name is not) the name shold be equal to taxonomy.

ramiy3 years ago

comment:4 ramiy3 years ago

  • Keywords has-patch added; needs-patch removed

ramiy3 years ago

changing the = to !=

comment:5 ocean903 years ago

  • Milestone set to Future Release
  • Type changed from defect (bug) to enhancement

Ok, I agree.

comment:6 wonderboymusic8 months ago

  • Milestone changed from Future Release to 3.7

Patch still applies, easy fix

comment:7 follow-up: nacin7 months ago

  • Milestone changed from 3.7 to Future Release

This seems wrong. The patch actually forcibly overrides 'name', when in reality, someone may have passed a desired 'name' in.

What should happen instead is the *default* should change from 'cat' to whatever the taxonomy name is. Only, the reason why it it is 'cat' is because that is the name of the corresponding query variable. So what we actually need to do is default it to null, then figure out what taxonomy is being queried, and then if 'name' was not passed in, use that taxonomy's query variable as the default.

Ah, but not quite. 'cat' is not the official query variable of categories. That'd be 'category_name'. I don't remember the difference, something having to do with inclusion of children I think. Either way, 'cat' is the ID, while 'category_name' is the actual slug (which is why it is the query variable). If you look at Walker_CategoryDropdown, term_id is clearly used for option values.

I'm sure it's possible to untangle all of this and to come up with some sane defaults that actually make sense. It might need to involve a wp_dropdown_terms() — which is ideally an alias/wrapper at some point, but we've held onto the namespace for some time that way we can "pivot" here if necessary.

So, for now, I don't think a change makes sense here.

comment:8 in reply to: ↑ 7 DrewAPicture7 months ago

Replying to nacin:

I'm sure it's possible to untangle all of this and to come up with some sane defaults that actually make sense. It might need to involve a wp_dropdown_terms() — which is ideally an alias/wrapper at some point, but we've held onto the namespace for some time that way we can "pivot" here if necessary.

See #19780 for wp_dropdown_terms ideas.

Note: See TracTickets for help on using tickets.