If you have a plugin to share and you:

1. register on wordpress.org
2. fill out a form to submit your plugin for inclusion in their repository
3. after confirmation upload your code (together with a structured readme-file) via svn

Then boom, automatically;

• plugin pages (for description, installation, faq, changelog, …) are created and populated with information from the readme and base php-file
• a zip-file is created containing your stable version
• your plugin is listed on the “new plugins” page

Before you know it, you’ve got a bunch of real users (wp-youtube-lyte was downloaded 128 times in 2 days) who can rate your plugin and provide you with feedback. And every time you upload a new stable version via svn, a new zip-file is created and your users will get a notification in their wp-admin pages, allowing them to upgrade by simply clicking that upgrade link. Don’t you love it when a plan comes together?

But enough raving already, got to go create that admin-page for my plugin now, as requested by a user. I’m a sucker for real users!

Possibly related twitterless twaddle:

• HTML5 offline webapps vs Google Gears Localserver
• WordPress galore: plugin bugs, android app, json-api & wp 3.0
• Stoute wordpress upgrade maakt posts van pages?

The whole thing sounds easy enough to implement, but I have some doubts that it will open the project to XSS attack of some sort. Don’t really know why, though.

We mailed a bit more about the risks of cross site scripting and then he wrote the following:

Sadly we can have malicious JS problems since cleaning up of incoming data is optional.

For an unrelated project I asked about authentication for a write-operation in the API and the reply was:

Authentication is not in the API yet. Currently you must include a session cookie along with API requests to perform a write, but the cookie itself is the one you get from logging in [in the web front end] as you would normally.

Which sounds a lot like “we support cross site request forgery out of the box” …

As with normal web applications, web API-security is an important (but complex) issue, which is not always easy to grasp. Based on a basic understanding of things, the following guidelines can go a long way into securing things both on the API-side and the client:

1. Know who you’re dealing with; disable API-access for your users by default (allowing them to opt-in), provide bullet-proof authentication and session management in the API and throw in a synchronizer token to prevent cross site request forgery
2. Never trust input from users or external systems; decide what to trust and filter out everything that’s not in that white-list (SQL-code, server-side code, javascript, and even html and css)

If you apply these basic principles to JSONP (make sure to filter the callback-parameter and set the correct content-type in your response) you’ll have a whole lot less to worry about!

More info:

• Owasp top 10 Application Security Risks 2010 (released on April 19th)
• Owasp Ajax security guidelines
• HTML Purifier: HTML filter library written in PHP.
• The risk of XSS and CSRF with JSONP (auto-translated from Swedish)

Possibly related twitterless twaddle:

• WebApp Security is mandatory (even for spammy virals)
• Warning: your computer might be infected!
• No more jsonp for Google geocoding webservice?

Well here you are, a simple bookmarklet that will display the LYTE-code when you’re on a random YouTube video page:

Want this? Then just do this:

1. drag this LYTE bookmarklet to your bookmarks toolbar
2. go to a random youtube-video page
3. click on the bookmark(let)
4. copy/paste the LYTE code on top of the page into your html
5. enjoy Lite YouTube Embeds (i.e. 17KB instead of 150KB with a normal embed) on your site!

Happy embedding!

Possibly related twitterless twaddle:

• High performance YouTube embeds
• Embedding HTML5 YouTube video with WP YouTube Lyte
• Lite YouTube Embeds in WordPress

“High Performance web sites”-guru Steve Souders is doing incredible work studying the impact of 3rd party content -and especially javascript-based services such as analytics and bannering- on the performance of a web site.

An entirely different type of 3rd party content is Flash video, especially YouTube embeds, but there are a number of indicators that these indeed do impact performance as well:

• opening a page with embedded YouTube can take some time when on dialup (or mobile data)
• YouTube-heavy pages tend to slow down older computers (flashblock or adblock anyone?)
• Facebook doesn’t really embed YouTube by default, but uses a placeholder with a thumbnail instead that is replaced by the embedded YouTube only when clicked
• Google Webmaster Tools “Site Performance” seems to sometimes single out pages with YouTube embeds (e.g. stating that there is a DNS-resolution overhead)

Indeed, when testing this simple page with some text and 2 embedded YouTube clips on webpagetest.org, these were the main results (full results including nice graphs here):

