![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 15 years ago
Last modified 4 months ago
#18275 new defect (bug)
Can't get perfect thumbnail sizes with image editor
| Reported by: | smerriman | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Media | Version: | 3.2.1 |
| Severity: | normal | Keywords: | needs-patch dev-feedback close has-screenshots |
| Cc: | Focuses: | ui, administration |
Description
In the media settings, I have the thumbnail set to a fixed size (218x145), and set to crop to these exact dimensions.
Sometimes the automatic thumbnail crops off people's heads, etc, so I use the Image Editor to manually adjust the thumbnail. I select a rectangle, set the aspect ratio to 218x145, click crop, apply to thumbnail only, and save.
However, sometimes that results in an image slightly off in dimensions - for example, 215x145.
I expect this is a rounding error. However, it happens even if I select an area much bigger than this when cropping in the Image Editor - eg 300x200. After I click crop and see the 300x200 image, I would expect the thumbnail to be automatically be created at 218x145 like it does normally based on this adjusted image - however, it appears the checkbox for using exact dimensions doesn't apply here. (In fact, if I select, say 300x300, it will make my thumbnail 145x145).
This feels like a bug to me, and makes it very hard to generate thumbnails at the size I want.
Change History (10)
#2
@
12 years ago
- Keywords needs-patch added
I have confirmed that when cropping in the image editor that the Setting > Media > Crop thumbnail to exact dimensions setting is not honored when cropping images via the image editor. I am not sure why $nocrop is being set to true, but if I was to guess, it is to give make sure that the user's crop size based on the selection in the image editor is honored. While more work to design/build, I wonder if it would be better if the image editor's UX communicated and respected the setting when cropping just the thumbnail.
Either way, I think it would be nice to fix this.
This ticket was mentioned in Slack in #core-media by presskopp. View the logs.
9 years ago
#9
@
5 months ago
Reproduction Report
Environment
- WordPress: 7.0-beta1-61709-src
- PHP: 8.2.29
- Server: nginx/1.29.5
- Database: MySQL 8.4.8
- Browser: Firefox
- OS: Ubuntu
- Theme: Twenty Twenty-Five (twentytwentyfive)
- MU Plugins: None
- Plugins: None (first test), Classic Editor 1.6.7 (second test)
Steps taken
- Uploaded an image to the Media Library (original size: 2400 × 1350).
- Navigated to Media → Selected the image → Clicked "Edit Image".
- Performed a manual random crop using the crop tool.
- Clicked "Apply Crop" and then "Save Edits".
- Returned to the Media Library (Grid View) to observe the thumbnail preview and image behavior.
- Repeated the exact same steps after activating the Classic Editor plugin.
Result: ❌ Bug is not occurring
Expected behavior
- After cropping and saving edits, the Media Library thumbnail and edited image should reflect the crop correctly without visual issues or incorrect preview behavior as described in the ticket.
Additional Notes
- Tested first in a clean environment with no plugins active.
- Environment was reset and the test was repeated with Classic Editor plugin active.
- Behavior remained consistent in both scenarios with no reproduction of the reported issue.
Screenshots/Screencast with results
#10
@
4 months ago
- Keywords dev-feedback close has-screenshots added; needs-testing removed
Removing needs-testing as the bug does not reproduce in WordPress 7.0-beta1-61709-src. Adding close - the issue appears resolved in a previous release. The crop logic referenced in the original report is no longer producing incorrect dimensions.
Update: this appears to be caused by line 615 of wp-admin/includes/image-edit.php:
} elseif ( 'thumbnail' == $target ) { $sizes = array( 'thumbnail' ); $success = $delete = $nocrop = true; }I don't know why $nocrop is set to true, but I can't see any reason for doing so, and removing it fixes the problem.