[wp-trac] [WordPress Trac] #23477: r21789 creates a breaking change in behavior for get_submit_button (was: Change #21789 creates a breaking change in behavior for get_submit_button)

WordPress Trac noreply at wordpress.org
Thu Feb 14 23:26:13 UTC 2013


#23477: r21789 creates a breaking change in behavior for get_submit_button
--------------------------+------------------------------
 Reporter:  vhauri        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Template      |     Version:  trunk
 Severity:  minor         |  Resolution:
 Keywords:                |
--------------------------+------------------------------

Old description:

> A recent change made to get_submit_button
> (http://core.trac.wordpress.org/changeset/21789/trunk/wp-
> admin/includes/template.php) has caused an unwanted change in behavior
> for a button on a site I maintain. Previously, the string passed as the
> second argument, `$type`, was matched against a switch statement with
> several unique cases. In the event of a non-match in the switch, the
> default action prior to #21789 was to assign the parameter's value as the
> `$class` string without altering it.
>
> The change introduced in #21789 now breaks a string into individual
> classes, which prevents the use of the unique class names within a string
> of additional class names. For example, the string `button-secondary
> save-button action` used to generate a class string in HTML of `button-
> secondary save-button action`, but now generates the unexpected result
> `button save-button action` (note lack of '-secondary') because it
> matches against the following if check on line 1600:
>
> `if ( 'secondary' === $t || 'button-secondary' === $t )`
>
> It should be noted that the phpdoc associated with the function does not
> name the use case that I was employing, but that the behavior of passing
> in a space-separated class string has previously resulted in the string
> being passed through untouched (and the comment here indicates it was
> known and expected behavior (http://core.trac.wordpress.org/browser/trunk
> /wp-admin/includes/template.php?rev=21781#L1649), and this is no longer
> the case. Not sure if this is worth a programmatic fix, or if it might
> just be worth noting in the function docblock that certain classes are
> now 'reserved' and cannot be passed into the `$type` string.

New description:

 A recent change made to get_submit_button
 (http://core.trac.wordpress.org/changeset/21789/trunk/wp-
 admin/includes/template.php) has caused an unwanted change in behavior for
 a button on a site I maintain. Previously, the string passed as the second
 argument, `$type`, was matched against a switch statement with several
 unique cases. In the event of a non-match in the switch, the default
 action prior to [21789] was to assign the parameter's value as the
 `$class` string without altering it.

 The change introduced in [21789] now breaks a string into individual
 classes, which prevents the use of the unique class names within a string
 of additional class names. For example, the string `button-secondary save-
 button action` used to generate a class string in HTML of `button-
 secondary save-button action`, but now generates the unexpected result
 `button save-button action` (note lack of '-secondary') because it matches
 against the following if check on line 1600:

 `if ( 'secondary' === $t || 'button-secondary' === $t )`

 It should be noted that the phpdoc associated with the function does not
 name the use case that I was employing, but that the behavior of passing
 in a space-separated class string has previously resulted in the string
 being passed through untouched (and the comment here indicates it was
 known and expected behavior (http://core.trac.wordpress.org/browser/trunk
 /wp-admin/includes/template.php?rev=21781#L1649), and this is no longer
 the case. Not sure if this is worth a programmatic fix, or if it might
 just be worth noting in the function docblock that certain classes are now
 'reserved' and cannot be passed into the `$type` string.

--

Comment (by nacin):

 Could you provide a specific example, with expected and actual results?
 Could make it easier to understand.

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


More information about the wp-trac mailing list