Due to a recent major change in Contact Form 7’s frontend JavaScript Autoptimize users might have to add wp-includes/js the comma-separated JS optimization exclusion list.
It is nice CF7 gets rid of the jQuery dependancy, but replacing that with a significant amount of extra JS-files and in some cases a wp-json request, really?
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:
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.
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;
}
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 ;-)
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.
[Update: this indeed got fixed with 1.1.4]
So audio-only embedding is broken due to YouTube enforcing the minimum embedded player size that has been added to the TOS recently. I’m working on a fix for this, expect 1.1.4 soon. And if you’re impatient (or want to help), you can always download the development tar-ball here.
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?
