I just upped Autoptimize 2.9 beta to version 4, which is likely to be the last version before the official 2.9 release (eta end June/ early July).
Main new features;
You can download the beta from Github (do disable 2.8.x before activating 2.9-beta-4) and you can log any issues/ bugs over at https://github.com/futtta/autoptimize/issues
Looking forward to your feedback!
JavaScript often has to be excluded from being aggregated due to inline JS depending on it. That’s why Autoptimize 2.9 will also have to option to defer inline JS, allowing all JS to be deferred, even that pesky jQuery. As seen in below screenshot exclusions obviously will be honored for both inline and linked JS so you will be able to tweak everything just right.
The settings for JavaScript optimization also have been reshuffled, making “also aggregate inline JS”, “force JS in head” and “try/catch wrapping” sub-options of “Aggregate JS” (so hidden on the screenshot as “aggregate JS” is off), whereas “Defer inline JS” is a sub-option of “Don’t aggregate but defer”.
So we have per post/ page AO settings and we now have “also defer inline JS” for what will become 2.9. And there’s more to come …
I’m in the process of adding a per page/ post option to disable Autoptimization.
In the current state of this work in process one can disable Autoptimize entirely on a post/ page or disable just JS optimization as you can see on the screenshot.
Now my question to you, Autoptimize user, is; what other options of below list _have_ to go in that metabox taking into account the list should be between 3 and 5 items long?
This morning I finally pushed Autoptimize 2.8.2 out of the gates which was a relatively minor release with misc. small improvements/ bugfixes. Only it proved not that minor as it broke some sites after the update, so here’s a quick postmortem.
wp-content/plugins/autoptimize/classes/external/php/ao-minify-html.php missingOne of the improvements was changing the classname of the HTML minifier to avoid W3 Total Cache’s HTML minifier being used. For this purpose not only small changes were made to the HTML minifier code, but the file was also renamed from minify-html.php into ao-minify-html.php. The file itself was present on my local filesystem, but I did *not* svn add it, so it was never propagated to the wordpress.org SVN server, resulting in it not being in the 2.8.2 zip-file causing the PHP Fatal “require(): Failed opening required” errors.
Every svn ci has be proceeded by an svn stat, always. I’ve updated my “go live” procedure to reflect that.
Additionally; I strongly advise against automatic updates for Autoptimize (and I don’t auto-update any plugin myself), not only for major f-ups like mine today, but also because any change to how (auto-)optimization works needs to be tested for regressions. And if you have a site that generates money somehow, you really should have a staging site (which can auto-update) to test updates on before applying on production.
Given the major change in Contact Form 7‘s frontend JavaScript and the problems having to optimize the JS or cache the page after the update, the question I get asked frequently is what alternatives there are to CF7.
So here is a very quick rundown of 3 such alternatives:
My advice; try HTML Forms if you have rather standard contactform-like forms and you’re not looking for something fancy (which CF7 is not either), try Formidable if you need drag & drop form building or if you (will) need more flexibility/ integrations.
Due to a recent major change in Contact Form 7’s frontend JavaScript Autoptimize users might have to add wp-includes/js/dist the comma-separated JS optimization exclusion list (or in some cases even wp-includes/js).
It is nice CF7 gets rid of the jQuery dependancy, but I’m not sure is replacing that with a significant amount of extra WordPress blocks JS-files was such a good idea?
Update: additionally the change also introduces nonces (random password-like strings as hidden elements in the form) which can spell serious trouble when using page caching plugins.
Up until now Autoptimize, when performing image optimization, relies on JS-based lazyloading (with the great lazysizes component) to differentiate between browser that support different image formats (AVIF, WebP and JPEG as fallback).
As JS-based Lazyload is going out of fashion though (with native lazyload being supported by more browsers and WordPress having out-of-the-box support for it too), it is time to start working on <picture> output in Autoptimize to serve “nextgen image formats” where different <source> tags offer the AVIF and WebP files and the <img> tag (which includes the loading=”lazy” attribute) with JPEG as fallback.
For now that functionality is in a separate “power-up”, available on Github. If you have Image Optimization active in Autoptimize (and you are on the Beta version, Autoptimize 2.8.1 is missing a filter which the power-up needs so download & install the Beta if not done yet), you can download the plugin Github and give it a go. All feedback is welcome!