Duplicate colors in palette causes issues

[timelsass]

In the customizer we have created a palette control system, so users have a place to manage their palette globally for our themes. After working on integration with Gutenburg, I've ran into an issue where users are selecting the same color for more than one of the colors in their palette. In the color settings two colors are selected:

When entering into the editor, the following error:

Warning: Encountered two children with the same key, rgb(29, 16, 22). Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.

Since our themes let users change the palette in the customizer, and the color classes are already applied to several elements, it's easy for a user to select the same color twice.

This can be reproduced more easily by adding the same color key via the add_theme_support method:

add_theme_support( 'editor-color-palette', array(
    array(
        'name' => __( 'Dark Background', 'themeLangDomain' ),
        'slug' => 'dark-background',
        'color' => 'rgb(0, 0, 0)',
    ),
    array(
        'name' => __( 'Dark Text', 'themeLangDomain' ),
        'slug' => 'dark-text',
        'color' => 'rgb(0, 0, 0)',
    ),
) );

I think that the same color should be allowed to exist in the palette for the use case of allowing a user to easily change their entire palette for a theme via the global controls (ie the customizer), and that the color selected in the editor should be based on the slug key opposed to using the color key as the slug is meant to be unique, whereas a color doesn't necessarily need to be.

On an instance by instance basis editing content, it might not make much sense to allow multiple colors, so one way to solve this issue would be to remove duplicate colors and prevent the errors from occurring. On the other hand as an example of where this is desirable: We have a theme author create a theme with our system and they assign a slot in the palette for the header background color, which is white, and they also assign another slot to the site content's background color, which is also white. An end user who has the theme and wishes to customize it might want to change the color of their header to something more contrasting with the site content's background, and they can easily do this. The same palette also impacts all of their site content, so it provides a way for a theme author supplying starter content in their themes a way to declare a relationship of how each slot in a palette effects elements on the site instead of tying the color directly to all elements just because it's the same, and ultimately gives the end users less flexibility.

The same issue would be evident when tackling #6941 as it would be easy for a user to select the same color twice as opposed to using a color they have already added in their palette.

Tested on Gutenberg v3.6.2 & WordPress v4.9.8

[designsimply]

I feel I mistakenly labeled this as a help request while it may make more sense as a feature request or enhancement and am correcting that now.

[DesignerThan95]

I have the same problem with the theme I am developing. I also included a dark mode so now the problem is, that if there is the same color two times, always the first one is selected, although that one is thought for a totally different purpose, that way it can happen that the webpage looks not good anymore in one of the modes.

[JiveDig]

+1 here. Same issue with the same reasoning behind having duplicate colors.

[JiveDig]

@timelsass Did you find a workaround? I'm curious about slightly altering the syntax rgb(0, 0, 0) vs rgb(0,0,0) vs rgb(0,0, 0) each time it's duplicated. Feels super hacky but the still curious ;P

[timnicholson]

+1 this is a very big problem for the theme I’m creating also. I very much want users to be able to reuse the same colors with different names (slugs). I want them to be able to select header, title, footer, primary, etc. colors that the theme uses. Users will definitely want the ability to specify the same color # for more than one of those.

Gutenberg already places the slug into the source HTML instead of the color, but it just chooses the first slug with the selected color. We would just need it to return the slug of the color that the user selected Is a color picker Instead.

[nathanrodrigues2111]

I am still facing the same issue in 2023, I still don't understand why WordPress uses color as the unique factor. Where the color can be same from time to time. Using slug would be have been the best approach. This is a really big problem.

My current hacky workaround is to change the last digit or alphabet of the hex eg:
Change this from #251046 -> #251045 , So one slug will have : #251046 and the other one will have #251045 , So that WordPress thinks that its a different color, Hence as per WordPress a different slug. And as per user experience are concerned the difference in the color is not noticeable at all . Hope this helps others as a hacky workaround for the time being, Till WordPress fixes this issue.

Before :

After :

[acketon]

This has caused some issues for us that were very difficult to track down and identify and really should be improved or fixed.

We are upgrading from WP 5.4 to WP 5.7. Sometime between 5.4 and 5.7 two new default colors were added by WP / Gutenberg (White and Black with #ffffff and #000000)

Our plugin was adding new color themes to the default list of colors and we have a color system that treats the colors as a "theme" and then applies that theme styling to the block if that has-color-<theme> class is applied. There are several colors palettes such as Primary, Secondary so classes are added as has-color-primary but we also had a light and dark option which the hex codes for the colors were set as #ffffff and #000000.

In 5.7 we were finding that when the user applied Light color the class has-color-white would be applied instead of has-color-light and so the styling for the "Light" theme was lost and not applied.

If instead of relying on the color value to apply the corresponding class name for the color it relied on the slug of the registered color it seems like this issue might go away.

Our current work around is as others have said to go through and change our Light and Dark registered colors to be a slightly different hex code. However that is going to require updating not just our plugin but a good number of themes that can use a filter to modify the registered colors.

If this can't be fixed, at a minimum some documentation should be noted so that people avoid registering colors that have the same color value as any other colors that are registered. It'd be nice to see a warning in the console or editor if 2 colors with the same color value are registered and are going to result in this issue happening and the wrong class name getting applied.

[jeflopodev]

I'm also having this problem (on wp: 6.4-beta1-56741; & gut: 16.7.0).
And It's really frustrating.
It slows down the process of creating a theme, since it forces you to change the colors manually.

I will use slighly different colors as nathan did here as workaround.

I hope this gets fixed soon🙏

[metasaman]

How is this still not fixed? It destroys the very purpose of tokenizing themes.