[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 needs-testing
--------------------------+-------------------------------------------------

Comment(by hakre):

 Replying to [comment:4 filosofo]:
 > Replying to [comment:3 hakre]:
 > > name and id are technically the same.
 >
 > I'm not sure why you would say this.  Their definitions and standard
 data types differ (CDATA for name, NAME for id).
 What I meant is that it makes no difference wether I pass a name or id
 attribute to a form element and therefore the report ''might'' have been
 invalid, I just needed clarification. ''Both of these attributes are
 designed to be used as fragment identifiers''. Name attribute is
 depreceated in xhtml 1.0  on certain elements (incl. a and form but not
 input elements AFAIK) and gets more love again in HTML 5
 [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-
 microsyntaxes.html#syntax-references Ref], for the HTML 4.01
 standarization you're right for their datatype definition (name = cdata
 [CI] [http://www.w3.org/TR/html401/interact/forms.html#adef-name-INPUT
 Ref]; id = name [CS]
 [http://www.w3.org/TR/html401/struct/global.html#h-7.5.2 Ref]) but if you
 switch over to XHTML 1.0 you will notice that name has been changed to a
 new definition (name = NMTOKEN).

 So I wrote that because it is kind of common good to put the same value
 into ID and NAME most of all the time (or drop the one or other). I'm
 aware that this can collide while using the
 ''[http://www.php.net/manual/en/faq.html.php#faq.html.select-multiple html
 form names and php array feature]'' while checking for a document's
 [http://validator.w3.org/ validity]. To get more information on
 compability issues regarding ID and NAME the XHTML 1.0 specs have an
 [http://www.w3.org/TR/xhtml1/#C_8 informative appendix which covers most
 of the connected areas]. I'm as well aware that it's not a must to do so.

 > Also, their practical uses differ: if someone wants to have a pages
 select element appear in multiple places in the document, he must change
 the id attribute but not necessarily the name attribute.
 This can but must not be done. The backend can deal with different names
 for different form elements doing the same as well, for XHTML it is very
 much advised to have an ID compareable value in name as well (ID). Again,
 I do not say, that this must be in WP, I just wanted to get more info
 regarding the report.

 jeremyclarke differentiated already with his comment (after yours), so I
 now better understand what this is about.

 ----

 Replying to [comment:5 jeremyclarke]:
 > Replying to [comment:3 hakre]:
 > > name and id are technically the same. it might be that this bug report
 is invalid.
 >
 > In the new APIs being added to wordpress form elements are being given
 name values that set up arrays, like {{{name="myoption[setting1]"}}} and
 id's that mirror the names but with underscores, like
 {{{id="myoption_setting1"}}}. When you start passing names that function
 as array definitions they don't really work as id's anymore, so they need
 to be different.

 Makes sense, I was and I am not aware of a new WordPress Form API so
 therefore I did not know and was not able to test against it. After your
 calrification I tested it right away and it works.

 If you can provide references to the new API for form elements you were
 talking about I would be able to test the patch against those as well.

 > This is why wp_dropdown_pages doesn't work with the Widgets API right
 now, it just makes sense to let people give seperate names and ids. The
 current patch also keeps the default behavior, so if you don't specify an
 id the name value is used. If you like making forms with id matching name
 you still can and won't have to add a new argument.

 Sounds very reasonable to me, but I tested your patch and I must say: It
 does not make any difference for me. I tested on the page-editor with the
 page-dropdown in the attributes widget there. It was one of the two points
 where wp_dropdown_pages is actually used (the other one is the inline
 editor):

 without patch:
 {{{
 <select id="parent_id" name="parent_id">
         <option value="">Main Page (no parent)</option>
         <option value="2" class="level-0">About</option>
         <option value="45" class="level-1">   My Cat</option>
         <option value="47" class="level-1">   My Car</option>
 </select>
 }}}

 with patch:
 {{{
 <select id="parent_id" name="parent_id">
         <option value="">Main Page (no parent)</option>
         <option value="2" class="level-0">About</option>
         <option value="45" class="level-1">   My Cat</option>
         <option value="47" class="level-1">   My Car</option>
 </select>
 }}}

 That might not be the test-case you thought about when I read your report.
 Please provide a test-case so your newly added feature can be properly
 tested.

 As far as I see this patch is working anyway, so I add the tested tag.

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