Twenty Nineteen: Highlight text color isn't reflected in the editor

[karmatosed]

The new text color feature doesn't work in Twenty Nineteen, you are unable to change the text color.

[samful]

CSS Only patch (needs to be made into SCSS)

[samful]

The styles were not being included in the "twentynineteen/style-editor.css" file, I uploaded a patch putting css directly in here, but someone needs to convert this to SCSS and add it to "twentynineteen/style-editor.scss" file.

I tested and 2017 and 2020 do not have this issue.

[samful]

full patch with SCSS

[samful]

Added full patch with SCSS, this was my first time using SASS, so if a SASSY master would look over it for me that would be great!

[ryelle]

I updated the patch to use the same colors as in /sass/blocks/_blocks.scss, and removed the .has-inline-color since it's not technically necessary. This only fixes the issue for the default colors, though.

It's possible to change the primary color in the customizer, and the colors are not updated in the editor. Twenty Twenty had the same issue, see this comment on #50120. The generated CSS in /inc/color-patterns.php needs to be updated.

[smit08]

Hi @karmatosed i have tested it in wordpress 2019 theme and i found it that the text color tool is working, but it is not working on some particular colors like primary, secondary, dark grey etc. But it is working on white and shades of yellow. I am attaching the screen-shot of it.

Testing steps:

1. wp v5.8.1
2. theme Twenty Nineteen
3. add text color on text. add color like primary, secondary, dark grey etc.

screenshot link: ​https://prnt.sc/1wzcbo8

[smit08]

screenshot that shows some colors are working in text color tool and some are not working.

[smit08]

In 2019 theme only primary, secondary and dark green color required the editor css so i created a patch for this 3 colors only.

[poena]

Hi @smit08
Twenty Nineteen uses SCSS and custom SCSS variables. The scss files needs to be compiled/built to create .css files.

Changes made directly to the style-editor.css are overwritten during that build process.
That is why it is not enough to change only style-editor.css.

.has-inline-color is not necessary.

@ryelle mentioned that the primary color can be customized, and that changing the CSS files is not enough to solve the full issue.

Here is how to confirm that:

1) Activate the theme.
2) Open the customizer.
3) Open the colors and select "custom". Set a color, save.
4) Open the block editor.
5) Select a text like a paragraph block and select "highlight" via the block toolbar settings. Select the primary color that you just changed.
6) Confirm that the text is still blue, not the custom color.

[sabernhardt]

With 5.9 Beta 1 release happening in a few hours, moving this ticket to future release.

[sabernhardt]

#56960 was marked as a duplicate.

[poena]

#51090 was marked as a duplicate.

[poena]

Testing with WordPress current trunk:

• Highlights with a color from the palette does not work in the editor.
• Highlights with a color from the palette works on the front.
• When the primary color is updated in the Customizer, the highlights on the front only works for blocks that has a block class name, so it does not work for paragraphs and lists.

The current selector is:

.entry .entry-content > *[class^="wp-block-"] .has-primary-color

• Highlights with a custom color from the color picker works in the editor and front.

There are pull requests in the Gutenberg GitHub repository for adding the wp-block-blockname CSS classes to the paragraph and list blocks, but there is no ETA.

[poena]

Related:
Twenty Nineteen is using CSS selectors that are no longer used in the editor #59922

Trac ticket: https://core.trac.wordpress.org/ticket/49787

Many text based blocks that uses the RichText component has an option called "Highlight".
The option was not working in the editor, and was only working partially on the front.

This pull request adds CSS that applies the correct color when the highlight option in the block toolbar is used, and the color is chosen from the theme palette.
It also adds new selectors for the highlighted element, <mark>, that applies the correct color when the color is changed in the Customizer option. (color-patterns.php)

[poena]

Test instructions

Apply the patch.
Open the block editor and add three blocks with some text: A paragraph, a heading, and a list.
In each block, select parts of the text, open the More options menu in the block toolbar (the down facing arrow icon). Select the blue color, and then the dark blue color in one of the other blocks, so that both these colors are tested.

Save.
Confirm that the highlight is showing correctly in both the editor and front.

Open the customizer, open the Colors panel, and change the primary color to any custom color.
Confirm that the color is updated both in the customizer preview, the front with the customizer closed, and in the editor.

Expected Results

Confirm that the highlight is showing correctly in both the editor and front.

[karmatosed]

I am unable to get the patch working in the latest version of WordPress. This might be due to the latest patch either being the wrong one to use or some changes recently. @poena are you able to test again and see what you find please?

[poena]

I have updated pull request 5921 to include the latest changes from trunk for the file twentynineteen/inc/color-patterns.php

This should solve the merge conflict.

