blog.futtta.be going mobile with WPtouch

blog.futtta.be goes mobileAfter reading how wordpress.com implemented not one but two mobile versions for all of their 4.5 million hosted blogs, I decided to install the same WPtouch-plugin on this very blog as well.
Installation and activation of a new plugin is very straightforward from within the wordpress admin-screens. In the case of WPtouch (and every other plugin that produces alternatives views of the same content on the same URL) however, there is a conflict with the WP super cache plugin which needs to be resolved by basically telling the cache-plugin to not handle request from browsers with “mobile” useragent-strings.
After that WP super cache config hack, your blog has a mobile section which you can tailor to your needs in the WPtouch config screen. These are some of the settings I changed:

  • removed categories and tags from the header (didn’t seem to work anyhow)
  • added most of my pages to the dropdown menu in the header
  • excluded my lifestream-digest posts from being displayed
  • removed author from and added excerpt to individual posts

If anyone visits this site with their mobile browser and stuff doesn’t work, your feedback is welcome!

HTML5 offline webapps vs Google Gears Localserver

Google Gears is a fantastic browser plugin; it allows a developer to create applications that run while offline, syncing with a server when online. Two great examples of the power of that mechanism are Gmail (both the “desktop browser” and the mobile Android-version) and Mindmeister (only while in trial, for paying Mindmeister-accounts after that period). The problem with Gears however is that it’s a plugin and not a lot of people have it installed: only Chrome-users have it by default. And that’s where HTML5 comes in; one of the areas where the new spec offers vast improvements over html4/xhtml is the ability to take webapps offline by allowing a developer to store files for offline usage and to write data to a local, browser-embedded database. Both Safari 4 and Firefox 3.5 support these features, so maybe HTML5 makes Gears already redundant in those browsers with more to come?
I haven’t gotten around to experimenting with offline databases yet, but I did already look into offline files. At first sight, Gears Localserver and HTML5 Offline Webapps indeed seem very similar; your html-page points to a manifest-file which contains a list of assets (pages, images, css, js, …) that the browser has to store for offline usage. Easy enough, no?
To get a better feel of how offlining in HTML5 works, I decided to try to write a simple WordPress plugin to replace its ‘Gears Turbo’-option. Turbo (which you can find in the Options-menu) essentially stores 1Mb of files locally, to speed up delivery of the WP-admin pages. To make a long story short; my plugin didn’t work. For starters, by default requests for non-local data are blocked, but it’s easy enough to unblock network access by adding “NETWORK:*” (with a newline before the wildcard) to the manifest. But more fundamentally; HTML5 Offline Webapps not only stores the files specified in the manifest-file, but also every html-page which points to the manifest (see my test here). There’s no way you can exclude those “master entries” from being stored. So if pages are stored, that means they have to be static and that all dynamic parts should be handled by javascript (fetching data using ajax and updating your page with it). And that, my friends, is clearly not a use-case that is applicable to WordPress admin-pages.
So HTML5 Offline Webapps is no drop-in solution to speed up delivery of dynamic pages, you’ll still need Gears to take care of that (or rely on old-fashioned carefully configured expiry- and cache-headers). But, as Google proves with the iPhone-version of Gmail, Offline Webapps combined with a HTML5 offline database can work miracles if you use it the correct way.

http://blog.futtta.be/2007/04/06/cache-header-magic-or-how-i-learned-to-love-http-response-headers/

WordPress 2.8 loves your proxy

Up until version 2.7.1, running WordPress on an intranet was a real pain in the ass. It connects to the outside world to look for updates, to check comments for spam (using Akismet) or to fetch RSS-feeds for widgets if you configured those on your blog, … But as you typically don’t have direct internet-access on an intranet and as there was no way of letting WordPress know about a proxy, your blog timed out while it was trying to fsockopen those external sites.
chet bakerBut that was yesterday, because the recently released WordPress 2.8 “Baker” (which is chock-full of new features) has support for internet-connections through a proxy, thanks to its great HTTP API. Don’t bother looking for it in the admin-screens, you’ll need to configure the proxy-settings in your wp-config.php.
Here’s what you’ll have to add (values are examples which you’ll have to replace with settings for your environment off course):

define('WP_PROXY_HOST', '192.168.22.1');
define('WP_PROXY_PORT', '9099');

