Cover block: fix duotone when background is set to fixed

[matiasbenedetto]

What?

Fixes: #31662

Cover block: fix duotone when the background is set to fixed

Thanks, @ajlende for your guidance here!

Why?

Currently, the cover duotone breaks if the content is set to fixed

How?

I'm rendering a div inside the main container to render the background

Testing Instructions

1. Create a new post
2. Add a cover block
3. Add an image
4. Add duotone for the image
5. Select the fixed background option
6. Save and navigate the post

Screenshots or screencast

duotone2.mp4

[ajlende]

I'd suggest taking a look at the block deprecations documentation since we're updating the markup of the saved block

[matiasbenedetto]

I'd suggest taking a look at the block deprecations documentation since we're updating the markup of the saved block

thanks @ajlende ! I tested the code with the block created before adding these changes so I'm not sure if we need a deprecation or not. What do you think?

[ajlende]

I tested the code with the block created before adding these changes so I'm not sure if we need a deprecation or not. What do you think?

The general rule is that I had heard about adding block deprecations is to add one if the markup or attributes change from one block version to the next. I'd taken that at face value up until now and hadn't really questioned why, so I dug into the code a bit to get a better understanding of how deprecations work to see if I could create a test case that fails.

I managed to get it to break with this markup that I generated by following the testing instructions from #39145 and additionally including fixed+repeated backgrounds on the 6.0 beta.

<!-- wp:cover {"url":"https://cldup.com/Fz-ASbo2s3.jpg","hasParallax":true,"isRepeated":true,"dimRatio":50,"minHeightUnit":"em","isDark":false} -->
<div class="wp-block-cover is-light has-parallax is-repeated" style="background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)"><span aria-hidden="true" class="wp-block-cover__background has-background-dim"></span><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"></p>
<!-- /wp:paragraph --></div></div>
<!-- /wp:cover -->

As mentioned in the documentation, block deprecations don't work like database migrations by running one after another to upgrade a block to a newer version. It basically just checks the block attributes against older versions of the block to confirm if the output was valid at one point in history. Then, if it finds a match, it saves the new output instead.

If you don't have minHeightUnit without a minHeight attribute in your test, the block deprecation matches just fine on the v9 deprecation and you don't see any issues.

I found that the code for running the block deprecations isn't too bad to step through in a debugger. I'd recommend setting a conditional breakpoint for rawBlock.name === 'core/cover' in parseRawBlock and/or in applyBlockDeprecatedVersions and then pasting the above code into the code editor if you want to see how it all works yourself.

[matiasbenedetto]

Thanks, @ajlende very useful insight. I could reproduce the issue whit that markup and learned why that happen by inspecting the code you pointed out. I added a deprecation to handle the new markup.

[ajlende]

Could you add a couple fixtures for the new block deprecation? Details in the docs for how to do that.

[matiasbenedetto]

fixtures added! :)

[scruffian]

LGTM, you just need to rebase, and I'll merge!

[matiasbenedetto]

@scruffian @ajlende conflicts fixed :)

[youknowriad]

I added the dev note label because this one seems to change the markup of the cover block slightly (right?) just to tell theme authors about potential impact. If you think that's not needed, feel free to remove the label.