---

This only solves the color of the text highlight.
When the highlight color is set for the background, the custom color set in the Customizer still does not work, not in the editor or the front.

When the highlight color is set to the background, WordPress adds it inline in the style attribute, style="background-color:#0073a8" and without adding a .has-*-background-color class.

[sabernhardt]

Related: #59457 is similar, for the Calendar block

Could the text color rulesets use more generic selectors instead of limiting them to the mark element? For example:

• body .has-primary-color in style-editor.css and
• html .editor-styles-wrapper .has-primary-color in inc/color-patterns.php

[karmatosed]

@sabernhardt it could, I am ok about adjusting if @poena is but I want to make sure we do review this in that case. I am going to flag that for consideration.

[poena]

Could the text color rulesets use more generic selectors instead of limiting them to the mark element? For example:
body .has-primary-color in style-editor.css and
html .editor-styles-wrapper .has-primary-color in inc/color-patterns.php

Yes, if the change doesn't break anything else. How do we test "everything else" ?

In Twenty sixteen, the .has-* is not nested.
In Twenty Seventeen, it is .entry-content .has-*
In Twenty Twenty it is :root .has-*

[poena]

By the way, since WordPress 6.5, WordPress outputs the registered colors as variables also for classic themes:

    --wp--preset--color--primary: #0073a8;
    --wp--preset--color--secondary: #005075;
    --wp--preset--color--dark-gray: #111;
    --wp--preset--color--light-gray: #767676;

How can we take advantage of that (with a fallback for older versions)?

[poena]

Also related to highlights ​Gutenberg: Default/core colors missing from 'Highlight' palette.

[sabernhardt]

How do we test "everything else" ?

Exactly. I asked the question because I do not know what else might become a problem. If only two items need to specify the element/block, the CSS would not look as clean as one selector, but two probably is not excessive:

mark.has-primary-color,
.wp-calendar-table.has-primary-color {
    color: #0073A8;
}

fallback for older versions

If colors are changed to custom properties in existing rulesets, fallback would be necessary (and that change might not be the best option). However, if the custom properties are only used to support colors in ways that have never worked with the theme, making those work in the latest version of WordPress would be a success.

[poena]

There is also the general issue with these selectors, for the front they are limited to the entry content so they do not work for widget areas.
Perhaps we need to rework these selectors completely but set up some visual regression testing tools to help with the testing.

[SirLouen]

Combined Bug Reproduction And Patch Test Report

Description

🟠 This report can't fully validate that the issue can be reproduced, but can validate that the patch fully solves the problem reported.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 136.0.0.0
• OS: Windows 10/11
• Theme: Twenty Nineteen 3.1
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0
  • WordPress Importer 0.8.4

Bug Reproduction Steps

1. Using the basic instructions provided by poena to reproduce this issue.
2. The only difference is that, when clicking More Options, there is a new option called "Highlight"
3. 🐞 If I highlight with blue or gray, I can't seem to see a difference, these are the main colours.
4. ❌ If I highlight with a clear different colour like a custom colour or a white colour, the difference is there.

Screencast attached to showcase these two scenarios.

Actual Results with patch

1. ✅ Issue is completely resolved with the patch

Screencast attached to showcase resolution

Additional Notes

• Judging by the @poena latest reproduction steps, it appears that some update has come from upstream with the Highlight menu, but still doesn't fully solve the problem (and also judging by the GB40279 report it seems there could be some causation upstream).
• As pointed out by @smit08 this only happens with main colours.
• From a code review, white is the only colour, that doesn't seem to need additional CSS rules, only the 3 primary colours (the two blues and the grey) seem to be affected.

Maybe this needs to further be checked upstream, setting a close candidate for reported-upstream, if a new ticket happens to pop in GB repo regarding this topic.

Supplemental Artifacts

🟠 Without patch sample screencast: ​https://f003.backblazeb2.com/file/wordpress-videos/wp-videos/2025/05/49787.1.mp4
✅ With patch screencast: ​https://f003.backblazeb2.com/file/wordpress-videos/wp-videos/2025/05/49787.2.mp4

[karmatosed]

@SirLouen I am reluctant to just close this considering the work that both @poena and @sabernhardt have put in so for now removing that issue. We should only recommend this if a state is the case that it is fixed and it has been reported fully upstream which unless I am mistaken is not the case.

Let's get a check-in with everyone and see what is going on first and then we can update. My feeling is if everyone agrees we are good but until the closing feels premature at least on this. Also flagging upstream is one thing, it would be good to also get reporting that. Close and reported-upstream are different states so whichever it needs to be should be followed through. A partial report isn't a full one though and I would like that ticket made for a full one before closing here.