If you need to authenticate to access the proxy you can add your credentials this way:

define('WP_PROXY_USERNAME', 'frank');
define('WP_PROXY_PASSWORD', 's3cr3t');

You can also exclude requests for specific hosts from going through the proxy:

define('WP_PROXY_BYPASS_HOSTS', 'localhost, blog2.corpintranet');

And finally you can block all outgoing requests by default and add domains to a whitelist to only allow those to connect:

define ('WP_HTTP_BLOCK_EXTERNAL', 'true');
define ('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org, akismet.com');

Off course some WordPress-plugins do not use the HTTP API yet (e.g. Lifestream and wp-security-scan rely on Simplepie, which does not use the proxy-aware wp_remote_get-function), so you might have to be careful when installing plugins that need internet-access.

Put your WordPress-categories back in the tagcloud

When blogging, tags and/or categories allow you to classify your posts. The taxonomy you create that way, allows searchbots (and human readers) to better understand what the post is about and to find related posts.
category cloud widget config screenshotEver since the release of WordPress 2.3 (in sept. 2007), you can specify both categories and tags for your posts. More or less following the ideas put forward by Lorelle-on-WordPress, I use categories as the main classification-method (putting posts in a hierarchical, directory-like structure) and add one-off keywords as tags. The only disadvantage: as tags are one-offs, the default tagcloud-widget in WordPress generates a dense put useless heatmap.
If you’re in the same situation, you might benefit from this little WordPress-plugin I wrote (well, …copy/pasted, actually, 80% is code straight from the original WP-tagcloud widget) to solve my tagcloud-woes. Once unzipped in your plugins-folder, “category cloud” will provide you with a widget which can not only generate a “tagcloud” or a “catcloud”, but also a “cat-and-tagcloud”. And because the default “general”-category might skew your catcloud-results or because you might prefer to have that NSFW-tag not show up, you can exclude tags and categories from being shown as well by entering their ID in the appropriate input box.

“Lifestreaming, across my universe”

Lifestreaming is where it’s at, so here I am, aggregating all my stuff (Google Reader shared items, my Youtube clips and favorites, my Facebook status and my blogposts) into one place. I tried sweetcron a couple of weeks ago, but for some reason it didn’t feel “ready” yet (or maybe I didn’t want to invest to heavily in it). I recently installed a simple WordPress plugin which seems to be doing the trick very well. Sweet indeed!
Next up; something to handle multi-language blogging a bit better, but now for something completely different (The Firm, Star Trekkin’ on Youtube);

The Firm - Star Trekkin'

WordPress 2.6 svn-upgrade; ouch!

WordPress 2.6 has been pushed out the door at Automattic and it contains some exiting new goodies as usual. So I fired up my trusty upgrade script, but got an ugly php-error when accessing the database update-pages:

Parse error: syntax error, unexpected T_SL in wp-includes/widgets.php on line 464

Turns out that the wp_widget_search-function in wp-includes/widgets.php included some remnants of an SVN-merge. Don’t know if it was a sync problem at my side or if the faulty code was on the SVN-server (it isn’t now), but I ended up copy/pasting the correct function from a fresh tar-ball I downloaded.

The WordPress-on-an-intranet nightmare

[UPDATE june 2009: this is solved in WordPress 2.8]
wp for dummies book coverHaving a fair amount of experience with WordPress installations and configuration, I wanted to install trusty old WP 2.5.1 on an idle desktop (winXP+xampp) at work to do some blogging on our intranet. The installation itself went smoothly (how hard can unpacking a zip-file be) but after some time the damn thing stopped working, producing nasty timeout-errors caused by a.o. wp-includes/update.php and wp-admin/includes/update.php.
The problem is that WordPress tries to open an internet-connection (using fsockopen) to see if updates are available. Great, except when you’re trying to run WordPress on an intranet behind a proxy without a (direct) connection to the internet. After some unsuccessful fiddling in multiple WordPress php-files, I ended up disabling fsockopen in php.ini (disable_functions)!

Disabling! Fsockopen! In php.ini! Just to have a working WP?

I mean, come on guys, why doesn’t WordPress provide configuration options where you can specify if and how (what type of proxy, what address to find it on, …) it should try to connect to the internet? I even made this truly amazing UI mock-up which you guys can just like copy/paste straight into your code;

