Do you manage your own mysql server? If so, I would look at the max_packet_size
That’s the only setting I can find which should restrict the query size.
Hey,
Yes we run our own servers, this particular one already has fairly high limits. On other sites the plugin optimizes 10k+ images without any issues and with even lower server limits. Nonetheless, I increased the max_allowed_packet to a 128M (which should be way more than needed) to see if it made a difference but still the same result. If we were hitting any limits, it should throw a PHP error anyways but there is nothing.
Any other ideas?
Thanks again for your support on this matter.
I’m not sure that PHP would throw an error for a mysql packet size problem, it usually only throws an error when the query syntax is bad. At any rate, 128M is definitely large enough. Can you look in your database to see if this option exists in the wp_options table: ewww_image_optimizer_aux_attachments
It does exist with an empty value and autoload ‘no’. Here is the exact export:
INSERT INTO wp_options (option_id, option_name, option_value, autoload) VALUES
(10270248, ‘ewww_image_optimizer_aux_attachments’, ”, ‘no’)
Well that’s as it should be, sort of. It SHOULD have something in it, but as we’ve already discovered, it isn’t saving somehow. The question is why? Is there another plugin that has capped the length of options values possibly? I’ve only ever seen this one time before, and then all of a sudden it started working when I was trying to debug the problem, so we never really figured out why it was doing it in the first place.
UPDATE: perhaps check to make sure the table isn’t in need of repair or something like that while I try to think of other possibilities.
Ok, I did a bit more debugging tonight, and found that it is the actual database update that fails inside of the call to update_option().
In looking through the list of files, there are several with odd (non-ASCII) characters. If the wp_options table has a utf8 (or similar) collation, that shouldn’t be a problem. But if the collation is not correct, I think that could be the cause of the update failing. Can you check to see what the collation is on your wp_options?
Nevermind, I remembered I had a way to check that, so I did, and it looks perfectly fine (same as my local db). However, in the debugging I’ve been doing, it’s been going into a file, and I had been dismissing a warning that came up every time I opened it with my text editor. Well, I finally took a look at it, and the warning says the file contains test that is not valid utf-8.
I think that can happen if the system encoding (at the server level) is not utf8. Regardless, the invalid characters are why the update fails, and thus the Scan & Optimize cannot continue. Without knowing the actual encoding of the system, it isn’t possible to convert it to utf8 reliably, but I tested it anyway, and when the filenames were all utf8 encoded, then it worked perfectly.
I checked the individual files in the log, and the encoding does not appear to be correct after a conversion (utf8_encode only converts from ISO-8859-1). However, running utf8_encode will at least allow the process to run, even if it will ultimately skip those files where the filename encoding is mismatched.
Awesome, great progress!
The system encoding is set to UTF8, so is the database, but the wp_options table is set to utf8mb4_unicode_ci. I assume that this should work just fine. However, it is possible that someone uploaded some images with special characters that the system doesn’t support – those would not work properly with the web server anyways so skipping them during optimization is quite all right.
It seems to work fine now. Is this a permanent fix now that you implemented?
At the moment, I’ve put it in for 2.9.6, hopefully it doesn’t cause more issues than it solves.
Awesome, thank you so much for your support.
Solved with 2.9.6. Keep up the good work!
