Opened 9 years ago
Closed 8 years ago
#34891 closed defect (bug) (fixed)
get_submit_button uses incorrect check for delete class
Reported by: | rmccue | Owned by: | afercia |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | ui-feedback has-patch |
Focuses: | ui | Cc: |
Description
get_submit_button
has a special case for the delete
type:
if ( 'delete' === $type ) $class = 'button-secondary delete';
However, type
can never actually be 'delete'
, as it's always an array:
if ( ! is_array( $type ) ) $type = explode( ' ', $type );
I'm not sure this is actually useful to fix though, since .delete
doesn't seem to have any styling.
Attachments (1)
Change History (7)
#3
@
8 years ago
- Keywords needs-patch added
Seems the relevant changeset is [21789]: there was a switch
before the change and as far as I see the delete
case was there just to ensure the delete
class was always paired with button-secondary
. Maybe those two lines could be removed now since button-secondary
should not be used (it's not responsive and doesn't reset the outline property on focus) and the default behaviour is to always have the base button
class so the result is button delete
.
#4
@
8 years ago
- Keywords has-patch added; needs-patch removed
The two lines have been removed, since the type is always an array and this check is useless.
Came across this today and wanted to chime in. I also didn't find any styles for
.delete
that would apply to this input, but since the'delete' === $type
is always false, the classes applied to the element arebutton delete
instead ofbutton-secondary delete
, and that could end up affecting the UI.However in the case I ran into today, both
.button
and.button-secondary
get the exact same styles applied unlesstrue
is passed toget_submit_button()
to wrap the input in ap
, but the only difference there is a slight adjustment tovertical-align
.In searching for places that use 'delete' in core, I found only one use: in widgets.php ("Clear Inactive Widgets"). I'm assuming this hasn't cropped up sooner since that form relies on the
removeinactivewidgets
value to trigger its purpose and ignores the classes set.