Invalid link in wp_postmeta / Image file deleted

Thank you for this troubleshooting. I have had a few people reporting this issue but thus far I can’t get anybody who is able to help me reproduce it. I have spent hours trying to figure out any combination of steps to get this to happen on my setup! I am wondering if there is another image plugin that is “cleaning up” these images, and Imsanity is either being blamed, or is somehow a factor?

Imsanity doesn’t mess with the postmeta data because during the upload Imsanity is *supposed* to hook in immediately after the file upload, right before WordPress analyzes the file and creates all of the optimized media files. So, WordPress is really tricked into believing that you actually uploaded a small file. Thus *should be* no need to go messing with the optimized media or the meta-data.

However, with the bulk resize feature the images already exist along with their WordPress optimized files. In this case – Imsanity doesn’t mess with the postmeta because WordPress (in the past) has never bothered to delete any “uneeded” optimized media sizes. So, in that case you might wind up with a “Large” file that was bigger than the original after Imsanity does it’s work. But, WordPress doesn’t delete that image. At least, this is the case on my test installations – I can’t seem to get any other result.

I would definitely appreciate any info that you can give – you obviously know how to go into the database and look at data and compare it to the filesystems. That would be extremely helpful since you also seem to be able to be reproducing the issue on your end. Any help you can offer to get me reproducing this on my system would be greatly appreciated!

Hi Jason,

Thanks for your reply. It is very easy to reproduce this issue with a fresh WordPress 3.8 installation. All that is needed is the Imsanity plugin and a suitable image file. An image file of 1200 x 800 pixels will reproduce the issue with default settings of both WordPress and Imsanity.

1. Install WordPress 3.8. Setup database connection parameters to wp-config.php and run wp-admin/install.php. No other config is needed.

2. Media > Add new. Upload the image file with 1200 x 800 dimensions.

Table wp_postmeta now contains an entry with:

wp_attachment_metadata | a:5:{s:5:"width";i:1200;s:6:"height";i:800;s:4:"file";s:20:"2014/01/MK221684.jpg";s:5:"sizes";a:5:{s:9:"thumbnail";a:4:{s:4:"file";s:20:"MK221684-150x150.jpg";s:5:"width";i:150;s:6:"height";i:150;s:9:"mime-type";s:10:"image/jpeg";}s:6:"medium";a:4:{s:4:"file";s:20:"MK221684-300x200.jpg";s:5:"width";i:300;s:6:"height";i:200;s:9:"mime-type";s:10:"image/jpeg";}s:5:"large";a:4:{s:4:"file";s:21:"MK221684-1024x682.jpg";s:5:"width";i:1024;s:6:"height";i:682;s:9:"mime-type";s:10:"image/jpeg";}s:14:"post-thumbnail";a:4:{s:4:"file";s:20:"MK221684-672x372.jpg";s:5:"width";i:672;s:6:"height";i:372;s:9:"mime-type";s:10:"image/jpeg";}s:25:"twentyfourteen-full-width";a:4:{s:4:"file";s:21:"MK221684-1038x576.jpg";s:5:"width";i:1038;s:6:"height";i:576;s:9:"mime-type";s:10:"image/jpeg";}}s:10:"image_meta";a:10:{s:8:"aperture";d:5;s:6:"credit";s:0:"";s:6:"camera";s:22:"Canon EOS-1D Mark II N";s:7:"caption";s:0:"";s:17:"created_timestamp";i:1371812123;s:9:"copyright";s:0:"";s:12:"focal_length";s:3:"200";s:3:"iso";s:3:"500";s:13:"shutter_speed";s:6:"0.0008";s:5:"title";s:0:"";}}

Uploads directory should now contain the following files (see below), of which MK221684.JPG is the original full-size image with 1200 x 800 dimensions, size 480095 bytes.

141162 Jan  6 16:27 MK221684-1024x682.jpg
129805 Jan  6 16:27 MK221684-1038x576.jpg
22824 Jan  6 16:27 MK221684-150x150.jpg
31861 Jan  6 16:27 MK221684-300x200.jpg
70996 Jan  6 16:27 MK221684-672x372.jpg
480095 Jan  6 16:27 MK221684.jpg

All is fine now.

3. Install Imsanity. Use default settings, where 1024 x 1024 pixels is the crop limit for all use cases.

4. Run Bulk Resize Images.

The outcome is such that Uploads directory now contains the following files:

129805 Jan  6 16:27 MK221684-1038x576.jpg
22824 Jan  6 16:27 MK221684-150x150.jpg
31861 Jan  6 16:27 MK221684-300x200.jpg
70996 Jan  6 16:27 MK221684-672x372.jpg
141162 Jan  6 16:35 MK221684.jpg

What seems to have happened is that full-size version file MK221684.jpg got overwritten by MK221684-1024×682.jpg (probably by unlink($oldPath); rename($newPath, $oldPath); within ajax.php). No file with name MK221684-1024×682.jpg exists anymore.

Table wp_postmeta remains unchanged, and is still having a serialized entry for MK221684-1024×682.jpg, the related file of which is now missing.

Hope this helps!

ok, so it definitely is the bulk resize feature then and not happening for images uploaded while the plugin is active?

I’m positive that Imsanity is not copying the 1024×682.jpg because the plugin has no awareness of any of any of the optimized media. Imsanity is just scaling and replacing the original image file. Something is happening after that occurs which re-calculates the necessary optimized media. This all happens in side a core WordPress function “wp_get_image_editor”

I’m usually hesitant to place blame but I’m feeling suspicious that WordPress has a bug where it deletes optimized media files without updating the postmeta data. This wouldn’t be out of the question because there’s no way with the core functionality alone to alter an original image after it has already been uploaded and optimized media has been generated. So this is probably not something that is covered with a test in WordPress core.

I might be able to put in some type of patch that corrects this and fixes the postmeta, but I’m hesitant to do that unless there’s no other way. The reason is because surely at some point this will be handled (as it should) by WordPress core, and anything that I do is likely to just screw things up when some future update is released.

I’m going to do a little more research and then figure out how to deal with it – either deal with it in Imsanity or file a bug report with WordPress.

Thanks again so much for the help – this has been nagging me for a while.

Yes, I confirm that this seems to affect only bulk resizing. Sorry if I didn’t make it clear in the very beginning!

Thanks for your effort, it’s a very nice plugin. I get your point about not patching the issue.

ah, nevermind I discovered there is a bug with Imsanity, not WordPress. I’m working on a fix and will have it out soon.

It’s a situation that only occurs is a specific situation where the Imsanity setting is set to the exact same size as the WordPress “large” media size and you then run the bulk media process.

What is happening is that WordPress “generate_filename” is returning the same name as the existing large file when instead it’s supposed to be a unique filename. So it was very confusing because it seems like Imsanity is messing with the “large” image size, but in fact it is only being tricked into naming it’s temporary file the same as the existing file.

Ok, great. If you need someone to verify that the patch is working, I’ll be glad to help.

ok, i just released an updated version 2.2.5 – thanks a ton for helping me to finally locate this bug. if you have a minute to verify that it’s fixed on your server that would be awesome.

Ok, tested the same scenario with 2.2.5 and cannot reproduce the issue anymore. file-1024x682.jpg is not altered and only the full-size image is changed (now identical with file-1024x682.jpg).

Great, thanks a lot! Marking this thread as resolved now.

awesome – thanks again for you help, this has been eluding me for a while now.