Category Archives: Technology

Blogposts on blog.futtta.be about internet, web developement, browsers, security, linux, …

WordPress 4.7 custom background image bug & workaround

If you encountered this bug but are not using Autoptimize, leave a comment below or contact me here. Your info can help understand if the regression has an impact outside of Autoptimize as well!


Gotta love Sarah, but there’s a small bug in Vaughan’s (WordPress 4.7) that breaks (part of the CSS) when Autoptimized. If you have a theme that supports custom backgrounds (e.g. TwentySixteen) and you set that custom background in the Customizer, the URL ends up escaped (well, they wp_json_encode() it actually) like this;

body{background-image: url("http:\/\/localhost\/wordpress\/wp-content\/uploads\/layerslider\/Full-width-demo-slider\/left.png");}

Which results in the Autoptimized CSS for the background-image being broken because the URL is not recognized as such. The bug has been confirmed already and the fix should land in WordPress 4.7.1.

If you’re impacted and can’t wait for 4.7.1 to be released, there are 2 workarounds:
1. simple: disable the “Aggregate inline CSS”-option
2. geeky: use this code snippet to fix the URL before AO has a change to misinterpret it;

add_filter('autoptimize_filter_html_before_minify','fix_encoded_urls');
function fix_encoded_urls($htmlIn) {
	if ( strpos($htmlIn,"body.custom-background") !== false ) {
		preg_match_all("#background-image:\s?url\(?[\"|']((http(s)?)?:\\\/\\\/.*)[\"|']\)?#",$htmlIn,$badUrls);
	  	if ($badUrls) {
			foreach ($badUrls[1] as $badUrl) {
				$htmlIn = str_replace($badUrl, stripslashes($badUrl), $htmlIn);
			}
		}
	}
  	return $htmlIn;
}

So how does Autoptimize work anyway?

A question that has come up a couple of times already is how Autoptimize and it’s cache work. So let’s do some copy/pasting of what I replied earlier on the wordpress.org support forum;

  1. AO intercepts the HTML created by WordPress for a request (using the output buffer)
  2. all references to JS (and CSS) are extracted from the HTML
  3. all original references to JS (and CSS) are removed from the HTML (the code in the original files is left as is, AO never changes those files)
  4. all JS (and CSS) is aggregated (JS in one string, CSS in as many strings as there were media types)
  5. the md5-hash (mathematical/ cryptographic function that generates a quasi-unique string based on another string) of the aggregated JS (and CSS) is calculated
  6. using the md5 AO checks if a cached file with that md5 exists and if so continues to step 8
  7. if no cached file is found, the JS (and CSS) is minified and cached in a new file, with the md5 as part of the filename
  8. the links to the autoptimized JS (and CSS) file in cache are injected in the HTML
  9. the HTML is minified (but not cached in Autoptimize)
  10. the HTML is returned to WordPress (where it can be cached by a page cache and sent to the visitor)

This is especially interesting if you want to understand why the cache size can “explode”; if in step 4 the code is even a bit different from previous requests, the md5-hash in step 5 will be different so the file will not be found in cache (step 6) and the code will be re-minified (which is relatively expensive) and cached (step 7).

And that, my friends, is how Autoptimize works.

How to fix CSS media-types impacting Autoptimized CSS order

pixeldima-forum-screenshotAdel of Pixeldima contacted me to look into a problem with some of the styles not being applied after autoptimization on the forum-page in his beautiful OKAB-theme. I had seen similar problems before, but decided to dig in this time to understand the root cause. That root cause turned out to be 2 CSS-files, one overriding the style of the other, having a different media-type, which messed up the load order once autoptimized. This can either be fixed at the theme-level, at AO configuration level or with a couple of lines of code hooking into AO’s API.

The problem

Without Autoptimize (which one can trigger by simply adding ?ao_noptimize=1 to the URL), these 2 relevant files were loaded (among many others obviously):

  • bbpress.css (the default bbpress css-file) was loaded first with media=”screen”
  • okab/bbpress-styles.css (part of the theme) is loaded second with media=”all”, overriding some of the CSS in bbpress.css

