[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:  3.0             
Component:  General       |     Version:  2.9             
 Severity:  normal        |    Keywords:  has-patch tested
--------------------------+-------------------------------------------------

Comment(by jeremyclarke):

 Replying to [comment:6 hakre]:

 Thanks for your careful consideration. I hear what you're saying about how
 they should be the same, and it would have been a good argument against
 the changes that have been made to the widgets API to use the new OO model
 for creating new widgets. That is the 'form api' I'm talking about, the
 system where you extend WP_Widget to add new widgets. It uses two methods,
 WP_Widget::form and WP_Widget::update, to automate the process of setting
 options for each widget instance. This involves using two other methods to
 get the id and name of each field in the form,
 $this->get_field_id('badges_page_id') and
 $this->get_name_id('badges_page_id').

 That's the test case I'm talking about. They output different things as
 mentioned above, name is the standard output like
 name="myoption[setting1]" and id's mirror the names but with underscores,
 like id="myoption_setting1". Thus its not a new form api per se, but this
 effectively creates a situation where WP needs to make any form-related
 functions work with seperate names and ids, so that they will be
 compatible with widget settings, which are some of the most important in
 WP going forward (widget api is basically the CMS api :P)

 In this situation it's impossible to use wp_dropdown_pages because the
 name and ID must be different and the function doesn't allow it. I want to
 use wp_dropdown_pages in my widget settings because the widget needs to
 know the ID of a specific page.

 In case its not clear, I'm using wp_dropdown_pages in my plugin code as
 part of the API, rather than patching it for its meager uses in core. IMHO
 this function is incredibly useful for plugin authors and should be
 treated as public API, to force plugins to redo the work of this function
 makes no sense to me. It's a great, easy to use function in all other
 situations and it should work with widgets too. The simplest possible test
 case would probably be a 'show page contents' widget, where you choose a
 page who's contents you want to show inside the widget.

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