Hmm, can you look at these attachment ID’s and see what particular images are having trouble:
1753 1752 1751 1750 1749 1748 1747 1746 1745 1744 1743 1742 1741 1740 1739 1738
If you have access to something like phpmyadmin or another way to look at your database, please check the wp_postmeta table in your WP database to see if there is anything stored for those attachments also. You’ll be able to see if there are other images missing metadata too.
If you can’t access your database or don’t know how, there is a line that looks like this in the plugin code that is disabled:
// print_r ($meta);
It is on line 2552 in the ewww_image_optimizer_custom_column function.
If you remove the two slashes at the beginning and save the file, then visit the Media Library, it will output the raw metadata for every attachment in the last column (it won’t look pretty, but it will show us what is stored in the database). Again, find the attachments listed above, and see if there is anything at all displayed for metadata.
When you are done, you can put the slashes back in to disable that line again.
Generally, those are attachments where something went wrong during upload, as the metadata is one of the last things generated after uploading a file. If there is no metadata, the file can’t be optimized properly.
all the row’s are filled with info, metadata has been read on all the files since another plug-in is showing the iptc keywords. those keywords where entered into the database during upload. (webpage for ID 1747 http://www.watersportspics.com/photograph/2013-ejkc/ejkceuropean-junior-kite-championship-2013-317/ )
only difference in the table is that 338 rows have width & height info while the other haven’t.
The attachment ID’s mentioned have width & height info in them. only the row’s aren’t always starting with this info
after more research (coding a dimensions row into the media library page) you are right
All the other files are missing the dimension info.
This really is bad news for me, don’t want to reupload 900 images again.
thanks for the advice.
Now time to see if there is a way to recreate the metadata on the already uploaded images.
I think there is a plugin that regenerates thumbnails, that might do the trick.
Also thinking I may want to revamp things a little bit there. When I originally forked the code, it relied solely on the metadata for getting the filename of the image. SO, if there was no ‘file’ field in the metadata, there was nothing to be done and it would stop processing the attachment as soon as that field was detected to be empty.
However, the plugin now is a bit smarter about finding the filename (uses the built-in wordpress function), and I may be able to revise that portion of the code a bit so it doesn’t die when the ‘file’ field is missing.
Esmi & nosilver4u, the regenerate thumbnails plugin is doing it’s trick. Did a test run on 20 images and they can now be optimized by the ewww-image-optimizer.
Would be great if the plug-in can act on the filename and go on from there with the processing
I’m assuming when you viewed the attachments (the ones with the odd metadata) in the media library that you did not see any messages like ‘Could not retrieve file path’? Looks like I had already updated that section of the code to ignore a missing ‘file’ field if it could retrieve the file path via the wordpress function.
Can you confirm that?
I can confirm this
Media library didn’t give any errors on the attachments with odd metadata
