Drink water, geen gebakken lucht (Blog Action Day)

We gaan vandaag even lekker kort door de bocht, het is Blog Action Day, geen Blog Nuance Day.
Flessenwater-producenten verkopen gebakken lucht. Ze prijzen hun waren aan als waren ze wonderen der zuiverheid, terwijl sommige mineraalwaters niet eens geschikt zijn om babymelk te maken omwille van te hoge concentratie aan metalen en mineralen.
En toch slagen reclamejongens, die ingehuurde waterdragers der flessentrekkers, er op slinkse manier in om U en mij bijzonder milieu- en portemonnee-onvriendelijk te laten handelen. Want we hebben allemaal toegang tot een alternatief dat 100 tot 500 keer goedkoper, veel milieuvriendelijker en minstens even gezond is; kraantjeswater.
Kijk naar onderstaande YouTube, bekijk die mooie infograph hiernaast even in detail en koop morgen een mooie glazen karaf om ‘s morgens met kraantjeswater te vullen. Geef uw water gerust een mooie klinkende Franse naam, dat doet drinken. Eau Futée misschien?

The Story of Bottled Water

Enkele bronnen:

Ik ben 15 jaar

Ik ben 15. Het is te zeggen, dat is mijn internet-leeftijd. Ik vond immers net het bewijs van m’n eerste online activiteit, diep begraven in de Usenet-archieven van Google Groups. Op 12 Juni 1995 had ik blijkbaar problemen om met de Dcom-modem in m’n 486DX2 met Trumpet Winsock een verbinding te maken met de modem-pool van de universiteit van Gent. Het moet zijn dat ik dat toen heb kunnen oplossen, want volgens diezelfde ex-Deja News-archieven postte ik van 1995 tot 1997 af en toe bv. soc.culture.belgium en be.comp.
Alhoewel ik m’n eerste html-experiment niet meer terugvind, wordt m’n eerste echte homepage, die van 1996 tot 1999 online stond op http://www.belgonet.be/~frank/, wel voor het nageslacht bewaard op de fantastische Internet Archive’s Wayback Machine;

