autoptimize

Autoptimize

by

screenshot of the arbitrary file upload fix on github. quite happy with my work thereWith Autoptimize 2.7.7 released on August the 23rd and having been pushed to all sites that were still on 2.7.0-2.7.6 by the WordPress plugins team on Aug. 30th and 31th, resulting in just under one million downloads in 8 days time, it is now the moment for a small debrief of the security issues that were fixed in this version.
2.7.7 fixed two vulnerabilities, one authenticated cross-site scripting and one arbitrary file upload.

  1. XSS:
    1. Problem: administrator users were able leave JavaScript in the exclusion-fields for CSS and JS optimization, leading that JS to be executed when the page was (re-)loaded.
    2. Risk: This could be abused by one administrator to execute JS against another administrator.
    3. Solution: This was fixed by applying esc_html (to become esc_attr in the next version as suggested by George Stephanis) to escape the JS-code and avoid it getting executed.
  2. Arbitrary File Upload:
    1. Problem: the code that processes Critical CSS settings imports did insufficient checks to ensure no malicious files were uploaded as it lacked a user capability check, did not check file extension of to uploaded file to be zip and did not check the contents of the zip-file. It did however check for a correct nonce for that specific action.
    2. Risk: this could lead to authenticated attackers uploading PHP-files that could be executed, but that risk was very much limited by the nonce-check (which all exploits I have seen happily ignore).
    3. Solution: the code has been updated to do a capability check, to make sure the file uploaded is a zip-file and most importantly to delete any unknown file found immediately after unzipping (based on an list of known-good files).

A big thank you to the two security researchers (Erin Germ for the XSS and an anonymous whitehatter for the file upload problem) who reported these vulnerabilities in a responsible manner and to the WordPress plugin team for their invaluable help in keeping our users safe.

Don’t take free & open source for granted; donate to Mozilla!

by

Do you ❤️ the free and open web and do you want to ensure a non-profit can continue to play an important role? Do you use Firefox or use MDN (Mozilla Developer Network) to check up on JS or CSS or HTML syntax?
We do too and as from today Optimizing Matters will donate $20 monthly. If you use Autoptimize or Async JavaScript or WP YouTube Lyte then please, pretty please, consider donating at https://donate.mozilla.org too.

Autoptimize 2.7.5; known issues

by
Update June 28th: 2.7.6 was released, all is (or should be) fine … 🙂

There currently are 2 known issues in Autoptimize 2.7.5 that will be fixed in the next release;

  1. when “inline & defer CSS” and “also aggregate inline CSS” are active then for logged in users the top “admin bar” might become invisible. unticking “also aggregate inline CSS” is a confirmed workaround.
  2. when “inline & defer CSS” is active, CSS-files that are not aggregated (excluded or 3rd party) and that do not have a media-attribute will not be deferred.

If you want you can download the beta of what will become 2.7.6 here and install that instead of 2.7.5 to get rid of these known issues.

Autoptimize code; blacklist/whitelist becoming blocklist/ allowlist

by

As of the soon-to-be-released Autoptimize 2.7.4, all occurrences of “blacklist” and “whitelist” in the code will be changed into “blocklist” and “allowlist”. There is no impact for users of Autoptimize, everything will work as before.
If however you are using Autoptimize’s API, there are two (to my knowledge rarely used) filters that are now deprecated and will be removed at a later stage. `autoptimize_filter_js_whitelist` and `autoptimize_filter_css_whitelist` still work in 2.7.4 but if you’re using them switch to  `autoptimize_filter_js_allowlist` and `autoptimize_filter_css_allowlist` to avoid problems when they are removed in the release after 2.7.4.
Small post-publishing clarification dd. 22/07/2020: this post is just an announcement, I feel no urge to discuss the change and am not really interested in arguments pro or contra. Don’t fret over this change, fretting is useless, instead enjoy the summer, kiss your lover, read a good book, … 🙂

Google PageSpeed Insights updated, new metrics and recommendations!

by

If you tested your blog’s performance on Google PageSpeed Insights yesterday and do so again today, you might be in for a surprise with a lower score even if not one byte (letter) got changed on your site. The reason: Google updated PageSpeed Insights to Lighthouse 6, which changes the KPI’s (the lab data metrics) that are reported, adds new opportunities and recommendations and changes the way the total score is calculated.
So all starts with the changed KPI’s in the lab metrics really; whereas up until yesterday First Contentful Paint, Speed Index, Time to Interactive, First Meaningful Paint, First CPU Idle and First input delay were measured, the last 3 ones are now not shown any more, having been replaced by:

  • Largest Contentful Paint marks the point when the page’s main content has likely loaded, this can generally be improved upon by removing removing render-blocking resources (JS/ CSS), optimizing images, …
  • Total Blocking Time quantifies how non-interactive a page while loading, this is mainly impacted by Javascript (local and 3rd party) blocking the main thread, so improving that generally means ensuring there is less JS to execute
  • Cumulative Layout Shift which measures unexpected layout shifts

The total score is calculated based on all 6 metrics, but the weight of the 3 “old” ones (FCP, SI, TTI) is significantly lowered (from 80 to 45%) and the new LCP & TBT account for a whopping 50% of your score (CLS is only 5%).
Lastly some one very interesting opportunity and two recommendations I noticed;

  • GPSI already listed unused CSS, but now adds unused JS to that list, which will prove to be equally hard to control in WordPress as JS like CSS is added by almost each and every plugin. Obviously if you’re using Autoptimize this will flag the Autoptimized JS, disalbe Autoptimize for the test by adding ?ao_noptimize=1 to the URL to see what original JS is unused.
  • GPSI now warns about using document.write and about the impact of passive listeners on scrolling performance which can lead to Google complaining about … Google 🙂

Summary: Google Pagespeed Insights changed a lot and it forces performance-aware users to stay on their toes. Especially sites with lots of (3rd party) JavaScript might want to reconsider some of the tools used.

Autoptimize 2.7; final stretch, testers needed!

by

Autoptimize 2.7 is in the final stages and the beta version can as of now be downloaded from https://downloads.wordpress.org/plugin/autoptimize.zip
Main new features:

So who want to test? Feedback in the comments please! 🙂

Autoptimize: no more broken pages due to CSS/ JS not found!

by

When cached HTML links to deleted Autoptimized CSS/ JS the page is badly broken … no more with a new (experimental) option in AO27 to use fallback CSS/ JS which I just committed on the beta branch on GitHub.
For this purpose Autoptimize hooks into template_redirect and will redirect to fallback Autoptimized CSS/ JS if a request for autoptimized files 404’s.
For cases where 404’s are not handled by WordPress but by Apache, AO adds an ErrorDocument directive in the .htaccess-file redirecting to wp-content/autoptimize_404_handler.php. Users on NGINX or MS IIS or … might have to configure their webserver to redirect to wp-content/autoptimize_404_handler.php themselves though, but those are smart cookies anyway, no?
If you want to test, you can download Autoptimize 2.7 beta here and replace 2.6 with it.