[wp-trac] [WordPress Trac] #11433: Add 'id' argument to wp_dropdown_pages to match 'name' (needed for use in widget settings)

[WordPress Trac]

#11433: Add 'id' argument to wp_dropdown_pages to match 'name' (needed for use in
widget settings)
--------------------------+-------------------------------------------------
 Reporter:  jeremyclarke  |       Owner:  jeremyclarke
     Type:  defect (bug)  |      Status:  new         
 Priority:  normal        |   Milestone:              
Component:  General       |     Version:  2.9         
 Severity:  normal        |    Keywords:  has-patch   
--------------------------+-------------------------------------------------
 == 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11433>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software