id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
11433,Add 'id' argument to wp_dropdown_pages to match 'name' (needed for use in widget settings),jeremyclarke,jeremyclarke,"== Problem ==
{{{wp_dropdown_pages}}} outputs a <select> with all the pages on your site in <option>s that have the page id as their {{{value}}}. There is already an option in {{{$args}}} for 'name' but there is none for 'id'. Currently the 'name' argument is used for both the name= and id= attributes in the <select>. 

IMHO this is an obvious oversight and should be corrected on principle. It also specifically presents a problem because as it stands {{{wp_dropdown_pages}}} can't be used in the settings for a widget in the new OO widgets API. To save a setting you need to give it both a name and id with the {{{$this->get_field_id()}}} and {{{$this->get_field_name()}}} methods, so wp_dropdown_pages should accept both parameters to be compatible. 

== Solution ==
This patch adds an 'id' argument to the defaults (with the same default as 'name', so it will be backwards compatible) and uses it in the output. 

== Interim Hack ==
For anyone else bumping up on this problem: Until this patch is in the core a temporary solution is to fetch the output using {{{$args['name'] = $this->get_field_id('setting_name')}}} and {{{$args['echo'] = FALSE}}}, then do a str_replace() on the output to change the name to be {{{$this->get_field_name()}}}. The same principle (fetch the output with echo turned off then filter the id/name to be what you need) can be applied to other situations where this patch would be useful.

Thanks for filosofo for help with the interim solution in #wordpress-dev.
",defect (bug),closed,normal,3.0,General,2.9,normal,fixed,has-patch tested,jeremyclarke WordPress@…