Repository navigation
Gallery block: "Fill" crop broken in editor canvas since WP 7.1 - images get baseline style="height: auto" overriding .is-cropped height #82252
Description
Description
Since WP 7.1, Gallery blocks with "Crop images to fit" (imageCrop: true) no longer crop images to a uniform row height in the editor canvas - some images stay at their native height and leave a gap (see screenshots). The saved content and published page are unaffected; this only happens in the editor canvas.
Cause: every image in the gallery now gets an inline style="height: auto" in the canvas, which beats the block library's own .is-cropped img { height: 100% } rule.
Step-by-step reproduction instructions
- Insert a Gallery block with "Crop images to fit" enabled, using a few images with different aspect ratios.
- Look at the row in the editor canvas.
Screenshots, screen recording, code snippet
Before (WP 7.0.4):
After updating to WP 7.1:
Inspector, showing the injected style="height: auto":
Root cause: the saved block content has no width/height/style on its tags, and the live front-end renders correctly. Only the editor canvas adds an inline style="height: auto". This looks like a side effect of the new Responsive style states for blocks feature in 7.1 (https://make.wordpress.org/core/2026/08/05/responsive-block-styles-and-configurable-viewports-in-wordpress-7-1/, #77817, #75707): the dev note says per-viewport overrides are marked !important so they can beat "the block's default inline styles" - implying core/image now always renders a baseline height: auto in the canvas for that mechanism to have something to override, whether or not that image actually has a responsive style set. That baseline is what clobbers the gallery's .is-cropped CSS.
Possibly related to the older #48762 / PR #44213 (same class of bug: image block's own default CSS beating explicit sizing).
Reproduced on two unrelated installs; on one of them we updated in place from 7.0.4 (working) to 7.1 (broken) with no other changes, which rules out plugins/theme.
Environment info
WP 7.1, bundled Gutenberg. Chrome, Windows 11 desktop. Two different custom hybrid themes - not theme-specific. Editor canvas only, saved content/front-end unaffected.
Please confirm that you have searched existing issues in the repo.
- Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
- Yes
Please confirm which theme type you used for testing.
- Block
- Classic
- Hybrid (e.g. classic with theme.json)
- Not sure
Activity
SainathPoojary commentedon Aug 31, 2026
Hey @Azragh, I gave this a try in WordPress Playground on WP 7.1 but wasn't able to replicate the broken crop behavior on my end.
I added a gallery block, toggled on "Crop images to fit", and made sure to use images with completely different aspect ratios. Everything still cropped uniformly in the editor canvas for me. I've attached a video of my test setup below.
Am I missing any crucial steps here to reproduce this?
Screen.Recording.2026-08-31.at.11.29.45.PM.1.mov
Azragh commentedon Sep 1, 2026
That is weird - just retested with all plugins deactivated and with WordPress's own Twenty Twenty-Five theme (no custom theme at all), and the crop is still broken in the editor canvas both times. Also tried a hard reload and a brand-new post with a fresh gallery block - same result every time - see video below.
One extra detail that might help: the row renders correctly for about half a second on load, then jumps to the uncropped state. That points to something running after the initial render that adds/re-applies the height: auto inline style, rather than it being there from the first paint.
Since Twenty Twenty-Five is a WordPress-bundled theme and this reproduces with every plugin off, this should rule out both a theme and a plugin cause? Happens with Gutenberg plugin activated too.
20260901-0619-12.0764168.mp4
Inline style on the image:
talldan commentedon Sep 1, 2026
I just noticed something similar happens when setting Link to Image File or Link to Attachment File on a landscape image in a gallery:
Compared to how it looks normally without that set:
Azragh commentedon Sep 1, 2026
@SainathPoojary I always set my image links to "file", this might be the missing step to reproduce.
talldan commentedon Sep 1, 2026
I think the regression is from #70575. It fixed a bug for standalone images, but it probably shouldn't apply when the image is in a gallery. 🤔
SainathPoojary commentedon Sep 1, 2026
Thanks for finding that missing step, @Azragh! I just tested this again, and setting the image link destination to "Attachment File" immediately triggers the broken cropping behavior in the editor canvas exactly as @talldan noted. I'm seeing the same
height: autoinline style overriding the crop.talldan commentedon Sep 1, 2026
I've started looking into a fix for this.
SainathPoojary commentedon Sep 1, 2026
@talldan I did a quick dive into this too and wanted to share my findings in case it helps!
The root cause seems to be the inline style logic in image.jsx injecting
style="height: auto"when the height is undefined (which is always true for gallery images). This inline style beats the gallery's.is-cropped img { height: 100% }CSS rule because inline styles have higher specificity.When an image is wrapped in a link, the tag gets the 100% height from the CSS, but the![]()
inside gets the height: auto inline style, which breaks the crop.