Varia Themes: Cover block - text changes color upon editing anything on the same page

[goblinartificer]

Quick summary

Multiple users have reported that on live sites using the Cover block, the text has previously been white, and has since changed to grey or black (an unreadable color) after another unrelated element is edited.

• No change in the HTML of the block in Gutenberg seems to exist.
• The block looks the same with white text in the editor, it's the live view that has a different color.
• In the CSS, the only thing that is different is that the has-background-dim class is moved down one level from .wp-block-cover to .wp-block-cover__gradient-background. It seems like color: var(--wp--preset--color--background); is set for both, though, so I have no idea what's happening there. All blocks inside still use inherit to get text color.

Steps to reproduce

1. On a site with existing Cover block templates with text in them (I used the Maywood default homepage in my test), activate Hever.
2. Make any change at all to anything on the page with the cover blocks in the editor.

What you expected to happen

The text should stay white, as it does in the editor.

What actually happened

The text goes dark grey or black and is unreadable on a dark-overlay image.

Context

Most recently, 33065416-hc (AT) Also in 28882174-hc (Simple). Test site is available at hgshdfhasdfwerfas.wordpress.co ⁠— all I did to get that color change to trigger was change the Welcome to Maywood H3 to a H4.

Simple, Atomic or both?

Simple, Atomic

Theme-specific issue?

Both these sites are on Hever, but it might be broader than that! I haven't tested other themes.

Browser, operating system and other notes

No response

Reproducibility

Consistent

Severity

Some (< 50%)

Available workarounds?

Yes, easy to implement

Workaround details

Manually setting text color works, but it's not an easy alternative for sites with lots of cover images.

[retnonindya]

This happens on the wpcourses.com website too. Editing any elements but Cover block on the page causes the text color on the Cover block to change too.

Site: Atomic
Theme: Stratford (I think this happens on Varia child themes?)

[formosattic]

For reference, a few other bugs related to Cover Block and color being off:

• Cover Block Overlay – Color no longer applied when adding / editing Cover blocks wp-calypso#57711
• Bradford: Cover block displaying black background #5011
• Varia Themes: Doesn't Adjust Color Based on Cover block Background #5051
• Barnsbury: Cover block color overwritten when it matches custom color used in theme palette  #4055
• Dalston: Cover Block Color Overlay Working Unexpectedly #5287
• Spearhead: Dark mode. Editor palette colors shows the wrong colors. #3410
• Cover Block has a dark overlay despite selecting white overlay color in the block settings #4639
• Varia: Text color on "Image showcase portfolio layout" pre-defined layout doesn't match editor #4189
• Image Block: Text Over Image feature behaves unexpectedly (the opacity on the Cover block bumped to 100%) wp-calypso#57884
• Varia themes: Default text Color inside the Cover Block is not the same in the editor and the front-end #4993
• Varia Themes: Cover block - text changes color upon editing anything on the same page #5181

[Robertght]

Hey!

I tried to replicate this using Hever, Maywood and Geologist on my end, but I had no luck.

Could you give it a second shot and if it still happens could you share a screen capture?

[chad1008]

I'm able to reproduce in Hever:

1. Create a new post.
2. Add a cover block using an image from media library.
3. Note the placeholder text color - it was a light grey in my test, almost white.
4. Add some text to the cover block and note the color - it was white in my test.
5. Publish the post and view your block on the front end, noting the color - it was black in my test.

I was also able to reproduce this locally with Hever (downloaded from WPcom) activated, so this isn't WPcom specific. In this case I created the cover block on a default theme (Twenty Twenty if I recall correctly) which worked fine. I then edited the same post, added a paragraph block, and updated. This caused the color on the front end to change from white (matching the editor) to dark grey/black.

I was also able to reproduce on another Varia child (Stratford). I was not able to reproduce when testing on some non-Varia child themes, so that may be worth investigating as others have noted.

So, TLDR of my testing:

• On Varia children the cover block placeholder and text will appear light/white in the editor, but dark/black/grey on the front end. Editing a page with an existing cover block will cause the front end color to change to dark/black/grey.
• One other themes (specifically Blockbase children I've tested) use dark font in both the editor and on the front end, so it may be that the lighter in-editor coloring is connected to the source of this issue. That seems to be the part that's different across the board.

[Robertght]

Thank you for testing this @chad1008 !

After a few runs on my end as well, this appears to be theme-specific(especially Varia based).

@jeffikus should we add this to the theme's repo?

[upwardmomentum84]

This also happened on an AT site running the theme Appetite in 33137529-hc.

[jordesign]

Doing some further testing on this - and shifting over to the themes repo as this seems related to Varia themes handling of colors in Cover blocks

[jordesign]

This issue is sounding really similar to #4993 - which is caused by the default text color for elements within Cover Blocks not matching within the editor and the front-end. It is as though the default text color for all blocks is changed to dark grrey.

In that issue the problem is seen when first editing content in pages (compared to updating pages in this issue). In these cases my hypothesis is that the blocks were using the default color already.

I suspect the same issue is at play - something about updating the page updateds the html/css definitions so the default color changes.

[eduardozulian]

Also reported in 4687419-zen

@jordesign It seems like we're getting several issues that overlap so I'd like to understand if setting a high priority here would make sense. :)

[formosattic]

Other reports from Automattic/wp-calypso#60272:

• 4702178-zd-woothemes
• 33772054-hc 4706374-zen

[Robertght]

I'd like to point out that in the above case the fonts were not applied either.

[csabarakasz]

I wanted to leave a comment here that this 4706374-zd-woothemes ticket was most likely not a bug, but a custom CSS that was added by the user and we didn't know about it, until now.