Autoptimize honors the media-types, resulting in 2 Autoptimized CSS-files;

  • autoptimize_1a002577cefe349767025a16201f37a9.css with media=”all” is loaded first (because the very first CSS-file encountered in the HTML had media=”all”) which contains okab/bbpress-styles.css
  • autoptimize_8e3c7dac90177214b6583286ddaa141f.css is loaded second with media=”screen”, containing bbpress.css

So due to the mediatype the code in bbpress-styles.css was loaded before the CSS in bbpress.css when Autoptimized, resulting in styles being overwritten the wrong way (bbpress-styles.css is overwritten by bbpress.css instead of the other way around).

The solution(s)

As Adel was the theme developer, he could immediately attack the root issue by enqueuing bbpress-styles.css with media=”screen”. This way both files share the same media-type and go in the same autoptimized CSS-file, resulting in the CSS of bbpress.css getting properly overwritten by the CSS of okab/bbpress-styles.css.

If you’re not the theme developer you’ll probably not want to change the theme’s code (although you could dequeue and re-enqueue in a child-theme’s functions.php), in which case you have two workarounds at your disposal: the easiest workaround being simply excluding the CSS-file that gets overwritten from CSS optimization (i.e. in this case simply adding okab/bbpress-style.css to the list of CSS optimization exclusions). Easy indeed, but on the downside you’ll have one non-optimized CSS-file. That’s why it’s a good thing we have our precious little API, allowing us to override the media-type of the offending file with just a couple of lines of code, like this;

add_filter('autoptimize_filter_css_tagmedia','check_mediatype',10,2);
function check_mediatype($media,$tag) {
  if ( strpos($tag,"okab/bbpress-styles.css") !== false ) {
	$media=array("screen");
  }
  return $media;
}

Conclusion

As Autoptimize honors the original CSS’s media-types, 2 CSS-files that ought to be loaded in a specific order might end up being loaded in the wrong order if their media-type is different. This can be fixed in the theme or worked around by excluding a specific CSS-file or using AO’s API to override the media-type for the offending CSS-file.

Autoptimize cache size: the canary in the coal mine

another-canary-in-a-coal-mineCopy/ pasted straight from a support question on wordpress.org;

Auto-deleting the cache would only solve one problem you’re having (disk space), but there are 2 other problems -which I consider more important- that auto-cleaning can never solve:
1. you will be generating new autoptimized JS very regularly, which slows your site down for users who happen to be the unlucky ones requesting that page
2. a visitor going from page X to page Y will very likely have to request a different autoptimized JS file for page Y instead of using the one from page X from cache, again slowing your site down

So I actually consider the cache-size warning like a canary in the coal mines; if the canary dies, you know there’s a bigger problem.

You don’t (or shouldn’t) really want me to take away the canary! :)

Autoptimize 2.1 and first Power-Up released

Yesterday evening I released Autoptimize 2.1 and the first Power-Up to manage critical CSS has been made available as a optional service over at criticalcss.com. This short video explains some of the logic behind the Autoptimize Critical CSS Power-Up:

How to fix render-blocking CSS in WordPress

Watch this video on YouTube.

But let’s not forget about Autoptimize 2.1! The new features include:

  • Autoptimize now appears in the admin-toolbar with an easy view on cache size and the possibility to purge the cache (thanks to Pablo Custo)
  • A “More Optimization”-tab is shown with info about optimization tools- and services.
  • settings-screen now accepts protocol-relative URL for CDN base URL
  • admin GUI updated and responsiveness added
  • If cache size becomes too big, a mail will be sent to the site admin
  • power-users can enable Autoptimize to pre-gzip the autoptimized files with a filter
  • new (smarter) defaults for JS and CSS optimization

Although excluding jQuery from autoptimization by default might seem counter-intuitive, the “smarter” defaults should allow more Autoptimize installs to work out-of-the-box (including on sites run by people who might not be inclined to troubleshoot/ reconfigure Autoptimize in the first place).

And thanks to the release I now have a better idea of the number of active installs (which wordpress.org lists as +100000); 2.1 was downloaded 3239 times yesterday evening and it is listed as running on 1.8% sites. Simple math learns that Autoptimize is currently active on approx. 180000 WordPress websites. Let’s aim for 200K by the end of 2016! :-)