Delete original images get 500 internal server error

Please check your server error logs to find out what caused the 500 error (you might have to run it again to get some fresh data in the logs).
If you don’t have access to the logs, please check with your web host for that.

I’m getting this too.

wp-admin/error_log shows this:

23-Jan-2021 01:04:04 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function imsanity_get_option() in ROOT/wp-content/plugins/ewww-image-optimizer/common.php:7239
Stack trace:
#0 ROOT/wp-content/plugins/ewww-image-optimizer/aux-optimize.php(672): ewwwio_remove_original_image(20)
#1 ROOT/wp-includes/class-wp-hook.php(287): ewww_image_optimizer_ajax_delete_original('')
#2 ROOT/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters('', Array)
#3 ROOT/wp-includes/plugin.php(484): WP_Hook->do_action(Array)
#4 ROOT/wp-admin/admin-ajax.php(184): do_action('wp_ajax_bulk_au...')
#5 {main}
  thrown in ROOT/wp-content/plugins/ewww-image-optimizer/common.php on line 7239

Browser console shows this:

POST https://dev.get-business-online.com/ronitbaras/wp-admin/admin-ajax.php 500
send @ jquery.min.js?ver=3.5.1:2
ajax @ jquery.min.js?ver=3.5.1:2
S.<computed> @ jquery.min.js?ver=3.5.1:2
ewwwDeleteOriginalByID @ eio-tools.js?ver=600:306
(anonymous) @ eio-tools.js?ver=600:295
c @ jquery.min.js?ver=3.5.1:2
fireWith @ jquery.min.js?ver=3.5.1:2
l @ jquery.min.js?ver=3.5.1:2
(anonymous) @ jquery.min.js?ver=3.5.1:2
load (async)
send @ jquery.min.js?ver=3.5.1:2
ajax @ jquery.min.js?ver=3.5.1:2
S.<computed> @ jquery.min.js?ver=3.5.1:2
(anonymous) @ eio-tools.js?ver=600:278
dispatch @ jquery.min.js?ver=3.5.1:2
v.handle @ jquery.min.js?ver=3.5.1:2

Remove line 7238 from common.php–the one with imsanity_get_option(), and it should work fine.
I’ll get a bugfix release out next week on that.

I’ve checked in the updated code, you can grab it from GitHub to try it out: https://docs.ewww.io/article/73-update-from-github

This issue seems to have been resolved, although progress of the deletion seems awfully slow and deleted files aren’t being listed (this would be a good idea for all the functions, actually – more confidence for the user).

When I got to 1543/6831, I had to stop the process, and when I restarted it, it was just as slow as it was the first time. What is it doing for so long?

One more thing: It ran for a long time, so when I left my desk and my computer went to sleep, my connection died. Then, when I looked again, I saw a network error and the process didn’t continue.

I think it’s best to run this (and other tools) in the background. If not, at least keep track of what’s been done, so it can be continued from where it stopped.

That definitely doesn’t seem normal, unless I have it running at a throttled rate…
I’ll check on that, and do some testing to see what “normal” ought to be.

Great, thanks. I still like the background idea ??

I checked my suspicion, and there’s a sleep() statement to throttle the process at line 676 of aux-optimize.php. Remove that, and it should speed up quite a bit. I just had that in there for testing and forgot to remove it, so I’ll pull that out for 6.0.1.

Awesome. Thank you!

Tried again. Still very slow.

This process likely involves one database query, possibly followed by a file deletion. There’s no way it takes about a second per image.

I timed 2 test sites and it did about 90 in a minute. That’s way too slow.

Also, I really wish there was more output, including whether something was deleted or not, and what was deleted, if anything was.

• This reply was modified 3 years, 8 months ago by Gal Baras.
• This reply was modified 3 years, 8 months ago by Gal Baras.

With version 6.0.1? It’s a few more than one query, and while it certainly shouldn’t be super slow, sometimes we run into really weird db slowness (even on hosts that should be fast). At any rate, I’m getting about 100 per 20 seconds, so more than triple that speed. It may not be the most efficient code, but I was trying to lean more on WP core functions than reinventing the wheel.

I’ll look into improving it down the road, but if someone wants to submit a pull request to make it faster (and more verbose), I sure wouldn’t say no.

One idea might be to run a single large query and then loop through it, rather than a long series of queries. If a complex join is involved, it may also be better to run a couple of simpler queries and apply some of the conditions in the PHP code.