Custom colors are lost when styles are changed

[mgawe]

Description

Hi, I noticed a problem with custom color palette in the site editor (as the title).

Step-by-step reproduction instructions

1. Go to Appearance > Editor
2. Open Styles > Colors > Palette > Custom (Add color) > Click "Done" & Save
3. Back to Browse style
4. Change to another style and Save
5. Check if the custom color has been saved in the previous style.

Screenshots, screen recording, code snippet

screen-capture.1.webm

Environment info

• WordPress 6.1.1
• Gutenberg 15.2.0
• Theme Twenty Twenty-Three

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[tresorama]

I think this is the intended behavior.

Step 1
When you select a "Style" variation of the theme the editor save a copy of the whole setting set of that particular "Style" as a copy bounded to the user (you) , then mark it as active.

Step 2
When later you add a color ( or edit an existing one ) and save, the editor create a new setting set, using what is currently "active" at that time as base, and add your overrides to the setting set. Finally persist this in the db.

Step 3
When you then select an other "Style" variation of theme, you restart.
So you are back to step 1.

Your confusion, rightly, arise from lack of this explanation in the UI.

---

For sure there are opportunities for improvement.

This is final user territory, potential not developer, so a better explanation is mandatory.

Imagine that an user create 10 color and then change style just because he likes the fonts.
He lose everything, being frustrated, and maybe consider to switch away from Wordpress.

Potential solution:

1
A confirm dialog that user must accept , that indicate clearly what he will permanently lose on confirmation.
With a "learn more" link that explain the whole system from documentation.

2
Because "Style" has a dedicated panel , there is room for an introduction link also in the first screen of the panel , before the image.
The first time user open the panel is the right time when we should explain the "style" system.

3
A question mark icon that user can click , that reveal a floating box with explanation as text.
Maybe I question mark for every ambiguous buttons of the panel ??

[mgawe]

@tresorama, thank you for the extensive explanation, but it seems to me that this is a bug, because the colors are lost even when previewing other styles. Look please:

anonymous_33050487-8578-47f9-a8ef-28cbe5579485_video.mp4

Shouldn't it work the way that it saves its custom colors for each style?

[tresorama]

Shouldn't it work the way that it saves its custom colors for each style?

Unfortunately, at the moment it saves its custom color for each "theme".
When you change "style" you are overriding what is considered "current customization" for the theme.

At the moment, you cannot save "custom things" for each style, but for each theme only.
So every time you change "style" all previous customization (bounded to that theme) are lost.

Consider this:

• You active TT3(twenty twenty 3) theme.
• leave "default" styles in the editor from "style > browse styles",
• then add a custom color under "styles > colors".
• change theme, let's say TT2 (twenty twenty 2),
• your custom color is not present,
• but if you change theme back to TT3, your custom color comes back.

But if :

• You active TT3(twenty twenty 3) theme.
• leave "default" styles in the editor from "style > browse styles",
• then add a custom color under "styles > colors".
• select a different theme "style" from "styles > browse styles ",
• your custom color is not present, and you lost it forever.

"Styles" are like children of the theme, meaning that every theme can have its own "styles", and each "style" is bounded to its theme. Styles are not cross-theme.
When you switch from a "style" to an other one, you are doing:

Step 3
When you then select an other "Style" variation of theme, you restart.
So you are back to step 1.

[tresorama]

Anyway @mgawe you raised a great issue, because this behavior is not ideal in current stage.
If you are a dev, my advice is to not use the custom color but use only what you can control, so theme.json.

I'm not an expert in Gutenberg and i have used it only for 2 weeks so maybe some other folk can describe an ideal use case for a not developer.

[mgawe]

@tresorama, I use custom colors to define the color palette for a dark mode theme, so I wouldn't want to give up on that.

[tresorama]

@tresorama, I use custom colors to define the color palette for a dark mode theme, so I wouldn't want to give up on that.

Can you explain how your dark mode system work?

[mgawe]

Sure! This is a very simple solution.

@media (prefers-color-scheme:dark) {
  body {
    --wp--preset--color--primary: var(--wp--preset--color--custom-primary-dark-mode);
    --wp--preset--color--secondary: var(--wp--preset--color--custom-secondary-dark-mode);
    --wp--preset--color--tertiary: var(--wp--preset--color--custom-tertiary-dark-mode);
  }
}

[tresorama]

Note about following example

The following example ....

• is not tested.
• i'm not sure that in the Editor UI you will see the right color code for "slot" color (in the circle).
• the problem of this issue (lost of customization on "theme style" changes) should be present even with this system in place, but at least you can preview color change in the editor and then copy/paste the color code to theme.json to make it persists

---

Example

Maybe you can define"slot", "light" and "dark" colors inside theme.json > settings > colors > palette, where the slot is assigned to "light" variant

// in theme.json

{
  "settings": {
    "colors" : {
      "palette": [
         {
          "slug": "primary",
          "name": "primary",
          "color": "var(--wp--preset--color--light-primary)"
        },
        {
          "slug": "light-primary",
          "name": "light-primary",
          "color": "#fff"
        },
        {
          "slug": "dark-primary",
          "name": "dark-primary",
          "color": "#111"
        },

and then control the swap in your css file

/* in your-css-file.css */

@media (prefers-color-scheme:dark) {
  body {
    --wp--preset--color--primary: var(--wp--preset--color--dark-primary);
  }
}

or if you can handle the "writing" you can also opt out a css file and use theme.json > styles > css

// in theme.json
{
"styles": {
    "css": "@media (prefers-color-scheme:dark) { body { --wp--preset--color--primary: var(--wp--preset--color--dark-primary);}}",
}

[mgawe]

Thanks a lot, but management has to be from the Site Editor (it's not for me, but my clients).

[tresorama]

You can teach them to not touch "slot" colors in Editor, and to customize "dark" and "light" variant only.
But yeah, it's not ideal.

[mgawe]

@kathrynwp Is there any chance to give it a higher priority? This is clearly a bug. Thanks!