WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 8 months ago

#52750 closed defect (bug) (fixed)

WP 5.7 colors inconsistent in get_option( 'admin_color' ) since color contrast changes

Reported by: ninetyninew Owned by: audrasjb
Milestone: 5.7.1 Priority: normal
Severity: normal Version: 5.7
Component: Options, Meta APIs Keywords: has-patch fixed-major
Focuses: accessibility, css Cc:

Description

Admin colors have changed in 5.7, we have developed some plugins which use:

get_user_option( 'admin_color', get_current_user_id() );

To then use the selected color palette to apply those values dynamically to some elements.

This returns an array of admin colors based off the selected admin color palette by the user:

stdClass Object ( [name] => Default [url] => [colors] => Array ( [0] => #1d2327 [1] => #2c3338 [2] => #3582c4 [3] => #72aee6 ) [icon_colors] => Array ( [base] => #a7aaad [focus] => #72aee6 [current] => #fff ) )

These return values do not seem in sync with the new colors.

e.g. #3582c4 is returned for the primary color (I think this is the old blue?), I am expecting this to return the new value of #2271b1 (I think?)

Attachments (3)

52750.diff (490 bytes) - added by ryelle 8 months ago.
trunk.png (11.3 KB) - added by ryelle 8 months ago.
patch.png (11.4 KB) - added by ryelle 8 months ago.

Download all attachments as: .zip

Change History (16)

#1 @audrasjb
9 months ago

  • Component changed from General to Options, Meta APIs
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.7.1
  • Owner set to audrasjb
  • Status changed from new to reviewing

Hello, thanks for reporting the issue!

#2 @desrosj
9 months ago

  • Keywords reporter-feedback added; needs-patch removed

@ninetyninew Are you able to provide more details? In my testing, get_user_option( 'admin_color', get_current_user_id() ); is returning the string name of the user's selected color scheme. In my case, it was fresh.

To then use the selected color palette to apply those values dynamically to some elements.

Is there more code run for this step that is not included in the ticket description? If not, is there potentially a plugin active that is filtering the admin_color value to be an object with the corresponding hex colors?

#3 @ninetyninew
9 months ago

Ah! apologies I've just double checked and i'm actually adding an extra line after the get_user_option part of this:

$_wp_admin_css_colors[$current_color_scheme]

Where $current_color_scheme is the color scheme returned from the get_user_option.

So the issue is within what is returned from the global $_wp_admin_css_colors and not the get_user_option itself.

@desrosj

#4 @desrosj
9 months ago

  • Keywords 2nd-opinion added; reporter-feedback removed

Related ticket: #49999.
Changeset: [50025].

Based on the changes to the `general-template.php` file in the commit specified above, I think this is behaving as expected.

@ryelle can you confirm this is the correct new value?

#5 @ryelle
9 months ago

That's correct, #3582c4 is the new value from the new color palette, but primary buttons are #2271b1. These colors aren't intended to be a 1:1 match to the colors used in the CSS (there are more colors in the CSS than just 4, for one thing). The "right" way to pull in color scheme styles is to use the helper classes, wp-ui-highlight or wp-ui-highlight-text.

But I wonder if there are a lot of plugins that use the PHP values this way 🤔 Should we update that value to match the button color?

#6 @ninetyninew
9 months ago

@ryelle I can't remember which but I've seen other plugins use this method. On one of our particular plugins we use this so we can style some events within a calendar in the same color the user is seeing within the admin area so it matches their admin style.

I'm pretty sure before these changes occurred the value returned from this was the same as the admin button color.

#7 @ryelle
9 months ago

  • Keywords needs-patch added; 2nd-opinion removed

Okay - I think we should update this, since it's a quick fix, and if anyone is using this value, it probably doesn't have a high enough contrast to be accessible (that's why we changed the button color in #52402).

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


9 months ago

#9 @peterwilsoncc
9 months ago

  • Focuses accessibility css added

@ryelle
8 months ago

@ryelle
8 months ago

@ryelle
8 months ago

#10 @ryelle
8 months ago

  • Keywords has-patch added; needs-patch removed

#11 @peterwilsoncc
8 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 50663:

Options, Meta APIs: Update default color scheme swatch to match CSS changes.

Update the default/fresh theme color swatch displayed on user profile pages to match CSS changes made during the 5.7 release cycle.

Props audrasjb, desrosj, ninetyninew, ryelle.
Fixes #52750.

#12 @peterwilsoncc
8 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for merging [50663] to the 5.7 branch.

#13 @peterwilsoncc
8 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 50679:

Options, Meta APIs: Update default color scheme swatch to match CSS changes.

Update the default/fresh theme color swatch displayed on user profile pages to match CSS changes made during the 5.7 release cycle.

Props audrasjb, desrosj, ninetyninew, ryelle.
Merges [50663] to the 5.7 branch.
Fixes #52750.

Note: See TracTickets for help on using tickets.