On a WooCommerce store, the staff running it crop more images than anyone. Product photos arrive at odd sizes, banners get reframed, and until recently that meant fighting the tiny inline cropper or bouncing out to the Media Library. The WordPress media editor modal replaced that cropper, and since pull request #78653 merged, it’s the default image editing experience, with no experiment flag to turn on.
The call for testing on Make WordPress Core lays out the scope. The Crop button is still the entry point. The modal adds freeform and aspect-ratio cropping, flip, fine and snap rotation, and a Details tab with alt text, caption, author, and the post the image is attached to.
The cropping tools are straightforward. The Save button is where people will get confused, because the crop is block-level and a lot of users will assume it’s attachment-level.
The inline cropper versus the modal
The old tool was built on react-easy-crop and squeezed into the editor canvas and block toolbar, which is why it mostly did aspect-ratio crops with zoom and not much more. The core team’s writeup of the constraints says as much: the library had a narrow feature set, and the canvas and toolbar had no room for anything else.
The media editor first shipped as an experiment in the Gutenberg 23.1 release. It now runs on a set of core tools and components that will eventually move into a WordPress package, so the third-party dependency goes away. The post is open about why they built it in-house. Well-maintained open source croppers that cover most of what users expect are hard to find, an earlier attempt at a custom editor-first cropper was abandoned, and building once for many contexts made more sense than one-off flows per block. For plugin developers that means fewer vendored libraries inside editor internals, plus a shared surface meant to serve the Image block, other editor contexts, and eventually a rebuilt Media Library. The post includes a Playground link that loads trunk with the modal active, so trying it takes a couple of minutes.
What the WordPress media editor saves
In the comments, a tester asked whether the crop applies to WordPress’s registered image sizes. The post author said no. Like the old inline cropper, the modal changes the specific instance in the block. It doesn’t regenerate the thumbnail, medium, and large subsizes, and it doesn’t rewrite the attachment file.
The crop is applied to what’s displayed in the specific block context. In other words, it’s Block-level, not Attachment-level.
Attachment-level editing is left for a future Media Library context. On a store, that distinction tells you where to use the tool. Crop a product photo inside a blog post and the product gallery, the catalog grid, and every other block using that attachment stay as they were. Make the same fix in the classic Media Library image editor and it writes the file and regenerates subsizes, which is what you want when the canonical image itself is wrong. For bulk rebuilds there’s always WP-CLI:
wp media regenerate --image_size=woocommerce_thumbnailHere’s how I’d split it. Content sites and blogs can treat the modal as the whole toolbox, since most crops there are about framing in context. Stores where one image feeds the gallery, catalog, and category pages should keep canonical fixes in the Media Library, which still has a restore-original option this flow lacks, and use the modal for per-post framing. Either way, tell staff the difference before someone crops a product photo in a post and files a ticket because the catalog thumbnail didn’t change.
I do this kind of check for store owners before an update like this lands: see how your blocks, attachments, and any media offload plugins behave with the new flow, then write a short internal note on what to edit where.
Alt text, captions, and what syncs back
The Details tab edits the attachment’s alt text and caption directly, and the suggested testing steps show the sync rule. The block should pick up new values when its own alt or caption was empty or matched the original media values, and it should keep anything you typed into the block by hand. That’s two different behaviors on the same save, so the core team listed them as separate flows.
Run the second flow on staging with your real plugins active. Add an Image block, type a custom alt, open the modal, change the attachment’s alt, save, and check that the block kept yours. Anything hooking attachment metadata updates can change the result, and SEO and media plugins do that a lot. (I haven’t checked how this behaves with offloaded media on object storage, where subsizes regenerate differently, so test that if it applies to you.)
Rough edges and what’s out of scope
The feedback so far is minor. The zoom control showed unrounded floats, and one tester found the fine-rotation control changed values on hover alone.
The post also lists what’s deliberately out of scope for now:
- manual pixel crop controls
- restoring the original image
- undo and redo history improvements
- extensibility for image filters and AI options
The modal is meant to be the base for the Media Library rebuild, so whatever behavior gets settled now will carry into screens staff use every day. Keyboard and touch are on the testing list: tab through the crop area, handles, and toolbar, use arrow keys to move and resize, and check what Escape does with unsaved changes. If Escape throws away work without a prompt in your browser, report it on the tracking issue instead of working around it.
