So audio-only and playlist embedding were broken due to changes at YouTube’s side, but version 1.1.4 fixes that. Some information for those users that implement WP YouTube Lyte’s audio-only embedding feature; it got broken because YouTube started to enforce the minimal player size they recently added to their TOS. Audio-only is, for many reasons, something that YouTube doesn’t want to support and indeed might even want to block, so this might break again. So if you want to be on the safe side or if you just don’t want to piss YouTube off, you probably should reconsider doing audio-only. That being said, here’s a nice audio-only track for your audio-only ears to celebrate this new release;
Last night I released WP DoNotTrack version 0.7.0, which adds a new filtering mode called SuperClean. Whereas the previous version only acted on elements added to the DOM, SuperClean now also allows you to filter the base HTML of your pages. To do this, SuperClean uses the PHP output buffer to catch the full HTML before it’s being sent to the browser. That HTML is then parsed with PHP Simple HTML DOM Parser and based on your black- or whitelist the filtering is applied (SuperClean + whitelist = running a very tight ship, really). Currently SuperClean is not available if you have configured WP DoNotTrack to only stop tracking for people who have set the DoNotTrack-flag in their browser. While we’re on the subject of conditional filtering; I’ve updated the code that checks for the DoNotTrack-flag to work around differences in browser implementations. Conditional filtering is pretty important, as it can help websites to comply with the (for now UK-only) “EU Cookie Law” which requires websites to ask their visitors for explicit consent prior to setting cookies. With WP DoNotTrack you can have your cookie and eat it too; you have your existing tracking scripts for users who give consent, while still being able to serve a “clean” website for users who enabled DoNotTrack in their browser. Given the fact that similar laws will be coming to a EU-country near you, conditional filtering is something I’ll be looking into further, so any feedback on the current implementation is more than welcome!
I’m not a developer, I’m just a random guy who was lucky enough to be around when the web started to happen, back in the nineties. And over the years I might have learned a bit about web development, but still I’m not a real developer. And yet, there I am with two WordPress plugins, fiddling with PHP and JavaScript. I’ll let you in on what’s not really a secret; I’ve made some ridiculous mistakes while coding those plugins. Trial and error, you know. Testing, fixing, releasing and getting feedback. Especially getting feedback!
Real users telling me it doesn’t work, asking for extra features or making proposals to make it better overall, that what I thrive on. The latest example; JavaScript namespaces. Not being a developer means that I know as much about coding patterns as I know about cows. I just hit the keyboard real hard and hope the browser understands what I throw at it. Until a good friend told me to use JavaScript namespaces, to avoid conflicts with other people’s JavaScript. And a week later someone wrote my software just didn’t work any more and I had to start digging and found a JavaScript conflict that was introduced with a new version of AddThis
And those are the moments one grows, as a developer; you start searching for information about scope, anonymous functions and namespaces. You try, it doesn’t work and you dig some deeper, until you stumble on a great question and answer on Stack Overflow with a link to a very detailed article about JavaScript coding patterns. So you go back into ‘vi’ and start changing the code once again and than all of a sudden you have a working version, which your Polish user confirms fixes the problem and you learned a lot while bugfixing. So kudo’s to all you guys & girls for the great feedback, you rock! Here’s WP YouTube Lyte version 1.1.3 to thank you.
I finally found some time to continue to work my other WordPress plugin. WP DoNotTrack checks for elements being added to the DOM by JavaScript to stop 3rd party tracking by some of the major plugins or themes.
Version 0.6.0, which I released last week, features a new “forced” option. This mode aims to provide better compatibility with JavaScript-optimizing plugins such as Autoptimize and W3 Total Cache by adding the relevant code only after those optimizers have done their job, using the output buffer. There will probably be a 0.6.1 today or tomorrow, to solve a small problem with mixed HTTP/HTTPS requests on the admin-page while in HTTPS. The output buffer sure is a powerful thing and for version 0.7.0, I’ll build on that to optionally filter the full HTML (with PHP Simple HTML DOM Parser) to stop unwanted requests for images, scripts or iFrames in there.
Do contact me if you found a bug, if you have questions or if you’d like specific feature to be added, I tend to rely heavily on user feedback to improve my plugins! And if you’re happy with how it works, drop by on the WP DoNotTrack-page on wordpress.org to rate it and/ or to confirm it works with your version of WordPress!
So using WP YouTube Lyte instead of normal YouTube embeds results in less files to download, less data to transport, the page being ready for interaction quicker and having everything loaded a whole lot faster. These figures are for a single YouTube on a page, but the impact is all the more important if you have multiple video’s on one page (e.g. a category or tag-page for “music” or “videos”) off course. The full comparison based on 10 tests on both pages:
You can do great things in JavaScript; accessing the DOM and adding, changing or removing nodes as you please. It is exactly that technology that WP YouTube Lyte is based upon; the PHP-part writes out an almost empty div’s with className “lyte” and with as id the YouTube ID, which the JS-part finds after the main document has loaded to render the “LYTE player”. Great for performance, so I was pretty surprised when DerTux, one of WP YouTube Lyte users wrote;
Although 52ms for a page with 3 “LYTE players” is minimal when compared to loading the same page with the full embedded YouTube player, the above statement bugged me enough to search the web for information about reflows and how to prevent them. Some of the more interesting articles:
Based on these pointers I started reworking lyte.js while testing on Google’s Page Speed Online (as far as I can tell the only tool that can detect reflows and then only as an experimental feature) to minimize reflows. I ended up:
adding the pL div, which contains the LYTE player UI (play-button, controls & YouTube thumbnail), only after all styles have been applied
adding the tC div, which contains the title, only after the tT div (with the title as received in the YouTUbe jsonp-call) has been added to it
replaced el.clientWidth (and el.clientHeight) with el.style.width.match(/\d+/g)[0]
some widths and heights did not have a unit specified in the dynamically generated CSS and this sloppy coding apparently also (indirectly) caused reflow
WP YouTube Lyte 1.1.1 will get pushed out in a couple of days (Thursday, probably) and will ship with these performance optimizations (and a fix for a regression which causes some styles not to be applied any more).
Nope, 1.0.0 wasn’t WP YouTube Lytes final destination, the train has left that station to arrive at version 1.1.0 yesterday. Main new features include:
It was time to put my money where my mouth is, or at least to give the use of a CDN a try. Based on previous tests MaxCDN seemed like a decent, dirt-cheap solution, so that’s what the js, css & images for this blog are served from now. Setting this up was very easy:
log into MaxCDN and set up a pull zone on static-cdn.blog.futtta.be with origin blog.futtta.be
create static-cdn.blog.futtta.be in the web interface of my DNS-provider (as a CNAME to the domain-name provided)
The speed difference can be huge, especially when routing to my origin VPS-server in Germany isn’t great. I’m sure my 2 overseas users and Google will approve! Bandwidth-wise, with 10MB/day, I seem to be far from the 1TB/year I’m allowed, so if you’d like me to setup a (temporary) pull zone for your blog so you can check out if this would work for you then just drop me a line.
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?