• (base) download complete: 0.356s for 2KB
• start render: 0.426s
• full page download complete: 3.005s for 315KB

There’s good and bad news in those figures. As could be expected the YouTube Flash embed doesn’t impact the rendering of the base page. But 2.6 seconds and 312KB just to display 2 video’s a visitor might not even bother to look at (I bet that the click-rate for embedded YouTube video is somewhere between 2 and 20%), that’s … sub-optimal?

So I threw some JavaScript at my computer to build an alternative to the default YouTube embed, the main goal being to build a Flash-less initial view with only a few lines of html/javascript which at some point people could copy/paste in their site just like they do now. And LYTE (Lite YouTube Embed) came into the world.

The main results when testing this LYTE-test-page on webpagetest.org (full results here):

• (base) download complete: 0.324s for 4KB (which is marginally faster)
• start render: 0.363s (again marginally faster)
• full page download complete: 0.803s for 35KB (leaner, meaner and faster!)

The code that would have to be copy/pasted (multi-line for clarity):
<div class="lyte" id="gnDh6PqWqD8" style="width:480;height:385;"><noscript><a href="http://youtu.be/gnDh6PqWqD8">Watch on YouTube</a></noscript>
<script>(function(){d=document;if(!document.getElementById('lytescr')){lyte=d.createElement('script');lyte.async=true;lyte.id="lytescr";lyte.src="http://futtta.be/lyte/lyte.js";d.getElementsByTagName('head')[0].appendChild(lyte)}})();</script></div>

The nitty-gritty (do skip if you’re not inclined to get aroused by technical details): this code attaches (a minified version of) lyte.js to the page’s head. The real work is done in that javascript-file: get all divs with class-name “lyte” (with a hack for friggin’ IE inlined), use the videoid which is in the divs’ id to fetch the thumbnail and title from YouTube, display these in a fashion which is very YouTube-like and add an onclick eventhandler to replace the fake with a real player when clicked (and remove the eventhandler to clean things up).

So using LYTE you can embed YouTube in such a way that the amount of data, the total download time and the total rendering time are significantly lower, without loosing any functionality.

And this -to conclude this long post- is what LYTE looks like (soundtrack by Nôze -- “Meet me in the toilet”, it’s Friday after all);

Possibly related twitterless twaddle:

• Lite YouTube embeds free for all!
• Embedding HTML5 YouTube video with WP YouTube Lyte
• Lite YouTube Embeds in WordPress

This example request for v2, http://maps.google.com/maps/geo?q=51,4&sensor=false&output=json&callback=parseme, results in a response containing a call to your own “parseme”-function, with the json-object as the payload;

parseme && parseme( {
"name": "51,4",
"Status": {
"code": 200,
"request": "geocode"
},
"Placemark": [ {
"id": "p1",
"address": "Brukkelen 191, 9200 Dendermonde, Belgium",
...
]})

But a month ago Google announced a new version of their geocoding webservice and the documentation for V2 mentioned that it was deprecated in favor of the Geocoding V3 Web Service. so I switched to the new API, only to discover that callbacks aren’t supported any more.

An example request for v3 http://maps.google.com/maps/api/geocode/json?latlng=51,4&sensor=false&callback=parseme results in nothing but the javascript-object:

{
"status": "OK",
"results": [ {
"types": [ "street_address" ],
"formatted_address": "Brukkelen 191, 9200 Dendermonde, Belgium",
...
]})

And that, my dear fellow travellers, sucks big time. JSON without the P means we’re back to useless proxy-scripts on our servers. So until Google lets Jason pee (sorry folks, I just had to write this) in the V3 geocoding webservice, I’ll continue using the deprecated V2 with sweet -but undocumented- callback!

Possibly related twitterless twaddle:

• Switching from Google Reader to Tiny Tiny RSS
• Persistent offline data storage without html5 webdb
• Onclick event handler in A HREF’s?

Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs, depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size).

But what if you could resize (generally: zoom out) the iframe-content to perfectly fit the available width and height, thus avoiding vertical and especially horizontal scrollbars? Well, that is exactly what squeezeFrame.js tries to do (using css zoom and -moz-transform:scale in Firefox)! Just include the javascript-file in the iframe-content page and set a few options if you want to change the default behavior (which is: zoom in/out for width only, max. + or – 5%).

