WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 11 days ago

#16677 closed enhancement (wontfix)

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

Reported by: ramiy Owned by:
Milestone: 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 4 years ago.
16677.2 (478 bytes) - added by ramiy 4 years ago.
changing the = to !=

Download all attachments as: .zip

Change History (11)

comment:2 follow-up: @ocean904 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 @ramiy4 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.

@ramiy4 years ago

comment:4 @ramiy4 years ago

  • Keywords has-patch added; needs-patch removed

@ramiy4 years ago

changing the = to !=

comment:5 @ocean904 years ago

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

Ok, I agree.

comment:6 @wonderboymusic22 months ago

  • Milestone changed from Future Release to 3.7

Patch still applies, easy fix

comment:7 follow-up: @nacin21 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 @DrewAPicture21 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.

comment:9 @boonebgorges11 days ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

I don't think we can fix this in wp_dropdown_categories(). Changing the default value will break any form using wp_dropdown_categories() for a custom taxonomy and using the default value of 'name'. If we build wp_dropdown_terms(), we can and should have more intelligent defaults, but I think we're stuck with what we've got for wp_dropdown_categories(). In the meantime, plugin devs should pass 'name' and 'id' params explicitly.

Note: See TracTickets for help on using tickets.