Cover Block Overlay – Color no longer applied when adding / editing Cover blocks

[hanananah]

Quick summary

According to the Cover Block support doc in the Overlay section, the overlay color should default to grey. When adding new Cover blocks or editing existing ones, the overlay color is removed/unset and needs to be manually selected to add/restore overlay feature.

Steps to reproduce

1. Open post editor (new or existing)
2. Add new Cover block

OR

1. Open post editor (new or existing)
2. Edit existing Cover block

What you expected to happen

Overlay settings should default to grey color.

OR

Overlay settings should still hold previously set color.

What actually happened

No overlay color is selected by default. Increasing / decreasing opacity setting affects cover block text, but not the image overlay.

Existing Cover blocks no longer hold previously set color, as color selected is somehow deselected.

Context

#4431371-zen

Operating System

No response

Browser

No response

Simple, Atomic or both?

Simple, Atomic

Theme-specific issue?

No response

Other notes

No response

Reproducibility

No response

Severity

No response

Available workarounds?

Yes, easy to implement

Workaround details

The Cover block overlay color can be reselected in the block settings.

[Robertght]

Thank you for flagging this @hgwaltney !

I think this was changed in a previous release of Gutenberg as I can't replicate it with 11.7.1, but I can't pinpoint when was this changed.

cc @Automattic/flow-patrol-create

I also asked here: p1636178892096800-slack-CBTN58FTJ

[sarahcada]

Adding another report at 4433797-zd-woothemes
For now the customer used the Overlay setting for each block in their newest post.

[filipanoscampos]

The user replied on this ticket: #4431371-zen
Unhappy with the suggested workaround. I tried to look for CSS to give a site-wide workaround but couldn't find any posts without the overlay.

I have asked the user to send an example and maybe we can look into a CSS workaround if the issue persists.

[benchilcote]

I responded as well to user in #4431371-zen. They have thousands of posts on their site, so this issue affects them in a substantial way.

Also - I did some of my own testing and was not able to reproduce the issue. I created a test post on an Atomic site, added a cover block with a color overlay, and with nested paragraph and heading blocks, then published it. After reloading the post on the front end and the post in the editor, the color overlay remained intact.

[AtrumGeost]

The user from 4431371-zd-woothemes shared a video and more details:

Video.mov

I just clicked a random one Godzilla v. kong in science fiction and in the editor the filter on the blocks is gone brighter and the text is black for some reason

Yet when I click on the review from the non-editor section how a reader would see it like the 2nd part of the video shows it shows like normal how it’s supposed to with the dark filter and white text

So the problem is in the editor it’s removing the dark filter itself and making the text black and this is only a change happening in the last few days not over years I’ve been using the site

[LauraSWP]

Another case here, text color could not be changed 28161311-hc
Had to use a custom CSS class and a tempo CSS fix.

[WunderBart]

Created an upstream issue: WordPress/gutenberg#36310

[donalirl]

Seen in #4440019-zen. The Cover blocks use the is-style-hover-reveal class on the Dalston theme. With the latest update, the overlay is faded grey by default. Before, the overlay appeared faded only on hover.

Before (normal behavior):

After (with the bug making it always appear faded):

[sajmes]

Another report here: 32646497-hc

Text color was also affected but using the highlight option in the block settings allowed us to set the text color properly.

[cometgrrl]

This issue is tracking an issue in another repository. All +1's of end-user reports should be done on this issue, while any discussion related to the issue itself and its fix should be done on the issue in the outside repository.

[paxblueribbon]

reported in zd-4439451

[AtrumGeost]

Got another report of a website with the Dalston theme having issues with the is-style-hover-reveal cover block style:

4441395-zd-woothemes

We have another issue possibly related:

p9cu9o-34L-p2

[cuemarie]

Another possible instance here: 30507333-hc

[bobmatyas]

Another report: 4441977-zen

[eduardozulian]

Another report: 32665748-hc

For my case, the following CSS helped me force a 0 opacity to the cover block image while changing it to .8 when we hover over:

.wp-block-cover.is-style-hover-reveal .wp-block-cover__gradient-background.has-background-dim {
  opacity: 0;
}

.wp-block-cover.is-style-hover-reveal:hover .wp-block-cover__gradient-background.has-background-dim {
  opacity: 0.8;
}

[bobmatyas]

Another report: p1636470933430900-slack-C03TY6J1A

[emilyaudela]

Many theme demos have also broken causing low color contrast, especially the contact sections. For example, in Maywood demo:

[JoshuaGoode]

Encountered on 4445479-zd-woothemes

Provided user with some CSS to get all of their cover blocks back to the default 0.5 opacity.

User will want an update when this is fixed and when they can remove the custom CSS.

[WunderBart]

Another report on #4447491-zen. I asked them to wait for the Gutenberg 11.9 release which should fix this per WordPress/gutenberg#36274.

This regression will actually be fixed via another PR: WordPress/gutenberg#36406. It will most probably be included in a v11.9.x patch release as the v11.9.0 has already been released. We're currently in the middle of the v11.9 upgrade in WPCOM, so please follow the tracking issue for more info. /cc @fullofcaffeine @chad1008 @glendaviesnz

