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!

[tresorama]

Related

#46397

[priethor]

Unfortunately, at the moment it saves its custom color for each "theme".

I agree this is the intended style, as @tresorama says. #50102 is going to introduce site-wide global styles so that settings like custom color palettes can be reused in different themes and variations.

[hagege]

I would also be happy if the issue is fixed. I have just addressed the issue in the Slack channel #fse-outreach-experiment with a corresponding video.
https://wordpress.slack.com/archives/C015GUFFC00/p1684153293359259

[mrfoxtalbot]

This is relevant to this other issue: Additional CSS Erased When Switching Style Variations in WordPress 6.2

[glendaviesnz]

Having looked into this while exploring a possible fix for #50685 the only way I can see to fix this in general for all global style customisations to variations is to add a new global styles CPT for each variation.

Currently, if you select a new theme a global styles entity is added for that theme, and all style customisations for that theme are saved to it. This is why you can make global styles changes to a theme, switch to another theme and make changes, then switch back to your first theme and the original changes are still there.

With a variation it just replaces all of the user customisations in the theme global style entity with the styles from the variation, as @tresorama noted above. It has to do this as it wouldn't be possible to effectively merge all the differences, as there is currently no way to tell which are user style customisations, and which are the variation customisations. Even if you did merge them, once you saved it and then switched to another variation you would end up stacking variation styles on top of variation styles.

One alternative would be to treat a variation switch the same as a theme switch so a new global styles entity is created, enabling you to move between variations without losing customisations to each. You wouldn't see customisations to one variation in another, but at least you wouldn't lose them when switching back and forth. But, this would need some way of identifying which theme+variation global styles entity should be used.

That is my reading of it anyway. I may be overlooking a reason why variations couldn't operate the same as themes in this regard.

I will add a new enhancement issue outlining what would be needed to make this change.

[glendaviesnz]

There is some background here about the rationale for the current setup. Based on this it won't be as simple as adding a new global styles entity for each variation save as suggested above. Some thinking will need to be done about the wider user/variation/theme setup and the impact of any change on themes/plugins, etc.

Some other related issues:

• Global Styles: Managing style variations #38333
• Style Variations: Add warning when custom styles will be lost #40561
• Global Styles: Allow saving, importing, exporting, copying from another theme without switching to it #45371

Given the number of existing issues around this topic I won't make another one - but it might be useful to pick one of the existing ones that best reflects the issue and close all the others in favour of that one.

[tresorama]

Maybe having a situation with these layers:

• Theme
• Theme style( aka theme variation)
• User customization

Could let "deep merging" ...

And also migrate user style to an other theme ...

[annezazu]

Closing this out in favor of #45371 Like Glen, I agree we have a number of duplicate issues that risk slowing down rather than speeding up this effort.