Bulk Optimizer Failure
There are several things that can go wrong when you are trying to optimize all your images. Some are easy fixes, others are more challenging, but here are some things you can do to resolve common issues.
Scan did not complete, will try again
The most important thing to pay attention to here is how long it takes for this message to appear. You should normally see the number of remaining images decrease every 20-25 seconds. However, if this error appears rather quickly, say in 1-5 seconds, then it could be an issue with the server running out of memory. While the plugin has a lot of built-in safeguards, it can still use a lot of memory on large sites with lots of images. So the first thing to try is to increase the value of the "memory_limit" for PHP. Some webhosts let you change this in cPanel, and some don't let you change it at all. In some setups, you can increase the amount of memory from your wp-config.php file, detailed at wordpress.org. If you get completely stuck, your webhost is the best place to go for information on this, as they are the ones who control the memory limits. That is, of course, unless you run your own server, but then you should know how to change this already :)
The other possibility, although quite rare, is that the plugin is encountering a fatal error in some operation. The best way to pinpoint such a problem is to check the server error logs. Some webhosts (like the amazing WP Engine), let you see the error logs right from your control panel. Some will have the error log feature turned on in cPanel, but not actually use it. If all else fails, ask your webhost to check the error logs for your site. Without information from the error logs, an error of this sort is really tricky to pin down, but not impossible. Skip down to the section on debugging (I promise, its really not that complicated).
The scanner is too slow!
The Bulk Scanner has two different methods for checking if an image has been optimized previously. The first, default, method loads the entire image optimization history into memory. This is usually faster, but as the history grows, it can become less efficient. The second method is simpler, and checks each image directly against the optimization history in the MySQL database.
EWWW IO will adapt to your site and choose the best scanning method in most cases, but if you would like to force the plugin to use the second method, you may do so by defining a constant in your wp-config.php file:
define( 'EWWW_IMAGE_OPTIMIZER_SCAN_MODE_B', true );
Perhaps you've seen it, that dreaded message "Temporary failure, seconds to retry..." There are a number of reasons this might happen: connection failure, using high compression with large images, running JPG to PNG conversion or PNG to JPG conversion, and others.
When you see a temporary failure, the plugin will attempt to take "evasive" actions. In other words, it will adjust your settings to avoid failure. Just as there are multiple reasons for failure, the plugin will attempt various actions until it runs out of choices. If, somehow, it is unable to avoid failure and you finally get an "Operation Interrupted" message, here are some of those reasons, and some things you can try manually:
- If you are using JPG to PNG or PNG to JPG compression, try turning it off.
- If you have Optipng set to a level above 2 or PNGOUT set to a compression level below 2, try setting them back to level 2.
- If you have PNGOUT enabled, disable it.
- If you have large JPG images, and are using Max Lossy compression, try normal Lossy. If that fails, try dropping down to Maximum Lossless.
- If you have large PNG images, try decreasing the PNG compression level, if that doesn't work...
- If you have large PNG images, and #5 didn't work, tell the plugin to skip large PNG images using an override (see the EWWW_IMAGE_OPTIMIZER_SKIP_PNG_SIZE).
Sometimes image optimization will also fail because your server is not giving the plugin enough time or resources to complete an image. Similar to the section about the scan failures, you can sometimes override the memory limit with your wp-config.php file. If that doesn't work, contact your webhost to increase the memory_limit setting.
Similarly, the max_execution_time within PHP can be problematic. If you can increase this via your webhost's control panel, try bumping it up to 300 seconds or so. If your webhost doesn't allow you to override it directly, ask them if it is something they can increase max_execution_time for your site temporarily. Even with the max_execution_time increased, some hosts have "intermediate" servers running Nginx that sit "in front" of your actual web server and can cause timeouts as well. These "intermediate" servers will often have a hard limit of 30 or 60 seconds, and services like Cloudflare will have a similar effect. If increasing the max_execution_time does not seem to help, try some of the above counter-measures to see if that helps.
On every site, the database server is set to limit the maximum allowed packet/query size. The default is generally around 16MB (megabytes), which is plenty, but if it's set too low AND you have a lot of images, the bulk scanner won't be able to properly process/scan the media library. Look for the max_allowed_packet setting in your MySQL/MariaDB configuration and increase it to 16MB or higher:
max_allowed_packet = 16M
Depending on the server, that setting could be in a couple different locations. Older systems will find it at /etc/mysql/my.cnf, while newer (mariadb) systems will have it located somewhere like /etc/mysql/mariadb.conf.d/50-server.cnf
Make sure to restart the MySQL/MariaDB/Percona service after making the change:
service mysql restart
Received an invalid response...
Usually, this really means, received an empty response, but it is possible that some plugin on your site is displaying errors or output in places it should not be. The best way to see that is using the method described in this video:
In short, use Firefox, right click anywhere on the page and hit Inspect (or press Ctrl+Shift+I), and use the Console tab to inspect the AJAX responses to see what is coming back. If you can't make anything of what is output, send it to us via the contact form. For bonus points, take a screenshot or screencast and send that along with your support request.
If the response is empty, it can be the result of leaving the scan page while scheduled optimization is enabled. The bulk and scheduled processes use the same queue, so sometimes the scheduled optimizer will complete the queue while the bulk page is waiting for you to continue the process. In other cases, it is a limit on the length of MySQL queries that can prevent the plugin from properly storing the list of attachments that need to be optimized. Try increasing the query limits, or ask your webhost if they have a limit in place that would cause issues with long lists of attachment IDs. For example, if you have 20,000 images in your media library, the plugin needs to be able to store the entire list of 20,000 attachment ID numbers. Without that, it will be unable to track the progress of the bulk operation.
If all else fails, use the built-in help function on the bulk page, or the contact form below, and we will see what can be done to solve the problem in your situation.