The fix was included in the v11.9.1 patch release and it should be deployed to Simple and Atomic sites later today.

[Gustavo-Hilario]

Another report here: 4466102-zd-woothemes

[inaikem]

@WunderBart, would you be able to help us confirm if the fix was deployed as expected?

Taking 4449926-zd-woothemes as an example, I'm seeing the correct has-background-dim-XY set on their homepage cover blocks, however, the opacity is still set to 0.5 regardless of their editor settings:

• Cover block 1: Editor opacity at 70%
• Cover Block 2: Editor opacity at 30%
• Cover Block 3: Editor opacity at 20%
• Cover Block 4: Editor opacity at 60%
• Cover Block 5: Editor opacity at 30%
• Cover Block 6: Editor opacity at 32%

I should note that I'm unable to replicate this particular issue on a test site.

Thanks for your help!

@Automattic/bug-herders, I've added this to our bulk reply queue for us to deal with when we have a confirmed fix! 🙏

[essleeung]

Another case of Dalston blocks having the opacity set by default, instead of only on hover. 32849972-hc

Please contact the user when fix is complete. F/U ticket here: 4535296-zd-woothemes

[eduardozulian]

It appears that this issue is also affecting the Group Block.

• 32821733-hc.
• Theme: Twenty Twenty (something is forcing an !important in .has-primary-color.
• CSS workaround:

/* Cover Block: temp fix for 57711-wp-calypso-gh 32884974-hc (EZ) */
.wp-block-cover__inner-container .has-primary-color,
.wp-block-group__inner-container .has-primary-color {
  color: #000 !important;
}

[kathrynwp]

Ran into this in 30888354-hc

Showed how to use the Highlight tool to make the text on the cover block white that way.

[paxblueribbon]

Had something similar in 32927342-hc / 4548270-zd

They don't have the Cover Block at all though, they have the group block. Not sure if this is the same bug or not.

[eduardozulian]

@pbking as you mentioned in Automattic/themes#5011, do you believe that this issue is also part of a larger problem?

[freelylovinglife]

Another report 4549872- ZD

[stronenv]

The issue seems to be resolved for 4449926-zd-woothemes :

• Color changes are saved and displayed correctly on the page and in the Editor.
• Opacity changes are saved and displayed correctly on the page and in the Editor.

Unsure which release actually did the fixing since 4449926-zd-woothemes has been on hold for a while.

[TeniCola]

Another report in 30053228-hc -- white default text in the editor view, but dark grey on live site, which made it illegible against the background.

I advised the user that the workaround solution was to manually apply the text color to their blocks inside the Cover block.

[jordesign]

Another interaction from #4448278-zd

[WunderBart]

@WunderBart, would you be able to help us confirm if the fix was deployed as expected?

Taking 4449926-zd-woothemes as an example, I'm seeing the correct has-background-dim-XY set on their homepage cover blocks, however, the opacity is still set to 0.5 regardless of their editor settings:

• Cover block 1: Editor opacity at 70%
• Cover Block 2: Editor opacity at 30%
• Cover Block 3: Editor opacity at 20%
• Cover Block 4: Editor opacity at 60%
• Cover Block 5: Editor opacity at 30%
• Cover Block 6: Editor opacity at 32%

I should note that I'm unable to replicate this particular issue on a test site.

Thanks for your help!

@Automattic/bug-herders, I've added this to our bulk reply queue for us to deal with when we have a confirmed fix! 🙏

Sorry for the late reply, totally missed your ping, @inaikem! 🙈 AFAIK, the fix has been deployed as expected. Although, since the markup of the Cover block has changed, similar issue(s) might be appearing for some themes that provide customized styles for the Cover block. Would you be able to verify if the reporting user uses a specific theme that it might be related to? /cc @chad1008

[carladoria]

Another report in 4638455-zen

[essleeung]

Another report here: 4722065-zd-woothemes
I wasn't able to replicate this on my test site. The user adds a cover block and it looks fine in the preview, but the live site shows opacity as 0.5-1.0 and you can't see the image underneath the overlay.

Expected	Actual

[glendaviesnz]

@essleeung I wasn't able to replicate this either. Is the issue visible on a public page on the users site?

[essleeung]

@glendaviesnz They had it set in their drafts for us to test and didn't want it on their live site.

[sguzovskaia]

User affected by the issue reported that the temporal CSS fix they were given is not working anymore.
hc-32839164/zen-4440019
Follow-up ticket zen-4821687

[janmckell]

Another user affected by this: 4895541-zen

Gave CSS code for a temp fix:
.wp-block-cover.is-style-hover-reveal .has-background-dim {
opacity: 0;
transition: .3s;
}

.wp-block-cover.is-style-hover-reveal:hover .has-background-dim {
opacity: 0.6;
}

[ClassicRKR27]

I've got another instance here: 34895673-hc

[Robertght]

I have tested this with several themes, older and newer and I can't replicate this anymore.

I'm closing this for now as per p1653547485419459-slack-C01UW7SB411, but please reopen if you encounter other cases.

cc @Automattic/dotcom-pa-group