Closed kurtrank closed 17 hours ago
@kurtrank thank you for reporting this. I will have a look into it in the next days.
Hi @kurtrank, sorry but i cant confirm the bug you found.
I tested with the following setup:
add_action('after_setup_theme', function() {
add_image_size( '3_2_xlarge', 1602, 1068, true );
add_image_size( '3_2_large', 1026, 684, true );
add_image_size( '3_2_medium', 768, 512, true );
add_image_size( '3_2_small', 300, 200, true );
});
Can you please disable all other plugins and test again?
For your Question about the default Wordpress behavior: yes wordpress will only create image-sizes if the original file is larger or equal than the image-size.
Ah, thanks for your detailed response. I didn't see anyone else who had this issue on here or the wp org plugin support, so I kind of got the feeling it might not be a problem with the plugin itself but I am a little lost. Someone else on my team had tried with other plugins disabled and it was still happening but I can do my own full testing and make sure and try to figure out what is going on.
@vollyimnetz You were right, I did more testing with no plugins and had no issues. I discovered there is another plugin that for some reason on uploading a new item, creates an entry in the metadata in the db for every registered size even if the original image is not large enough to crop. It will just list the original image as the file, which is then marked for deletion as it doesn't match the new generated filename:
[3_2_medium] => Array
(
[file] => square-3-640x512.jpg
[width] => 640
[height] => 512
[mime-type] => image/jpeg
[filesize] => 115891
)
[3_2_large] => Array
(
[file] => square-3.jpg <------- original file
[width] => 640
[height] => 640
[mime] => image/jpeg
)
[3_2_xlarge] => Array
(
[file] => square-3.jpg <------- original file
[width] => 640
[height] => 640
[mime] => image/jpeg
)
I did not realize that by default WordPress will not create a metadata entry at all for a size if it's not large enough to crop (which makes sense). I am not sure why this other plugin does it this way. I'll have to re-evaluate if the other features of that plugin are worth keeping, but for now I will use the crop_thumbnails_should_delete_old_file
filter. There may be an easier way to check if it's an original file but this is what I came up with for now:
add_filter( 'crop_thumbnails_should_delete_old_file', 'my_crop_thumbnails_delete_check', 11, 4 );
function my_crop_thumbnails_delete_check( $should_delete, $image_details, $active_image_size, $current_file_path ) {
$matches = array();
$upload_path = preg_match( '/(uploads|files)\/(.*)\/(.*)/', $current_file_path, $matches );
if ( $matches[2] ) {
// path to existing file
$url = wp_get_upload_dir()['baseurl'] . '/' . $matches[2] . '/' . $image_details['file'];
// check if original file
$post_id = attachment_url_to_postid( $url );
}
if ( $post_id ) {
// we have an original file, skip deleting
$should_delete = false;
}
return $should_delete;
}
Seems to solve my problem. Sorry about the trouble!
I've gotten reports of some image files breaking, and in trying to reproduce their issue I found that cropping a size that WordPress has not created a separate file for seems to delete the original image. Note that this appears to only be an issue when uploading an image smaller than one of your defined sizes and then cropping one of those larger sizes. I think it doesn't really make sense to crop a larger size (as the "size too small for good crop quality!" warning indicates), but I think it's happening because people are grouping by ratio and cropping all at once.
Custom sizes defined:
When an image is uploaded I guess WordPress only creates separate image files if the image is large enough for each size. In my test I uploaded a 640x640 square image, so it created a new file for
3_2_small
and3_2_medium
but not the other two.When I crop one that doesn't exist (like
3_2_xlarge
) or group by same ratio and crop all 3_2, the debug says that it has deleted the originalsquare-3.jpg
.I guess this happens because: WP didn't create a separate file so it lists the original as the "file" for all of those sizes, and it looks like whatever is listed there is marked for deletion https://github.com/vollyimnetz/crop-thumbnails/blob/e9e55568ad31f7043173f4261f257c62036b5389/functions/save.php#L92
I am wondering if this is something that can be fixed, or if it's meant to work like this and I need to configure something differently about my custom image sizes? Maybe it should have a check to never delete the original, or only delete if
notYetCropped
is false.Full JS-Debug
Image attachment metadata from database