jeichorn
Forum Replies Created
-
This has happened on 2 of our sites as well. It looks like its a widespread problem. I’m seeing it on php 5.5 sites:
[22-Jan-2017 01:17:21 UTC] PHP Fatal error: Class ‘WPSS_Utils’ not found in /dom18874/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 7323
The bug is pretty obvious reading the code.
wp-spamshield.php line 48 you call:
rs_wpss_getenvwhich calls WP_SpamShield::sanitize_ip on line 217
In any case where sanitize_ip has a problem, you attempt to log that data but the util class hasn’t been required yet.
My suggestion would be to pull the include block on line 138 up above the first function call. Its super easy to hit this problem otherwise.
Forum: Plugins
In reply to: [EWWW Image Optimizer] Slow queries against wp_ewwwio_imagesThanks, I will send some patches your way once they are written. Right now we are just testing with a couple customers so the warnings in the UI aren’t a problem.
-josh
Forum: Plugins
In reply to: [EWWW Image Optimizer] Slow queries against wp_ewwwio_imagesThank should work, thank you.
Btw we are looking at making ewww available to all pagely customers. It would be in a batch mode only operation since we don’t allow exec to run (there would be a cron running the wp-cli batch processor for each site).
Would you be interested in a set of patches to have a new define driven mode for enabling this (removing the exec warning etc, giving a message about images being optimized hourly). Or should we just fork the UI (this may be better since we likely would want to prevent editing of some options) while reusing the code that does the conversions. If we fork thinks we would still give you credit of course.
-josh
Forum: Plugins
In reply to: [EWWW Image Optimizer] Slow queries against wp_ewwwio_imagesThe docs on varbinary say you can size it up to 64k. Keeping at as small as possible is best, maybe 2048 or 4096
-josh
Forum: Plugins
In reply to: [EWWW Image Optimizer] Slow queries against wp_ewwwio_imagesSorry about this, I didn’t fully investigate the problem. We are still seeing the full table scan even with the index because you are using the binary keyword in the query.
There are 2 options to fix this.
Switch the field type of path to varbinary(1024) (I think paths longer than that will break anyway) or to blob. Note that mysql 5.0.3+ supports varbinary > 255, given your query pattern varbinary should be better performance but i’m not sure that matters since the switching to using an index makes everything as fast as you can easily measure.
In either case you can then drop the BINARY keyword from the query since its inherit in the field type, this lets you use the index. On my test case that drops the query time for .24 sec to 0.00 sec 🙂
-josh