-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Original file is deleted when cropping an image not yet cropped by WP #95
Comments
@kurtrank thank you for reporting this. I will have a look into it in the next days. |
Hi @kurtrank, I tested with the following setup:
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:
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 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
crop-thumbnails/functions/save.php
Line 92 in e9e5556
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
The text was updated successfully, but these errors were encountered: