Support » Plugin: Gutenberg » Latest update Gutenberg plugin over-rides custom editor color palette

  • Resolved Flexer

    (@flexer)


    Greetings,

    I have defined custom editor-color-palette in the usual way for a custom theme.
    The latest update of Gutneberg Plugin over-rides my custom editor colours and replaces them with default. Disabling Gutenberg Plugin-returns them as they were before the update.

    Thank you

    • This topic was modified 2 months, 1 week ago by Flexer.
Viewing 14 replies - 1 through 14 (of 14 total)
  • Thread Starter Flexer

    (@flexer)

    I now understand that theme.json is the new place to put these options when Gutenberg is enabled. But I understood that add_theme_support( ‘editor-color-palette’) array will not be over written if theme.json does not exist or does not include the setting.color.pallete is not defined. Am I wrong?

    Plugin Support David Smith

    (@get_dave)

    Hi @flexer.

    You are correct that the docs suggest we should have full backwards compatibility with add_theme_support('editor-color-palette').

    https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/#backward-compatibility-with-add_theme_support

    Are you able to provide a code example of your colour palette in order that we can replicate the issue more easily?

    I’ll ask one of the team working on this to see if they can identify whether or not this is a bug.

    Thread Starter Flexer

    (@flexer)

    Thanks @get_dave

    Because the site is going live today I went ahead created a theme.json file and set up the colours there.

    I did not have a chance to see if this is happening on other sites, and see if this might’ve been a cache issue or something else. Sorry about that.

    This is the pretty straight foreward code (which I commented out on live site);
    (BTW: I noticed that in the theme.JSON examples there is no translation code: Maybe another thread for that)

    add_theme_support( 'editor-color-palette', array(
    		     array(
    		       'name' => __( 'Privacy Orange', 'privacy_pro' ),
    		       'slug' => 'privacy-orange',
    		       'color' => '#ee5d4e',
    		     ),
    		     array(
    		       'name' => __( 'Privacy Grey Light', 'privacy_pro' ),
    		       'slug' => 'privacy-grey-light',
    		       'color' => '#f6f6f6',
    		     ),
    		     array(
    		       'name' => __( 'Privacy Grey Mid', 'privacy_pro' ),
    		       'slug' => 'privacy-grey-mid',
    		       'color' => '#777777',
    		     ),
    		     array(
    		       'name' => __( 'Privacy Grey Dark', 'privacy_pro' ),
    		       'slug' => 'privacy-grey-dark',
    		       'color' => '#838587',
    		     ),
    		     array(
    		       'name' => __( 'Privacy Black', 'privacy_pro' ),
    		       'slug' => 'privacy-black',
    		       'color' => '#231f20',
    		     ),
    		     array(
    		       'name' => __( 'White', 'privacy_pro' ),
    		       'slug' => 'white',
    		       'color' => '#FFF',
    		     ),
    			) 
    		);		
    Plugin Support David Smith

    (@get_dave)

    I’ve asked one of the team working on this for info. I’ll also try and add it to the next Core Editor agenda.

    It also overrides fonts settings added via add_theme-support, forcing fonts to be preset values rather than what is specified in add_theme_support and the theme stylesheet. The presets all seem to use !important which should never be done. WordPress and Gutenberg should never override a theme’s settings.

    Plugin Author André

    (@oandregal)

    Hey, thanks for the report and sorry for the trouble.

    This is a bug that I’m fixing at https://github.com/WordPress/gutenberg/pull/34955

    • This reply was modified 2 months, 1 week ago by André.
    Plugin Support David Smith

    (@get_dave)

    @flexer it looks like @oandregal has merged a fix for this issue. It won’t be available in the Plugin until the next release which is 11.6.0.

    However if you’d like to test and verify you can install the Nightly from https://gutenbergtimes.com/need-a-zip-from-master/#nightly and see if that’s done the trick.

    Please do let us know. Much appreciated.

    Plugin Author André

    (@oandregal)

    Hi,

    I have an update to share: I’ve just released Gutenberg 11.5.1, which comes with a fix for this issue. If you update the plugin, it will be resolved.

    I wish I could have done it yesterday but it was not possible. Sorry for the trouble this caused.

    Best,
    André

    Thread Starter Flexer

    (@flexer)

    @oandregal

    Thank you so much for this. This is part of why I love WordPress and one of my main arguments when advocating for WP, we get it done!

    👍 Fantastic!

    @flexer

    Unfortunately, there is still an issue with fonts. I see this:

    has-huge-font-size {
    font-size: var(–wp–preset–font-size–huge) !important;}

    The above CSS overrides my theme setting:
    .has-huge-font-size {
    font-size: 68px;
    font-size: 4.25rem;
    }

    Plugin Author André

    (@oandregal)

    Hi @koolkatwebdesigns,

    “huge” font size is one of the fonts provided by core, which generates the has-huge-font-size class. The full list of fonts, colors, and gradients provided by core can be checked at https://github.com/WordPress/gutenberg/blob/trunk/lib/theme.json#L187

    If a theme wants to override a class provided by core (be it a font, a color, etc.) it can be done by providing a different value for the CSS Custom Property. Something like:

    :root {
    --wp--preset--font-size--huge: <font size value>;
    }
    koolkatwebdesigns

    (@koolkatwebdesigns)

    This was not an issue with earlier versions of the plugin – why should there be !important presets? A theme that worked with an earlier version should still work.

    Thanks

    Plugin Author André

    (@oandregal)

    Hi,

    the presets include !important because of potential conflicts with colors provided by blocks.

    Take a block whose selector has higher specificity than a single class. The post title, for example. If it sets the color like:

    
    .wp-block-post-title h1 {
      color: green;
    }
    

    while the presets are:

    
    .has-red-color {
      color: red;
    }
    

    Now, let’s say a user selects the red color for the post title. Given the specificity of the block and of the preset, the user-provided color won’t be applied. That’s the use case we want to fix with this change: user changes have always higher priority than any theme or core style. This is specially important for generating the global stylesheet (see details). This was discussed here and here.

    I know that the use of !important has a bad reputation and it’s for a reason. However, in this case, it’s an appropriate tool we can use to make sure the end result respects the user actions.

    Note that this change still let the themes to update the values provided by core presets (see example above). Have you been able to try that? Does that work for you?

    I am able to override the presets, I a just disappointed that the update broke previously working code and how presumptive the presets seem.

Viewing 14 replies - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.