Cover block regression in WP 5.9

[stevesand]

Wow, this was not a smooth update, what happened here?
This update broke all my current 10+ websites.

5.9 breaks Gutenberg Cover blocks.

You have moved the class positions for dim blocks without a fallback or auto update solution.
Classes like: "has-background-dim-10" has jumped down a step in the hierarchy making previous blocks black instead of dim.

Headline color classes have also changed, breaking headline colors.

[glendaviesnz]

Thanks for reporting this @stevesand.

A migration was added to the Cover block code to automatically migrate the old block structure to the new structure in order to maintain the background dim setting, so not sure why that did not work in your situation.

I took the following block structure from a pre 5.9 site:

<!-- wp:cover {"url":"http://localhost:8889/wp-content/uploads/2022/01/tree1.jpeg","id":75, "dimRatio":40} -->
<div class="wp-block-cover has-background-dim-40 has-background-dim">
	<img class="wp-block-cover__image-background wp-image-75" alt="" src="http://localhost:8889/wp-content/uploads/2022/01/tree1.jpeg" data-object-fit="cover"/>
	<div class="wp-block-cover__inner-container">
		<!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"large"} -->
		<p class="has-text-align-center has-large-font-size">
			Guten Berg!
		</p>
		<!-- /wp:paragraph -->
	</div>
</div>
<!-- /wp:cover -->

and when pasted into a 5.9 site it converted it to the following structure:

<!-- wp:cover {"url":"http://localhost:8889/wp-content/uploads/2022/01/tree1.jpeg","id":75,"dimRatio":40} -->
<div class="wp-block-cover"><span aria-hidden="true" class="has-background-dim-40 wp-block-cover__gradient-background has-background-dim"></span><img class="wp-block-cover__image-background wp-image-75" alt="" src="http://localhost:8889/wp-content/uploads/2022/01/tree1.jpeg" data-object-fit="cover"/><div class="wp-block-cover__inner-container"><!-- wp:paragraph {"align":"center","placeholder":"Write title…","fontSize":"large"} -->
<p class="has-text-align-center has-large-font-size">
			Guten Berg!
		</p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

and the opacity displayed as expected in the editor and the frontend.

Do you have still have access to the block markup from one of your cover blocks prior to the 5.9 upgrade (the block markup as above can be accessed in the editor by clicking on the menu at the top left and selecting 'Code Editor')? There may be something different about the block structure in your case that hasn't been accounted for in the migrations.

Also, if you are able to provide details of which theme the site is using that may also help to track down the cause of the issue.

[stevesand]

Hi.
Have to give you cred for a really fast reply and suggestions. Thank you.

No for some reason the migration is not happening.

To solve it I ran a replace for all "wp-block-cover has-background-dim-40 has-background-dim" to replace it with only "wp-block-cover". The <span> is added but the classes from the root div are not removed. Making the divs super dark.

Many of the websites also runs Editorkit. Editorkit adds it own classes to wp-cover, can that have something to do with it? Are the blocks dependent on only having Gutenberg classes?

I discovered some more problems when restoring clients websites.
The border radius is gone from buttons, breaks previous buttons.
The class "is-light" is added cover blocks, making text dark, not sure where this class stems from.

[Clorith]

Hiya, and welcome to the WordPress Trac!

Is this only happening in the front-end of your site, or also on the editor?

What would be great to check is if you go to a page having this issue, edit that page (just open the editor), and save it again, you'll probably not have to make any edits before saving the page.
After doing that, is the styles applied as expected? (if you could test this on a site where a plugin isn't interacting with the core block, as you described some sites doing).

[glendaviesnz]

No for some reason the migration is not happening.

My apologies, as @Clorith mentions the migration only happens when you edit a post containing a Cover block.

But the styles were supposed to still be in place to maintain the background opacity for existing blocks without the need to edit them. I tried viewing an un-migrated block on 5.9 and it appears to work:

however - it is defaulting to 0.5 opacity instead of respecting the actual dim ratio that was set for some reason. Were your blocks still showing some opacity or was the opacity gone completely?

I will see if we can get a patch up to resolve this issue and to get the old blocks to respect the opacity that is set rather than defaulting back to 0.5.

To solve it I ran a replace for all "wp-block-cover has-background-dim-40 has-background-dim" to replace it with only "wp-block-cover". The <span> is added but the classes from the root div are not removed. Making the divs super dark.

With doing this you might find that you get an invalid block error when you try to edit those blocks in the editor. Another solution may be to add the following additional styles to the sites - ​https://gist.github.com/glendaviesnz/b3480d37ff0ea75103cea8ca5bd1796b

I discovered some more problems when restoring clients websites.
The border radius is gone from buttons, breaks previous buttons.

Are you able to add separate tickets for these ones please as it makes it easier to follow up then?

The class "is-light" is added cover blocks, making text dark, not sure where this class stems from.

The reasoning behind this change can be found here ​https://github.com/WordPress/gutenberg/pull/33541 - if that doesn't seem to make sense in your context, then go ahead and add a new ticket for this problem as well.

Thanks again for taking the time to report these problems.

[glendaviesnz]

Potential fix for this up at ​https://github.com/WordPress/gutenberg/pull/38362

[stevesand]

Hi!

What an amazing team you have. So many quick suggestions and solutions.

After restoring some more websites i can confirm:

In most cases: Resaving the page or post works. For us with many many sites, pages and posts, this has taken some time to go through.

In some cases, resaving does not work. Im guessing this is a conflict with either editorkit or WPML. I have not been able to pin point why it does not work for some sites.

I can also confirm that the intial issue is what @glendaviesnz suggested with a 0.5 default opacity. The covers looks normal in admin, but not on the front pages. They turn very dark with some opacity.

The new "is-light" class has lead to some problems with sites that were depending on the old behaviour with white text. But i guess that is another topic.

Thank you for all suggestions.

[glendaviesnz]

We have merged a ​fix for this into Gutenberg, which will hopefully be back-ported to WP 5.9.1.

In the meantime, rather than needing to manually edit exiting blocks to fix this, adding ​this custom css to a site should resolve the issue.

[Clorith]

Milestoning for 5.9.1 for visibility, so that it's included wit hthe update.

[webmandesign]

#55153 was marked as a duplicate.

[peterwilsoncc]

I've renamed this ticket for clarity.

This issue has been fixed in the Gutenberg repository (see the associated ​issue and ​pull request). The fix will be included in the Gutenberg package updates for WP 5.9.1, see #55163.

Given the issue has been fixed and is pending merge to WordPress, I'm going to close this as reported-upstream.