@lindsay.at

I've spent a lot of the last couple weeks looking at OpenID and related technologies more in detail. I had already placed my claim at ClaimID, but I've been looking more into the technology in the large. It just seemed to be in the air lately, along with some work reasons. I was pleasantly surprised to find that FluxCMS (here, on this site) is an OpenID server itself. Additionally, there was a MicroID function written within the site, but no integration. After a first draft and some suggestions from Flux-meister chregu, here's a small patch to insert into the master.xsl template:

<meta name="microid">
<xsl:variable name="fullRequestUri">
  <xsl:value-of select="php:functionString
       ('bx_helpers_uri::getRequestUri','')" />
</xsl:variable> 
<xsl:attribute name="content">
<xsl:value-of select="php:functionString
                      ('bx_helpers_openid::microid',
                       'me@mydomain.tld', 
                       concat(substring($fullRequestUri,0,
                            string-length($fullRequestUri)),  
                          translate(substring($fullRequestUri
                              string-length($fullRequestUri),1),
                                   '/','')))"/>
</xsl:attribute>
</meta>

Perhaps it's a bit cheeky to diss a CMS on a blog that doesn't use it, but I use WordPress, even if it's not on this site. My "big time" blog is moving house, from a dedicated server that I more-or-less maintain (in my wife's office), to a shared server on TextDrive. Performance certainly has taken a big hit, but I can pretty much guarantee that it can scale to higher traffic better and that it won't be taken out nearly as often or as long by random downtime.

I spent huge swathes of the weekend trying to get the site's theme working in a way that I liked. The K2 theme boasts of being a flexible theming framework, allowing you to do what you like in CSS, and "baking in" support for several popular plugins, lowering the need to tinker with the core theme files even further. The promise didn't quite match reality. K2 is an attractive, clean theme, and I like the fun, AJAXy things you can do with it, but it still has a set structure and strong ideas about how elements are displayed. Unfortunately, I was trying to match a known structure and layout, and had strong ideas about what the design should look like, myself. WordPress was good in allowing complete flexibility, but in the process I completely changed the internals of the infamous WP-loop, meaning I have to do a lot of work if ever I want to upgrade the K2 theme.

(This makes me wonder about plugging XSLT into the WordPress theme hierarchy. You can radically rewrite elements using that. So I'd imagine a master Xhtml document being created by the loop, and optionally doing a run through an XSLT stylesheet before being shipped off to the reader. Obviously, I'm a bit swayed by this site's architecture, and it's simply moving the problem to another place, and not entirely avoiding maintainability problems (and creating further performance issues as well). But, computer science is nothing if not the art of moving problems around... Anyway, that's an aside to explore later.)

What really let me down, however, was the complexity of the master CSS file for the K2 theme. The default theme has a lot of attractive, complex, subtle things going on, and the CSS is a mess to deal with. First off, if the makers of K2 want to encourage CSS-only styles, they would do well to strip out the unnecessaries in the base CSS, and move the attractive blue Kubrick-2-like theme into a default style of its own. There were far too many settings to override, deeply buried within the CSS inheritance hierarchy (I had to impose my choice of font family at least four times, manually, for example).

Quite contrary to K2's implied promises, I ended up with a cluttered, fairly arbitrary stylesheet that was a series of hacks. I know at least part of the blame falls on my empirical, hack-y CSS coding method. Part of it also falls on the state of CSS, and the tools we have to deal with it — I think there must be a better way. (Does anyone advocate grouping by properties instead of elements? All the elements of the same color could be named once, and then all font styling is done that way, etc. I see flashes of this in exemplary styles, but it isn't consistent. [I see google brings up one page, originally from 1996...])

So, since I must count you as one of my dedicated fans (especially if you've read this far), I can point you to the site as a preview, because I'm sure it's not going to be overrun by a Slashdot effect from here: mediadescri.be. I like the URL a lot. I've been sitting on it for the better part of a year.

The underlying CMS engine, which should be invisible to most users, is the Flux content management system. (It's based on Popoon, a PHP-based clone of Apache's Cocoon.) I mention it because already it's starting to pay for the fairly small time investment to learn it: the XSLT/XML processing pipeline on the back end has proven its usefulness in adapting some XSLT stylesheets I had lying around for my work. To my surprise, the localisation that I had built into the stylesheets worked in the CMS with no extra effort. That's the sort of project I like: a fairly small bit of glue that multiplies the benefits with everything around it....