A couple new features have will be landing in version 3.3, and there have been some big changes “under the hood” with API accounts and within the plugin itself:
- With version 3.3, you can now enable Image Backups, which will store your images for 30 days. You can restore an image from the Bulk Optimizer page using the Show Optimized Images button or from the Media Library in list view. NextGEN, Nextcellent, and FlaGallery have also been updated to allow one-click restores as well. As always, you should have your own backups, but now EWWW has an extra “safety net” for you too!
- Another new trick that EWWW IO learned is the ability to use relative paths for tracking and optimizing images. This is particularly useful for those on the Pantheon platform that use their load-balancing feature. With the load-balancers, file paths change every 30 seconds, and so EWWW had a difficult time finding images, and tracking whether or not an image had been optimized. Relative path support will be enabled on all Pantheon sites automatically, so if you have an existing Pantheon site that is NOT using load-balancing, please contact us for information on updating your database to recognize previously optimized images.
- Auto-rotation: All images that have an Orientation field stored in the EXIF metadata will be auto-rotated to ensure that resizes are generated by WordPress correctly, and to ensure your images don’t go sideways when metadata is stripped by optimization. This uses an external library called PEL for managing the metadata updates, and is one of the reasons for mandating PHP 5.3+ moving forward.
- So yes, PHP 5.3+ is now required. First, there are zero supported linux distributions that are still maintaining PHP 5.2. This means there are likely security holes in PHP 5.2, and those will never be patched. I know some folks like to live on the wild side, but that’s a bit crazy. Also, PHP 5.6+ are way faster than previous versions, and 7.0+ is even double the speed of 5.6 for WordPress. So if you insist on sticking with PHP 5.2, that’s double-crazy! Any competent webhost will be able to upgrade your site to a newer version of PHP within minutes (if not quicker). Most of the time you can simply toggle a switch in your web-hosting control panel (cPanel). There are some plugins that don’t work with PHP 7.0 (shame on them), so make sure you test things out thoroughly if you opt for 7.0 or 7.1. If you use a PHP tester plugin, you’ll get a false positive with EWWW I.O. but rest assured I run EWWW I.O. every day on PHP 7.0, so it’s well-tested on that version.
That leads me to some of the changes that are more “in the background” type things:
- Testing. Version 3.3 was delayed significantly because I’ve been working on unit tests, integration tests, and ensuring EWWW IO complies with the WordPress Coding Standards. This allows EWWW IO to be automatically tested for faults on a variety of platforms every time I perform a check-in on github. Using Travis CI, the plugin is tested on the latest version of WordPress, as well as WP 4.4, every PHP version from 5.3 to 7.1 (and even hhvm), as well as multi-site WordPress. Now, this doesn’t mean there aren’t bugs… Wait, but I right perfect code! Haha, anyone who says that is nuts, most of us don’t even write perfect sentences (kudos if you already caught the typo in the last sentence). Using Travis CI allows me to catch many bugs more quickly, and in the future, develop tests to ensure that once a bug has come up, it can’t come back again without triggering a failure in the test matrix.
- Some have experienced the pain of an image regeneration bug, and while EWWW will attempt to auto-detect when such a problem occurs, and alert you to that fact. It wasn’t able to prevent that from happening. Thus I put my thinking cap on, and came up with a way to prevent such things from happening. If anything attempts to regenerate an image using the WP_Image_Editor class, EWWW IO will check the expected dimensions of the new image, and if they match the dimensions of the existing image, the new image will be discarded, and NOT optimized. This doesn’t negate the fact that these sorts of bugs can slow down your site a bit, but it will prevent EWWW from magnifying the issue, and bringing your site to a crawl.
- There were some huge changes to background image optimization. First of all, retina images will now be optimized in the background, to reduce the wait time when uploading new images. Also, EWWW will behave better during a mass image operation like regenerating thumbnails. Optimization will be disabled during generation, and if background mode is functional, the newly generated images will optimized in the background. This also prevents EWWW from ignoring the disabled sizes list during thumbnail regeneration. There was also a rather large bug where background mode would cause a sort of snowball effect if you had something importing images automatically. If, for example, you imported 100 images in a batch, it would create a queue with the first image, then a second queue with the first two images, a third queue with the first three images, and so on. In the worst case, that could create 970,000+ queues on a site with EWWW active for several months while importing images, yikes! Now EWWW only maintains two queues, active and inactive, and will not add an image to a queue more than once.
- There was also a bug that could surface when checking permissions of the binaries used for local optimization. If the check triggered an admin notice, it made the media library appear blank. It was NOT blank, mind you, but it sure looked that way. Problem was, the notice was output before the rest of the page, and the invalid HTML code broke the media library layout. The notices are now delayed to the appropriate point, and the permissions checks were rewritten to be more flexible and accurate in the process.
- A couple improvements were also made with the bulk scanner. In particular, running EWWW IO within WP-CLI when a memory limit is set will no longer cause memory errors. The low memory mode was also suffering from a bug that would skip images sometimes. With that fixed, EWWW IO is now able to use this same mode in instances where querying the entire ewwwio_images table is less efficient than querying each individual image, and the end result is a more reliable bulk scanner.
There are various other fixes and reliability improvements, which you can find on the full changelog on github.
Some changes have also been made with the API, and our billing system:
- Multiple improvements were made, like allowing multiple email records, and syncing Paypal purchases properly. The changes also allow you to use a single Paypal account to setup multiple accounts at ewww.io.
- Another big new feature is the ability to generate multiple API keys on your account for client use. If you do a lot of consulting/client work, you can now generate a unique key for each client/site. This allows you to track their usage, and set monthly limits on usage as necessary. And should you ever suspect your API key has been misused/stolen, you can generate a brand new key from https://ewww.io/my-account/ without having to contact support.
- The API now also obeys the metadata flag when generating WebP images, which is useful for those of you that have ICC profiles embedded in the metadata. It also uses the JPG quality setting to set the WebP quality, so you can tweak that to your heart’s content.
- In response to customer demand, and my own dissatisfaction with the amount of money being lost to credit card processing fees, the minimum payment amount on the API is $9. As such, the billing system will not bill your account until you reach 3,000 or more credits, and the signup fee has been increased to $9. New customers get a signup bonus of 500 credits, so if you’ve been waiting to try out the API, there’s no better time.
I can barely wait to get this into your hands and make your life more productive, but I want to give our translators a couple days to catch up, so the planned release date is April 19, 2017. If you can’t wait either, grab a copy from github.