Problem
If you have been using video backgrounds inside the Cover block and the editor suddenly throws Error 153, you are not imagining it and you are not alone.
WordPress called this out directly in the May 2026 developer roundup: a fix is now merged for the embed video background Error 153 in the editor. That sounds like a small patch note, but this one is disruptive because it hits a content editing flow that marketing teams tend to use on homepage hero sections, landing pages, and campaign blocks.
When this happens on a live client site, the problem is not just "the background video is broken." The bigger issue is that editors stop trusting the block. They duplicate sections, re-save broken markup, or switch to raw HTML workarounds that make the cleanup harder later.
If your team already ran into related editor-side rendering issues, my post on WordPress 6.9 Block Styles Broken Layout is worth keeping nearby. A lot of Gutenberg bugs look visual at first, but the expensive part is usually the content cleanup after the editor goes unstable.
Why It Happens
The recent WordPress note is short, but the bug pattern is familiar.
Cover blocks with video backgrounds sit at an awkward intersection of:
- block attributes stored in post content
- editor preview behavior
- embed provider handling
- background media rendering inside a complex layout block
That is a fragile path compared with a plain image background or a self-hosted video file.
In practice, I usually see three reasons this class of bug becomes messy:
1. The editor and frontend do not fail in the same way
Sometimes the frontend still renders something acceptable while the editor throws the error. That encourages teams to leave the broken block in place.
2. External embed behavior adds another variable
A video background sourced through an embed path is just harder to stabilize than a local media file that WordPress controls directly.
3. Editors try to repair the section manually
Once people start copying and pasting the block, toggling alignment, or converting it between variants, you can end up with several versions of effectively the same broken hero section.
The Fix
The first fix is the obvious one: update into a WordPress or Gutenberg build that includes the patch.
The second fix is the one I care about more on client sites: stop relying on the fragile path until you confirm the editor is stable in your exact stack.
My preferred fallback is a self-hosted background video in the Cover block instead of an embedded background. It gives you a cleaner media path and fewer moving parts in the editor.
This is the safer block structure I fall back to:
<!-- wp:cover {"url":"https://example.com/uploads/hero-loop.mp4","backgroundType":"video","dimRatio":50,"minHeight":560,"isDark":false} -->
<div class="wp-block-cover is-light" style="min-height:560px">
<video
class="wp-block-cover__video-background intrinsic-ignore"
autoplay
muted
loop
playsinline
src="https://example.com/uploads/hero-loop.mp4"
></video>
<span aria-hidden="true" class="wp-block-cover__background has-background-dim"></span>
<div class="wp-block-cover__inner-container">
<p>Your hero content here</p>
</div>
</div>
<!-- /wp:cover -->
That is not glamorous, but it is predictable.
If the section was originally built around an embedded provider and the editor is unstable, I do not keep patching the same block in place. I replace it with one of these options:
- a self-hosted MP4 or WebM background
- a static poster image plus a normal Video block below the fold
- a custom hero component outside Gutenberg if the section is business-critical
What I Audit Before I Call It Fixed
I do four checks after the update:
1. Open the post in the editor and duplicate the block
If duplication or selection still causes the editor to wobble, I do not trust the patch yet.
2. Re-save the post and compare rendered markup
I want to make sure the block serialization stays clean and the frontend output does not drift.
3. Test responsive previews
Cover blocks hide layout bugs until you switch viewport size. Background media issues often show up there first.
4. Check whether the block is truly still needed
A surprising number of hero video backgrounds should have been static imagery in the first place. If the section is decorative, simplifying it usually beats nursing a fragile embed setup forever.
The official source for the patch note is the May 2026 WordPress developer roundup. That is the right link to share with content teams because it confirms this was a real editor-side issue, not a one-off local glitch.
What I Would Not Do
I would not tell editors to keep retrying the same broken block and hope the save sticks.
I also would not rush into custom JavaScript hacks inside the editor unless the site absolutely depends on that exact background behavior. For most teams, the fastest stable fix is to update, test, and switch the media implementation if needed.
CTA
If your WordPress editor is breaking around high-visibility blocks, I can help clean up the content model and stabilize the site properly. See my services if you need hands-on WordPress and Gutenberg debugging.