squeezeFrame.js was tested successfully in Firefox 3.6, IE6, Safari4 and Chrome4, but does not work in Opera 10.5. More info (including some “known issues”) can be found on the demo-page and in the javascript-code off course.

As always; reply in the comments or contact me if you find bugs or have problems.

Possibly related twitterless twaddle:

• 5 tips to tackle the problem with iframes
• Fix iframe-positioning problem with frameMagic.js
• 5 valuable Cufón tips

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)
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!

Possibly related twitterless twaddle:

• blog.futtta.be going mobile with WPtouch
• WordPress galore: plugin bugs, android app, json-api & wp 3.0
• Lite YouTube Embeds in WordPress

So if you happen to have problems with the positioning of 2nd (or later) pages in iframes (due to the top part of the iframe not being visible in the ‘viewport’), just upload frameMagic.js to your webserver and add the following to the head of your html to ease your iframe-blues;

<script type="text/javascript" src="path/to/frameMagic.js"></script>

Optionally you can specify which iframes are to be treated this way (excluding the other ones) by doing

<script type="text/javascript">
var fM_conf="iFrame1,iFrame3";
</script>

You can find more information and examples on http://futtta.be/frameMagic.

Possibly related twitterless twaddle:

• 5 tips to tackle the problem with iframes
• Avoid iframe-scrollbars with squeezeFrame.js
• HTTP upload MIME type hell

1. Google loves doesn’t hate iframes done right!

Although Google is rather vague about the subject, iframes and SEO do not have to be mutually exclusive. But you will have to make sure it’s your main page that shines in search results, not the iframe-content. The main page (where the iframes are defined) has to be more then a mere placeholder for one or more iframes. Migrate as much information (titles, description and other text) from the iframe-content to your main page, which should describe what goes on in the iframe(s). Use the iframe title-property and insert alternative content between opening and closing iframe-tags. A quick example:

<h2>Calculate your mortgage rate</h2>
<p>Calculating your mortgage rate was never easier; just enter the loan-amount and the duration below!</p>
<iframe src=”http://page.url/iframe-container-page1″ …  title=”Calculate your mortgage rate here”>Your browser does not seem to handle frames properly, but you can calculate your mortgage rate <a href=”http://page.url/iframe-container-page1″>here</a></iframe>

2. Own the stage

Avoid visitors viewing the iframe-content out of the context of the main page (e.g. because they followed a link in search-results). Add javascript to the iframe-content to check if it is accessed stand-alone and redirect to the main page (or explain and provide link to the main page) if that is the case.

if(self.location==top.location) top.location.replace('http://contain.er/page-url/here');

3. Don’t draw blanks

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no? The (hackety-hack) solution; tell the browser to scroll to the top of the iframe each time a new page in it is loaded, by calling the function below (with the iframe id as parameter) when the iframe’s onLoad event fires:

<script>
var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
}
</script>
<iframe id=”iframe” onLoad=”frameMagic(‘iframe’);”>

Update: the above code has been updated heavily, check my frameMagic.js blogpost

4. Your users really do need scrolling=”auto”!

Help your visitors access all iframe content no matter what configuration they’re using: don’t disable the iframe scrollbars! Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size). Instead define a reasonable iframe-width and height, make the iframe-content width flexible (fluid) and let the browser decide if a vertical scrollbar is needed.

Update: squeezeFrame.js might be a solution to your scrollbar-woos

5. Smart sizing without scrollbars

If you really really really don’t want scrollbars, if you want your iframe to adapt to the size needed by the iframe-content automatically and if you’re not afraid to experiment; there are some nifty javascript-solutions that allow the iframe-content to communicate the required height to the main page. Check out Framemanager (stand-alone, has some issues though) and the JQuery-postmessage iframe-example (which does everything in javascript, which isn’t really ideal from an accessibility point of view).

Conclusion: iframes aren’t necessarily evil (either), but you’ll have to make a small effort to render them somewhat SEO- and user-friendly.

Possibly related twitterless twaddle:

• Fix iframe-positioning problem with frameMagic.js
• Avoid iframe-scrollbars with squeezeFrame.js
• Embedding YouTube HTML5-video with newTube

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!

Possibly related twitterless twaddle:

• New powerful iPhone with Flash preinstalled in q4?
• My Mobile bookmarks
• Jakob Nielsen on mobile web usability