The problem, of course, is that not everyone is on the same social network. And you might not want to be on any of the social networks that I’m on. Or you might not trust any of those companies. Enter ping.fm.

ping.fm serves as a central point for me to blast out my navel-gazing, mind-numbingly boring status updates to a variety of services (all of the ones mentioned above and more like Plurk, MySpace, Pownce, LinkedIn, Tumblr). This means when I make a status update at ping.fm, it gets fanned out to all the sites I’ve ping-enabled (of course I have to give them credentials for each site).

All of this is great but not totally innovative, it’s just another layer of madness above the existing, silo’ed madness. And it doesn’t solve the fragmented two-way conversation problem (replies on Twitter stay on Twitter, etc). But what caught my eye this evening was the ability to fan my ping.fm updates to custom URLs. This means I can set up a PHP page on my own website and ping.fm will send the status updates to that page also. This opens up some interesting possibilities.

So I did just that. I now have a microblog/status feed on this site if anyone cares when I brushed my teeth or if I’m late for a train. Be the first to know!

How it works: I use ping.fm to post my status and it is fanned out automatically to Facebook, LinkedIn, Twitter, identi.ca and codedread’s custom PHP. That PHP takes the status and adds it to a static Atom file on my site.

So now that I’ve got a microblog feed that’s disentangled from any one particular social network, I’ll probably add some code to my site to display the latest status from my microblog feed somewhere.

Oh and if you don’t like the funky character in the URL then you can also use this one. They both point to the same location.

One request to ping.fm: Please support OpenID!

I like the idea of having a seamless transition between my blog and website. so this evening I decided to flip the switch on the blog, even though the WordPress theme is very much a work-in-progress. I still need to figure out what to do with the sidebar, but I can always hack away on the theme on my old blog installation internally and publish updates once they have been verified on a set of decent browsers (Firefox 2+, Opera 9+, Safari 3+).

I use SVG in a bunch of different places: inline as decoration around the page (the blue gradient and the title) and referenced (via <object>) for the icon menu (at the top) and W3C validation badges (at the bottom). Once I nail down all the particulars, I’ll compress menu.svg and serve only menu.svgz so it can be neatly cached (at roughly 15kb). But I’ll keep menu.svg around for web developers to look at if they’re curious.

Work on this led to a few bugs reported at Mozilla, WebKit and Opera – but no show stoppers. The best user experience is in Opera 9.5. For the first time, I’m using declarative animation (in a simple way) for icon mouse-hovering. Firefox and Safari users miss out for now, unfortunately.

It turns out, as Shelley has mentioned, that the best developer experience to work on XHTML is also (by far) Opera. Instead of Firefox’s “yellow screen of death” we’re greeted with Opera’s “light grey screen of mild achiness”. Instead of cryptic messages about unexpected tags, the element which failed to be terminated and the tag that broke the XML parsing are highlighted for you.

I encountered some funniness when I tried to validate my pages on the W3C Validator. Apparently it thought they were text/html pages. So I had to add a little catch in my PHP content negotiation code to force application/xhtml+xml when I want to. Anyway, the PHP content negotiation code looks like this:

You might find some of my old site themes amusing, sad, or boring:

• 2004-04 – Early static HTML, table-based layout, no CSS.
• 2005-04 – Reworked into a templated PHP site. Eventually I turned it from table-based to CSS layout-based (snapshot is table-based).
• 2006-01 – Theme from 2006. Using CSS for layout. Embedded SVG aqua buttons for navigation menus. All modern browsers now support the features I was using on this page.

Matt from WordPress disses the heavy-handed move to PHP5. I personally like PHP5 better than PHP4, though my site was using PHP4 for everything. I notice Matt says “there isn’t a released PHP app today that isn’t PHP 5-compatible”. But I don’t think this can be true, unless he means PHP apps that matter to him. They point to this page which describes the differences between PHP 4 and 5, but I think something huge is missing from this page: DOM manipulation. There is a potentially big change to web apps out there that use DOM XML.

The only thing I had to do when migrating was to change my DOM XML function calls to use DOM.

• DOM XML will “never be released with PHP 5″.
• DOM is a PHP5-only feature.

These changes affect every line of code that used a DOM XML function, but the changes are pretty trivial, especially if you already know the DOM. XSLT handling is also not backward/forward compatible, from what I understand.

But why does that PHP page neglect to mention this? This was pointed out in 2004 by Justin Gehring, but the page fails to have been updated as an official notice. Alexandre Alapetite has provided a module that, I think, eases this transition (Disclaimer: I have not used this module because I rewrote my PHP for PHP5).

In all likelihood, I am missing something obvious here – so please chime in and put me on the clue-train. Do people typically not manipulate the DOM in PHP?