Tag Archives: bug

Warning: Divi purging Autoptimize’s cache!

8 Replies

A heads-up to Autoptimize users who are using Divi (and potentially other Elegant Theme’s themes); as discovered and documented by Chris, Divi purges Autoptimize’s cache every time a page/ post is published (or saved?).

To be clear; there is no reason for the AO cache being cleared at that point as:

  1. A new page/ post does not introduce new CSS/ JS
  2. Even if new CSS/ JS would be added somehow, AO would automatically pick up on that and create new optimized CSS/ JS.

Chris contacted Divi support to get this fixed, so this is in the ticketing queue, but if you’re using Divi and  encounter slower saving of posts/ pages or Autoptimized files mysteriously disappearing then his workaround can help you until ET fixes this.

WordPress 4.7 custom background image bug & workaround

7 Replies

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;
}

Wanted: testers for WP YouTube Lyte (the one with the new YT API)

Leave a reply

As I wrote a couple of weeks ago, YouTube is shutting down their old v2 API, forcing WP YouTube Lyte to swith to v3. The main change; users will have to get an API key from Google and provide that in the Lyte settings page.

Initial development & testing has been done (this blog switched already) and I now need some brave souls to test this. You can download the “beta” from https://downloads.wordpress.org/plugin/wp-youtube-lyte.zip and report back here or on the wordpress.org support forum about how that did or did not work for you.

Looking forward to having to fix some nasty bugs until everything will finally be in it’s right place once again ;-)

Osunlade ft Erro Everything In Its Right Place

Watch this video on YouTube.

Fixing Firefox’ LessChromeHD to reclaim lost screen real estate

1 Reply

I had been happily auto-hiding the Firefox navigation bar on my small-screen netbook for a couple of years already, until that add-on (LessChromeHD from the Prospector series) stopped working after having upgraded to Firefox 35. So I started Firefox from the command-line and spotted this error:

addons.xpi WARN Error loading bootstrap.js for lessChrome.HD@prospector.labs.mozilla: TypeError: redeclaration of variable event (resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/frank/.mozilla/firefox/jy6bws91.default/extensions/lessChrome.HD@prospector.labs.mozilla.xpi!/bootstrap.js:226:8)

A quick look at the source code confirmed “event” was declared twice, once on line 210 and a second time on line 226. The fix, obviously, is simple; on lines 226-228 replace all references to “event” with e.g. “shownEvent”;

let shownEvent = document.createEvent("Event");
shownEvent.initEvent("LessChromeShown", true, false);
trigger.dispatchEvent(shownEvent);

You can do this yourself by unzipping “lessChrome.HD@prospector.labs.mozilla.xpi” in your extenstions-folder, editing boostrap.js and updating the xpi. Or you could wait for the Mozillians to update LessChromeHD.

Bad Karma Blocks WP YouTube Lyte

4 Replies

On a blog that uses WP YouTube Lyte which I happened to stumble across, the following warning was displayed:

Hey! If you’re browsing in Firefox, there’s a very good chance that you won’t see youtube / video embeds.

As I really don’t like bugs but couldn’t reproduce any issue myself, I contacted the blog’s owner to find out what was happening. The description of the problem was pretty confusing:

The still shot/first frame of the video is there with the play icon, so things look hopeful, but when you click on the play icon the entire video disappears from the page. Page structure / layout does not change, but you are left staring at a blank white box where the embed should be.

A white div of death, really … Anyway, to cut a long story short, the misbehavior was caused by “Karma Blocker“. This Firefox addon “blocks resources based on their karma”, using a ruleset that scores behavior to blocks banners, trackers and also WP YouTube Lyte (or rather, the YouTube iFrame). Apparently the combination of the bad karma of JavaScript and the iFrame triggered the blocking mechanism.

I couldn’t code around Karma Blocker and chances are small the default configuration will give YouTube iFrames better karma, but the next version of WP YouTube Lyte (1.1.0, to be available soon) will display a simple message kindly letting users know they might want to adapt their Karma Blocker’s weightings.

But why is karma punishing me?

Watch this video on YouTube.

The WordPress-on-an-intranet nightmare

6 Replies

[UPDATE june 2009: this is solved in WordPress 2.8]

wp for dummies book coverHaving a fair amount of experience with WordPress installations and configuration, I wanted to install trusty old WP 2.5.1 on an idle desktop (winXP+xampp) at work to do some blogging on our intranet. The installation itself went smoothly (how hard can unpacking a zip-file be) but after some time the damn thing stopped working, producing nasty timeout-errors caused by a.o. wp-includes/update.php and wp-admin/includes/update.php.

The problem is that WordPress tries to open an internet-connection (using fsockopen) to see if updates are available. Great, except when you’re trying to run WordPress on an intranet behind a proxy without a (direct) connection to the internet. After some unsuccessful fiddling in multiple WordPress php-files, I ended up disabling fsockopen in php.ini (disable_functions)!

Disabling! Fsockopen! In php.ini! Just to have a working WP?

I mean, come on guys, why doesn’t WordPress provide configuration options where you can specify if and how (what type of proxy, what address to find it on, …) it should try to connect to the internet? I even made this truly amazing UI mock-up which you guys can just like copy/paste straight into your code;

_______________________________________________________________________________
How should WordPress connect to the internet to check for updates?
(*) Direct connection to the internet (default)
( ) Use a proxy:
    Proxy type:     (*) http ( ) socks
    Proxy URL:      ___________________________________________
    Proxy User:     ___________________________________________ (optional)
    Proxy Password: ___________________________________________ (optional)
( ) No internet connection available (WordPress won't be able
    to warn you about updates!)
________________________________________________________________________________

_
;-)
Pretty please?