Basically, after the bulk resize, in every <img…> tag the “src” attribute has changed to have the new size at the end of the image path like before it was xxx.jpg, it is now xxx-400×500.jpg. The images still have the correct names, but only the URLs have changed in articles and galleries etc.
Help please, I don’t want to restore the whole database.
Hmm, Imsanity doesn’t touch any src attributes. WordPress creates those alternate size images – but imsanity doesn’t touch them or rename anything.
Thanks, I have a feeling. After the bulk resizing, the preview images with the 1024 string disappeard:
Before: https://dl.dropbox.com/u/1188066/before.png
After: https://dl.dropbox.com/u/1188066/after.png
The max file size in the imsanity settings are all set to 1024: https://dl.dropbox.com/u/1188066/prefs.png
Could it be that there is a malfunction on deleting temp images in the resizing process?
So actually, the “src” tags haven’t been changed because they were like that before (database dump), and I initially installed Imsanity for the first time today.
So, it really is like I said: alle the wordpress generated images with “1024” in the filename have been removed from the server. Luckily, I made a backup and right now I am restoring those images, and as far as I can see, this makes the site working correctly again.
Hmm, well if you have an image that is 4000×4000 (for example) WordPress will create the alternate thumb, med and large size and appends the size to the filename – which is where you see those “1024” images. They are not considered a “post” on their own and they don’t get a unique record – so Imsanity never even sees that they exist.
If you upload an image that is lower than 1024, though, WordPress won’t bother to create the large size because it’s bigger than the original.
So, perhaps if you bulk resize images so they are lower than the threshold for WordPress “large” size – internally WordPress is doing something now, thinking that the large image size shouldn’t be there or something. I’ll have to test that. I haven’t seen it before, though.
Good forethought making a backup – I definitely recommend it before any bulk operation!
I just tested various cases and I can’t reproduce that problem. I’m pretty confident that Imsanity didn’t delete your images.
Imsanity doesn’t have a delete function, so it doesn’t make sense that images would get deleted. It also doesn’t have any awareness of the alternate sized images that WordPress creates so it wouldn’t make any sense that it was touching them at all.
I checked because I wanted to make sure there wasn’t some side-effect occurring in a WordPress library function after the images were resized, but I can’t get it to happen & I don’t see anywhere in WordPress that would happen either.
If you can figure out how to reproduce it consistently then I’m happy to look again, but so far it’s not looking like an issue with Imsanity
Hi Jason,
thank you for checking those things. I was able to reproduce this problem:
0. Disable Imsanity
1. Create a new article
2. Insert new image in full size (wordpress uploads the full-size image and creates 5 versions of it: xxx-120×80.jpg, 150×150.jpg, 160×120.jpg, 300×200.jpg, 1024×685.jpg) (https://dl.dropbox.com/u/1188066/step1.png)
2.1 Enable Imsanity
3. Temporarily disable the 250 image maximum in your plugin (ajax.php line 76)
4. Search for images in the bulk resize and only check the newly uploaded image (https://dl.dropbox.com/u/1188066/step2.png and https://dl.dropbox.com/u/1188066/step3.png )
5. Bulk resize this one
6. Check in /uploads and realize: the 1024×685 version of the image is gone. (https://dl.dropbox.com/u/1188066/step4.png)
Hm, although, the image is gone, WordPress now only references to the original image file name and thus the image is still being displayed. I upgraded to 3.5.1 last night and before the upgrade all images were referenced to the corresponding 1024 version (i checked this in the DB dump) and now they are referenced to the original image file name.
Thus, there was the problem with the old posts, but not with newly created ones, although the 1024-versions, WordPress still creates are still being deleted (you might check into this). But this only doesn’t come into play because WordPress now directly references on the original image file name.
Weird.
i really appreciate your help debugging. can you find anything as far as possibly another plugin or something that would be doing that? i’ve tested now your exact sequence as well as other sequences to see what’s happening but i still cannot get it to occur ever. i made a video of my testing, maybe you can tell me something going on with your setup that is different from mine?
I made this video of my testing process: http://youtu.be/SvGIvUEDB90
i tested on WordPress 3.5.1 as well as trunk version 3.6
I would at this point I would be tempted to say that there is some anomaly happening on your setup because I know Imsanity doesn’t have a delete feature – it doesn’t touch the alt image sized either. But if you are able to figure it out then I would definitely like to know – even if it is some obscure combination of factors.
Thanks again
Thank you for the video. I think that I will be able to respond tonight, so stay tuned 🙂
Has this issue been solved? I am currently experience the same problem.