_______________________________________________________________________________
How should WordPress connect to the internet to check for updates?
(*) Direct connection to the internet (default)
( ) Use a proxy:
    Proxy type:     (*) http ( ) socks
    Proxy URL:      ___________________________________________
    Proxy User:     ___________________________________________ (optional)
    Proxy Password: ___________________________________________ (optional)
( ) No internet connection available (WordPress won't be able
    to warn you about updates!)
________________________________________________________________________________

_
😉
Pretty please?

Verhuis je blog zonder twee keer na te denken!

Het leven op de elektronische snelweg kan zwaar zijn: Koen Fillet was bijna een volledig jaar zijn kluts kwijt omdat de Leeskamer-blog van naam én URL was veranderd. Hij sprak deze ochtend zichzelf, Jan Coucke en de wereld dan ook enigszins vermanend toe;

“Verander je ouwe vertrouwde blog niet zomaar van naam en van adres. Denk twee keer na, want je lezers ben je kwijt.”

Hij heeft gelijk natuurlijk; door een ondoordachte verhuis kun je heel wat lezers rechtstreeks (rss-volgelingen of echte trouwe bezoekers) en onrechtstreeks (zoekrobotten en bezoekers die via zoekmachines op je site komen) verliezen.
Beter twee keer nadenken dus. Of gewoon verder lezen, dat zou U ook kunnen doen. Want om mijn bloggende medemens al dat dubbel gepeins te besparen, zal ik hier de truuken van de foor opsommen, zoals ik die gebruikte bij mijn verhuis van het wordpress.com-platform naar een eigen wordpress.org-installatie.
Op je oude blog zou je volgende dingen kunnen doen:

  • je verhuis ruim op voorhand aankondigen (met url natuurlijk).
  • Van de laatste blogpost maak je natuurlijk een duidelijke doorverwijzing naar je nieuwe blog, met link en al.
  • Je zorgt er dan voor dat die laatste tekst het enige zichtbare artikel is voor wie op de homepagina komt.
  • Laat je oude blog voor de rest gerust staan, maar kleed hem wel grondig uit:
    • Exporteer alle teksten (inclusief commentaar).
    • Laat in je (populaire) posts enkel de eerste paar zinnetjes staan en link voor het vervolg door naar je nieuwe blog.
    • Verwijder commentaren en zet de commentaar-optie uit.
    • Laat zoveel mogelijk interne links direct naar je nieuwe blog verwijzen.
  • Publiceer de rss-feed van je nieuwe blog op je oude blog.

Op je nieuwe blog ga je dan bijvoorbeeld op deze manier aan de slag:

  • Importeer alle blogposts (inclusief comments) van de oude versie.
  • Pas interne links in die geïmporteerde tekstjes aan om te voorkomen dat je lezers terug naar het verleden worden gekatapulteerd.
  • Publiceer de eerste dagen gerust een artikeltje meer, zodat je lezers zich direct thuis voelen.

Vraag voor de rest aan de eigenaars van sites waar je blog vermeld wordt om dat adres aan te passen. En niet onbelangrijk voor je rss-lezers tenslotte: gebruik feedburner om je feed te publiceren. Nu, direct, weken, maanden en jaren voordat je verhuist al. Het is een fantastische gratis dienst en op het moment van de waarheid moet je dan enkel je feedburner-instellingen aanpassen en al je rss-volgelingen verhuizen mee zonder dat ze daar zelf iets voor moeten doen.
Misschien een beetje neurotisch allemaal en “your mileage may vary“, maar in mijn geval werkte dat wel goed. Regelmatige lezers verhuisden dankzij de aangepaste feedburner-feed automatisch mee. Wie m’n blog op de gewone manier bezocht, ziet op m’n uitgeklede wordpress.com-blog dat ik verhuisd ben èn direct ook links naar mijn laatste posts op mijn nieuwe stek. Zoekrobotten worden via m’n oude site op allerlei manieren doorverwezen naar m’n nieuwe onderkomen en vinden daar direct ook inhoud om te indexeren. Zolang Google nog resultaten uit de oude blog toont (en dat zal nog een tijdje zo zijn), kunnen toevallige bezoekers daar nog proper landen om daar dan naar m’n nieuwe site doorverwezen te worden.
Dat was het zo ongeveer denk ik, veel meer valt daar niet over te vertellen. Succes met je verhuis!