Don't load core colors in editor when theme.json is used #40183
Comments
ndiego
added
the
Global Styles
|
HI @vyskoczilova, you can remove the core color specifications on the frontend by adding the following to your theme.json file. This will also remove the default color and gradient palettes from the color picker UI. They are still printed in the Editor as you indicated, but this will ideally get resolved in future versions of Gutenberg. Thanks for flagging! More functionality for theme developers to opt-out of certain features is ongoing. I will link any relevant PRs as they get created. |
|
@vyskoczilova Could you edit the issue's title to include 'editor' in the title (e.g. "Don't load core colors in editor..."; so it will be easier to find ? |
vyskoczilova
changed the title
|
HI @skorasaurus thanks a lot. I know that I can get rid of them in the frontend, but backend styles are overwriting my styles and instead of having just only one set, I need to develop styles for the editor as well :( I thought that having compact and prefixed blocks will solve this problem, but since all bunch of styles are inline it causes a lot of troubles. |
|
And do we really need !important styles? |
|
|
@ndiego Even with "defaultPalette": false, set I'm still getting the core colors on the front end. This is the case with or without the gutenberg plugin installed.
|
|
I can verify this behavior. The --wp-preset--... definitions for default colors, gradients and duotone are still present on the frontend even with
|
|
I can verify this also. I'm attempting to add a custom color palette to theme.json and only have that appear on the frontend with css variables. Generally the functionality is great but perhaps we need a way to remove the default colors/gradients and duotones from the frontend as listed by @kauaicreative. |
|
I can see the problem too, if defaultPalette, defaultDuotone and defaultGradients are set to false then we don't want to display palette in back office and in front we don't want inline style and css variables "--wp--preset-yyyy--" either. |
|
Still seeing this issue. Adding the abovementioned |
|
I have the same problem, but the question is whether this is by accident or by design that this setting doesn't work as we expect. I have found many other discussions in this repo suggesting the core global palette intentionally always loads on frontend for compatibility reasons. So maybe the |
|
The issue still exists. JSON {
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"appearanceTools": false,
"color": {
"defaultDuotone": false,
"defaultGradients": false,
"defaultPalette": false,
...Still variable exists as: --wp--preset--color--black: #000000;
--wp--preset--color--cyan-bluish-gray: #abb8c3;
--wp--preset--color--white: #ffffff;
--wp--preset--color--pale-pink: #f78da7;
--wp--preset--color--vivid-red: #cf2e2e;
--wp--preset--color--luminous-vivid-orange: #ff6900;
--wp--preset--color--luminous-vivid-amber: #fcb900;
--wp--preset--color--light-green-cyan: #7bdcb5;
--wp--preset--color--vivid-green-cyan: #00d084;
--wp--preset--color--pale-cyan-blue: #8ed1fc;
--wp--preset--color--vivid-cyan-blue: #0693e3;
--wp--preset--color--vivid-purple: #9b51e0;
...
--wp--preset--gradient--vivid-cyan-blue-to-vivid-purple: linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);
--wp--preset--gradient--light-green-cyan-to-vivid-green-cyan: linear-gradient(135deg,rgb(122,220,180) 0%,rgb(0,208,130) 100%);
--wp--preset--gradient--luminous-vivid-amber-to-luminous-vivid-orange: linear-gradient(135deg,rgba(252,185,0,1) 0%,rgba(255,105,0,1) 100%);
--wp--preset--gradient--luminous-vivid-orange-to-vivid-red: linear-gradient(135deg,rgba(255,105,0,1) 0%,rgb(207,46,46) 100%);
--wp--preset--gradient--very-light-gray-to-cyan-bluish-gray: linear-gradient(135deg,rgb(238,238,238) 0%,rgb(169,184,195) 100%);
--wp--preset--gradient--cool-to-warm-spectrum: linear-gradient(135deg,rgb(74,234,220) 0%,rgb(151,120,209) 20%,rgb(207,42,186) 40%,rgb(238,44,130) 60%,rgb(251,105,98) 80%,rgb(254,248,76) 100%);
--wp--preset--gradient--blush-light-purple: linear-gradient(135deg,rgb(255,206,236) 0%,rgb(152,150,240) 100%);
--wp--preset--gradient--blush-bordeaux: linear-gradient(135deg,rgb(254,205,165) 0%,rgb(254,45,45) 50%,rgb(107,0,62) 100%);
--wp--preset--gradient--luminous-dusk: linear-gradient(135deg,rgb(255,203,112) 0%,rgb(199,81,192) 50%,rgb(65,88,208) 100%);
--wp--preset--gradient--pale-ocean: linear-gradient(135deg,rgb(255,245,203) 0%,rgb(182,227,212) 50%,rgb(51,167,181) 100%);
--wp--preset--gradient--electric-grass: linear-gradient(135deg,rgb(202,248,128) 0%,rgb(113,206,126) 100%);
--wp--preset--gradient--midnight: linear-gradient(135deg,rgb(2,3,129) 0%,rgb(40,116,252) 100%); |
Description
Hi! Maybe I miss something, but why when we use theme.json and our colors the global colors are included? We're still fighting with overriding those and since they are inline, its absurdly hard and they are in fact no used in the theme.
I'm talking about these:
Not sure if it's related to the #40181
I think it's a bug and Gutenberg should use avoid those hijacking style tactics - if you build standard CSS it's really time consuming to solve the conflicts you have no control about (since they happen when you update the Core).
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
No response
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
The text was updated successfully, but these errors were encountered: