I was going to rant about the decline of technical support last Saturday, but I got side-tracked by Future-proof URLs and Cruft-free URLs in Movable Type.
I don’t necessarily share their goals, however. I’m not ready to label .html as cruft, unlike .php or .aspx it is not leaking an implementation detail. I’m not concerned about file extension changes, either — even a RegEx moron like myself can craft an .htaccess to deal with that problem.
My primary goal was to improve the quality of ads that Google’s AdSense serves for my site. Ads related to syndication and weblogs seem to be the default for my site, especially with shorter entries. Those ads aren’t adding value to my site, instead they make me look bad.
I realized that AdSense was probably serving those ads because of the left side of my site — all of the Navigation links contained /blog/, and there is a Syndication section. For weeks I silently cursed Google for not being smart enough to exclude content that never changes across pages and not providing a way to manually exclude content within a page. To solve this problem myself I would have to stop serving Syndication links to Googlebot and eliminate /blog/ from all of my URLs.
Re-architecting my site just for AdSense would be silly, of course, but being able to serve variable content fit in with another goal of mine: to provide an excellent browsing experience for handheld devices.
I decided to use PHP for my entire site, minus the .php extension. I liked the Future-proof URLs in Movable Type method of using directory URLs, as it provides a convenient place to store other entry-specific content (moblog images, comment feeds, etc), but my MT installation already has a couple of tweaks that make upgrades a royal pain. Thanks to Step 1 of Cruft-free URLs in Movable Type I realized that adding DefaultType application/x-httpd-php to an .htaccess file would allow me to use PHP without a file-extension and free of side-effects. I lose the directory benefit, but I’ll find a way to go on living…
Then I moved on to figuring out how I should use PHP to alter my content. Using MT templates to produce pages that mixed content with PHP script seemed dirty to me, so I opted to keep them separated. My main Individual Archive template is now a two-line PHP script that simply passes the Entry ID to an function in a require_once file. For the content itself I decided that RSS 2.0 was the most appropriate format, and a secondary Individual Archive template publishes the entries to /xml/entry-<$MTEntryID$>.xml.
I decided to use XSLT to transform the RSS to XHTML, which posed some challenges:
- I know jack about XSLT, having only used it twice for trivial one-off transformations.
- A few of my entries still produce invalid XML.
- RSS namespaces don’t exist for all of the information I need.
Much time was lost while figuring out how to prevent namespace pass-thru and JavaScript butchering (exclude-result-prefixes and <xsl:comment> w/ CDATA), but fixing my invalid XML was a bigger problem. The Validable plug-in was failing me in certain circumstances, but I know longer recall what they were. I eventually added Bloxpert to the mix and tweaked Validable to only fix entity-encoding issues. Tidy now thinks that all of my XML is valid, but I still have some formatting issues with entries that don’t use convert_breaks.
On the RSS front, Phil Ringnalda’s blogcomments and RSS Archive Module for Movable Type are helpful. I’m still trying to figure out the best way to handle received TrackBacks pings; the TrackBack Module for RSS overlooked them, and the mt-tb.cgi model of straight RSS <item>s doesn’t work for this scenario. I sent a message to rss-dev, hopefully I won’t have to invent that wheel.
As of the wee hours of this morning, the PHP + RSS + XSLT system is live. Once my RSS format is finalized I will convert the Daily Archives over, then I will do some things to further leverage PHP. Funky caching doesn’t quite fit this implementation, but I’ve got something similar in mind. I’m also envisioning some neat RSS tricks at the individual-entry level.
