Title: bulk optimizer stops Last modified: August 21, 2016 --- # bulk optimizer stops * Resolved [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/) * Hi, * Let me tell first that i love the idea behind this plug-in. installed it today and tried to run several images trough it. At first it was working awesome, but after i started a bulk optimize on my complete media library it stopped reported which images where worked on: the screen was showing the following: * Optimized image: Full size – * Plug-in status: * jpegtran: OK version: Independent JPEG Group’s JPEGTRAN, version 9 13-Jan-2013 optipng: OK version: OptiPNG version 0.7.4 gifsicle: OK version: LCDF Gifsicle 1.70 Graphics libraries – only need one, used for conversion, not optimization: GD: OK   Imagemagick ‘convert’: OK safe mode: Off  exec(): OK   Only need one of these: finfo: OK  getimagesize(): OK  mime_content_type(): OK * Added a pastebin with debug on from a batch of 20 images where a few where already processed [http://pastebin.com/6PNnrAsC](http://pastebin.com/6PNnrAsC) * [http://wordpress.org/plugins/ewww-image-optimizer/](http://wordpress.org/plugins/ewww-image-optimizer/) Viewing 10 replies - 1 through 10 (of 10 total) * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194920) * 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. * Thread Starter [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194922) * wrong info * Thread Starter [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194923) * 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/](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 * Thread Starter [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194931) * 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. * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194934) * I think there is a plugin that regenerates thumbnails, that might do the trick. * [esmi](https://wordpress.org/support/users/esmi/) * (@esmi) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194935) * [http://wordpress.org/extend/plugins/regenerate-thumbnails/](http://wordpress.org/extend/plugins/regenerate-thumbnails/)? * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194936) * 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. * Thread Starter [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194937) * 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 * Plugin Author [Shane Bishop](https://wordpress.org/support/users/nosilver4u/) * (@nosilver4u) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194939) * 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? * Thread Starter [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * (@kitesurfpics) * [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194947) * I can confirm this Media library didn’t give any errors on the attachments with odd metadata Viewing 10 replies - 1 through 10 (of 10 total) The topic ‘bulk optimizer stops’ is closed to new replies. * ![](https://ps.w.org/ewww-image-optimizer/assets/icon-256x256.png?rev=1582276) * [EWWW Image Optimizer](https://wordpress.org/plugins/ewww-image-optimizer/) * [Frequently Asked Questions](https://wordpress.org/plugins/ewww-image-optimizer/#faq) * [Support Threads](https://wordpress.org/support/plugin/ewww-image-optimizer/) * [Active Topics](https://wordpress.org/support/plugin/ewww-image-optimizer/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/ewww-image-optimizer/unresolved/) * [Reviews](https://wordpress.org/support/plugin/ewww-image-optimizer/reviews/) * 10 replies * 3 participants * Last reply from: [kitesurfpics](https://wordpress.org/support/users/kitesurfpics/) * Last activity: [12 years, 8 months ago](https://wordpress.org/support/topic/bulk-optimizer-stops/#post-4194947) * Status: resolved