Vanaf 2002 had ik een shell-script dat elk uur rss-feeds binnenhaalde en met rss2html.pl uit xml-rss omzette naar html om m’n homepage te produceren (eerst nog op http://belgonet.be/frank, later op http://e-cafe.be/frank) en ook dat zit proper opgeborgen in de archieven van de Wayback Machine:

Op 28 april 2003 schreef ik m’n eerste blogpost op een zelf geïnstalleerde Nucleus, daarna kwamen de Telenet Blogs en m’n korte verblijf op WordPress.com om uiteindelijk op m’n eigen blog.futtta.be uit te komen. En die persoonlijke online geschiedenis hou ik liever zelf bij, in m’n eigen blog-archieven. Want ge kunt zoiets niet alleen overlaten aan Google, toch?

WordPress stats oddity

A couple of months ago I removed Google Analytics from this wee little blog, but I still use the less sophisticated WordPress.com stats plugin to follow up on what is being read around here. Loading the stats-page in my Android-browser is far from optimal (it uses Flash to draw the charts and it is a pretty big page), so I was pleased to read that version 1.3 of WordPress for Android features a stats-section. But the reports don’t work, I just get “No stats data found, please try again later”.
Now while playing around with the stats API over the weekend, I noticed some unusual things:

  • “blog_uri=futtta.wordpress.com” works
  • “blog_uri=blog.futtta.be” results in “Error: zero rows returned.”

The API also supports blog_id instead of blog_uri and after some digging for blog_id’s I found that they are listed in (the html source of) the blog dropdown-list on your wordpress.com-dashboard stats page. And there the problem became clear: I had two blog_id ‘s for the same blog_uri (blog.futtta.be) and the first one was defunct:

  • “blog_id=2184847” results in “Error: zero rows returned.”
  • “blog_id=2185033” works just fine

As I can’t remove the entry with the faulty blog_id from the Stats DB and as I can’t change the Android WordPress app to use one of multiple blog_id’s instead of the blog_uri, I can’t fix this little bugger myself, so I contacted WordPress Support. But how did I end up with 2 blog_id’s in the database?

Over vanalles en nog wat

Een paar kleine ditjes en datjes, het moet hier niet altijd proper uitgewerkt zijn:

  • Dropbox is tof, maar niet perfect: op Android een file aan je Dropbox toevoegen doet pijn aan het gat en de Windows-versie wilt ook thuis de proxy van het werk gebruiken (auto-detect proxy werkt niet).
  • WP-YouTube-Lyte zit aan versie 0.4.1, de afmetingen van de player zijn nu configureerbaar. Het ding is al bijna 2300 keer gedownload (cumulatief voor alle versies) en op basis van de downloadcijfers na een release gok ik dat het op een site of 300 geïnstalleerd staat.
  • Van cijfers gesproken, afgelopen maandag met deze blog de 100.000 pageviews gepasseerd, dank daarvoor anonieme passant.
  • Ik draai al een week ofzo op Firefox 4 beta1 (zowel op Windows als op Ubuntu), lekker stabiel voor een eerste beta. Tabs on top is inderdaad logisch en html5 video (met WebM) op YouTube lukt nu ook, maar aan de nieuwe theme en add-on manager is nog “wat” werk. Beta2 zou eerstdaags uitkomen, maar het is nog wachten op de grote javascript snelheidswinst (waarmee FF terug dichter bij de concurrentie zou moeten komen).

En nog wat: als het gesprek even stilvalt, vragen mensen niet meer naar het weer, maar naar je mening over de slaagkansen van droomkoppel De Wever & Di Rupo. Ik zeg dan dat ze moeten slagen en dat ze dat zelf ook weten want dat het er anders niet goed uitziet voor onze portemonnee en dan verwijs ik naar een interessant artikel dat ik daarover op Apache las en het gesprek valt weer stil.

WordPress galore: plugin bugs, android app, json-api & wp 3.0

Some random WordPress-related thingies I’ve been looking into;

  • I bumped into a weird bug in css-js-booster which caused error-messages like
    <!-- Booster had a problems finding wp-content/
    plugins/css-js-booster/../../../../../../
    3f540bbd99f8ebecb73880a685db76ae_plain.css -->
    

    to appear in the html-source, although all CSS seemed to be processed. The problem was caused by PHP’s safe_mode and got fixed in 0.2.2, thanks der Schepp!

  • A few days ago my entire WordPress-blog returned empty pages, the admin-section included. Turns out that this “white screen of death” is a known issue with the WP super-cache plugin when combined with PHP APC (2 of the main components of my “Speed up WordPress“-post). As this only occurs rarely, I’ll stick to restarting Apache for now (I don’t want to switch back to eAccelerator) but I hope the APC and WP Super-Cache teams will look into this further.
  • After ditching Google Analytics, I looked into how WordPress stats are collected. Indeed, the script is sourced at the end of the HTML, thus slowing down the rendering of the page.  Let’s hope someone at Auttomatic reads Steve Soulders’ very interesting blogposts on “Performance of 3rd Party Content” and decides it indeed is time follow Google Analytics’ example and switch to asynchronous loading of the WordPress stats Javascript.
  • I installed the WordPress Android application and played around with it a bit. I don’t think I’ll be posting with it any time soon; writing on a small touch-device is a hassle, there’s no such thing as a rich HTML editor and  updating pages and especially posts or comments is very slow (because of the incredible overhead and complexity of the xml-rpc API?). Still, nice to see the WordPress-icon on my HTC Hero 😉
  • Thinking about that clumsy WordPress xml-rpc API (which I experimented with approx. 1 year ago), I started looking for a plugin that provides a rest/json api. JSON API does just that and it has great potential, but it might not be suited for public-facing WordPress installations just yet, as it allows unauthenticated users to create new posts. So you might want to wait for authentication to be added to JSON API before installing it?
  • And I just read that the first beta of WordPress 3.0 was released; wordpress and wordpress.MU get merged, menu management and a new theme are but a few of the new features. Wouldn’t is be great if functionality/ ideas from wp-super-cache, css-js-booster and json-api would be added as well?

Speed up your (WordPress-)site!

Google likes fast! Visitors like fast! So why don’t you go make your site really fast?
Suppose you just bought yourself hosting and you just installed WordPress for blogging or lightweight-CMS-purposes, how can you improve your site’s performance in that case? Easy!

  1. speed up PHP: use a caching optimizer (I use APC) to significantly speed up PHP performance (don’t bother  signing up for shared hosting with a company that doesn’t offer PHP with acceleration).
  2. cache dynamic output: install the “WP Super Cache” WordPress plugin. Configure and then forget about it; if you create/edit a blogpost, impacted pages are automatically removed from cache.
  3. optimize CSS and JS: install the “CSS JS booster” WordPress plugin, which (amongst other things) grabs all CSS and JS from WordPress and Plugins and outputs it in one CSS- and one JS-file (some plugins, e.g. Sociable and WordPress Mobile Pack, might need tweaking of the css media-attribute though) UPDATE: CSS JS booster has not been updated since 2010 and I switched to (and later even took over development of) Autoptimize for JS, CSS & HTML optimization.
  4. avoid calling 3rd party javascript: tracking (e.g. Google Analytics, which I removed), widgets (e.g. Twitter badges) or other 3rd party gadgets (e.g. AddToAny, which I removed) can slow down your site’s performance significantly
  5. optimize images: fire up your favorite photo editor and make that image just a bit smaller, use an acceptable level of compression (I end up between 70 and 80% for JPEG’s, depending on the image) and upload to smushit.com to squeeze out the last optimization-drop (example; I used a 20KB picture from Flickr, resized it to 80%, saved it with 77% compression and smushed it to end up with a mere 6KB).

The impact of a number of these steps can be measured easily; below are the response times of my blog’s homepage (the  html including css, js and images) as measured by Pingdom Tool’s Full Page Test.

  1. default WordPress (on a Linux VPS with 320Mb RAM memory): 6.5 seconds
  2. (1)  with PHP APC activated: 4.1 seconds
  3. (2) with WP Super Cache: 3.1 seconds
  4. (3) with CSS JS Booster: 1.3 seconds

So there you have it, from 6.5 to 1.3 seconds in only 5 easy steps! WordPress specific, but easily applicable to other platforms as well. Now go and make your site fast! And then go and make it even faster!

AddToAny: removing the “spy” from the share-ware

Update 02-2015: the information below does not reflect the way AddToAny works now and as such only has historical value. The comment by A2A’s developer below, explains what has been done between 2010 and 2015.
After discovering AddToAny secretly enrolls all of my blogs visitors in a behavioral marketing platform, I disabled the plugin and mailed the author for more information. He answered the media6degrees-integration was a partner-test, only providing them with non-personally identifiable data, which the company indeed can use for targeted advertising. But the good news was that AddToAny would also offer a “publisher opt-out mechanism” shortly. And indeed, last week, Pat announced the brand new a2a api and mailed me the following opt-out code;

var a2a_config = a2a_config || {};
a2a_config.no_3p = 1;

These two lines of javascript, which have to be placed in front of the http://static.addtoany.com/menu/page.js script-include, should disable all current and future 3rd party tracking. I hope the web-guys from e.g. deredactie.be and standaard.be (and there are many others) implement this as soon as possible!
So now we can opt-out from having our visitors being spied upon by media6degrees, what more could one want? Well, since you’re asking, here’s a small list of things AddToAny could really should do;

  • transparency; tell users that their visitors’ information will be shared with 3rd parties (in all relevant places)
  • documentation: show them how to “remove the spy” on the AddToAny api page (“no_3p” isn’t there)
  • ease-of-use: allow the tracking to be disabled with a simple checkbox in the WordPress and Drupal plugins

The opt-out code is a important first step and I’m sure concerns such as those voiced on the WordPress-forums will help AddToAny to further make the right decisions!

(Not) Obsessing over the iPhone

PPK of Quirksmode-fame it at it again, this time badmouthing iPhone-centric web development. A lot of people seem to take issue with his point of view, but aside from the (typically Dutch?) in-your-face bluntness, I do think he makes some very valid points. The web is about broad accessibility, about allowing as many people as possible to access your information/ application and the same should indeed be the case for mobile web development.
Sexy as a iPhone-UI mimicking webapp (based on e.g. iUI or JQTouch) might seem, it does have a number of important shortcomings:

  • it is sub-optimal for the web, even on iPhones, as the context is very different (e.g. in terms of responsiveness)
  • the iPhone-UI-approach does not make a lot of sense on non-iPhone high-end touch devices
  • it will probably not work on mid- and lower-end phones at all

So yes, web-developers should try to build mobile sites that render on as many devices/ browsers possible, as we do on the non-mobile web. Unless you’re willing to invest in several sites for different handsets, building for one specific device is a bad choice, however good the browser might be (and Safari Mobile indeed is great).
That’s why I decided to switch from the iPhone-centric WPTouch (which I installed only 3 months ago) to “WordPress Mobile Pack” for this blog. WMP offers great mobile functionality out of the box;

It includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.

When running the MobiReady test to assess how “mobile-ready” my blog is, I get a great score of 4.35/5 (page size being the main remaining issue). So thanks for ranting PPK!

Enhanced privacy for embedded YouTube

While looking into the possibility to play embedded YouTube clips with html5’s video-element on this blog, I noticed Google added an ‘Enable privacy-enhanced mode‘ flag to the embed-options. This small tweak ensures that visitors who arrive on a page that has YouTube embedded, don’t immediately get tracking cookies stuffed down their throat. Unless they play the video or click through to youtube.com, that is.
Enabling the “enhanced privacy” option just changes the URL in the embed code from youtube.com to youtube-nocookie.com;

<object width="560" height="340"><param name="movie" value="http://www.youtube-nocookie.com/v/FuGJfVAgiTM&hl=en_US&fs=1&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube-nocookie.com/v/FuGJfVAgiTM&hl=en_US&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="560" height="340"></embed></object>

The change has no impact whatsoever on the user experience, so I immediately tweaked the code of the Smart YouTube WordPress plugin on my server and I asked the developer to add the option to his plugin as well.
Yet another small step in the fight against Google’s omniscience!

AddToAny removed-from-here


Update 02-2015: the information below does not reflect the way AddToAny works now and as such only has historical value, read this comment by the developer for more info.
When looking at my blog’s performance in Google Webmaster Tools I saw Google complained of multiple dns-lookups. I knew about stats.wordpress.com, google-analytics.com (well, yeah …) and gravatar.com, but one domain in the list didn’t make sense to me at all; media6degrees.com, so I started to investigate a bit. Grepping the wordpress-, theme- and plugin-code on my server didn’t reveal anything, so I went into Firebug to see what was happening in javascript.
Apparently the AddToAny WordPress-plugin was initiating the call:

  1. add-to-any requests http://static.addtoany.com/menu/page.js (which is rather big but gzipped & cache-able)
  2. page.js in turn contains tracking (near the end of the file), by requesting an 1X1 pixel image at http://map.media6degrees.com/orbserv/hbpix?pixId=2869&curl=<encoded URL of page>
  3. media6degrees then sends the pixel and … sets multiple cookies in the process

And what’s media6degrees business you ask? Maybe they’re just providing the add-to-any author with statistics? Well, not exactly. This is what media6degrees writes on their website: “We deliver scalable custom audiences to major marketers by utilizing the online connections of their consumers.” So by using AddToAny, you’re providing media6degrees with data about your site’s visitors, which they can use to sell targeted communication to their customers.
If visitors of small-time blogs like mine would be the only ones affected by this, the damage would be limited. But AddToAny is also implemented on large local news-outlets such as deredactie.be or De Standaard Online and no doubt on some big international sites as well. Somehow I doubt those organizations know they’re feeding their visitors to media6degrees and I bet some of them would even strongly disagree.
I’m not happy about this, that much is clear. AddToAny offers great functionality, but:

  • it adds unneeded requests to my page, causing the page to finish loading later (dns-request + http-request)
  • it enrolls my site visitors in a targeted communication platform without anyone knowing (or agreeing)
  • none of this is communicated on the AddToAny website or on the AddToAny WordPress plugin page

I mailed the author about this earlier this week (when i didn’t even know about media6degrees tracking cookies yet), but got no feedback up until now and I logged an issue on the wordpress.org support forum as well. And I decided to pull the plug on AddToAny off course, replacing it with sociable, making my blog render yet another millisecond faster, while at the same time protecting my visitors from this sneaky behavioral tracking by AddToAny and media6degrees.