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.
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:
A new page/ post does not introduce new CSS/ JS
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.
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!
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 ;-)
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.
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.
