Einkoro

I’ve created a fork of the plugin with a fix for the PHP version check to support 7.0+ that you could try:
https://github.com/Einkoro/wp-image-cleanup

Considering the plugin has been inactive for 2 years I wouldn’t be surprised if you encounter other issues though. Let me know if you encounter any and I can take a look at it. Highly recommend backing up before you do anything after indexing regardless.

I’ve created a pull request to address this issue and respect which post types are enabled when sorting taxonomy archives: https://github.com/hijiriworld/intuitive-custom-post-order/pull/9

The issues seems to stem from lines 444 and 453. If WP_Query does not have a post_type defined (ie you are browsing a taxonomy of a custom post type) it falls back to checking if post is enabled.

Beware of changing the allowed mimetypes if you have any plugins or functionality allowing users to upload files through WordPress such as bbPress attachments or any sort of customer support ticketing system or image gallery. You will be allowing it there as well.

I would recommend making sure the user is able to manage woocommerce before adding the mimetypes. You can do that with the following, replacing exe/dmg with whatever files you need to allow:

// Allow exe or dmg for digital downloads
add_filter('upload_mimes', function($mimetypes, $user)
{
    // Only allow these mimetypes for admins or shop managers
    $manager = $user ? user_can($user, 'manage_woocommerce') : current_user_can('manage_woocommerce');

    if ($manager)
    {
        $mimetypes = array_merge($mimetypes, [
            'exe' => 'application/octet-stream',
            'dmg' => 'application/octet-stream'
        ]);
    }

    return $mimetypes;
}, 10, 2);

Also of note the ability to use protocol relative URLs is broken with the check added in 2.3.10 so you must explicitly put https:// or https:// rather than // for your download links.

It looks like the imagick extension should be included in HHVM since 3.0:
https://github.com/facebook/hhvm/issues/954
https://github.com/facebook/hhvm/tree/master/hphp/runtime/ext/imagick

I’ll bump up the max execution time and drop the number of passes. Being able to disable EWWW during media_handle_upload() would probably be invaluable here as its a select member tier that has access to a upload form intended to submit PNG or TGAs of very high resolution assets. About 96 users in total but who knows what kind of crazy sized files they will throw at it. Particularly when the recommended DPI is 300.

It doesn’t seem to be detecting imagemagick as the error occurs in class-wp-image-editor-gd.php rather than class-wp-image-editor-imagick.php

As for the missing dependencies this sounds like it might be the issue if its exec failing:
https://github.com/facebook/hhvm/issues/3340
https://stackoverflow.com/questions/23266805/problems-with-hhvm-and-shell-exec

Its a pain to reproduce since it seems to vary.

Might also be nice to offer an option to optimize at regular intervals via wp-cron rather than during upload. At least for users that disable WP_CRON and setup a actual cron job to trigger it so its not affecting load times.

+1, would be nice for custom upload forms using media_handle_upload() if we could disable it.

I’m seeing the same issue with WordPress 4.0

It looks like the PNG bulk optimization stripped the transparency before I enabled the option to convert to JPG from what I can tell as clicking restore original is missing the transparency. I have backups so its just a matter of restoring the images and the table for attachments before I give this another run.

To work around this I hooked a function into the action ‘displaytweets_tweet_template’ and used DisplayTweets::get_instance() to access the plugin’s methods and bypass the default template avoiding modifying the plugin directly. Then I added the offset to the timestamp:

$posted_since = apply_filters( ‘displaytweets_posted_since’, date_i18n( $datetime_format, strtotime($tweet->created_at) + ( get_option(‘gmt_offset’) * 3600 ) ) );

Seeing this again on the upgrade from 5.0.6 to 5.0.7. CPU usage immediately spiked for MariaDB and HHVM after the upgrade and the website became unresponsive. Approximately 10GB of binary logs were being written every five minutes.

The only thing relevant in the php log was endless entries like this:
SlowTimer [1053ms] at runtime/ext_mysql: slow query: alter table lcwp_wfConfig modify column val longblob

I haven’t changed my credentials although I did enable two factor authorization at CloudFlare. I tried regenerating the API token and updating the plugin settings with the new one to see if that made any difference but it is still occurring.

With the background fill color left blank bulk optimize converted the PNGs with transparency to JPG with #fff for the background color on the latest version of the plugin.

Do you know if the bulk optimization performs conversions or if its only at upload and manually clicking the link from the library?