For quite some time now, I’ve been attempting to devise an easy method to allow me to use the template engine of my choice for MovableType, as opposed to using theirs. The biggest reason for this is to save the time required to “Rebuild” for an insignificant cosmetic change. The secondary reason is to allow other pages (not managed by MovableType) to use the same layout templates so that, a change in one template file would change the look and feel for the entire site.
I’ve considered so many options. Of all of those, the following seemed the most promising:
- Access the Database directly from PHP
- Have MovableType output XML
I’ll make MovableType output the entries in XML. Then I’ll use xmlParser to read them in and make them available to me. I’ll decide which entry to read in by looking at $_SERVER['PATH_INFO'] an no one will be able to tell otherwise.
Admittedly, this was my best idea yet. The storage method makes sense. The access method makes sense. The URLs stay clean. If data is needed to be represented a different way (perhaps I desire to have a “most recent comments page” some day), I merely add a quick template to provide the data somewhere accessible, and make methods to retrieve it. The only real reason I haven’t done this is because it’s quite a bit of work.
In order to get the advantages I seek I need to make certain that, at the very least, my “Individual Archives” provide all the data I require. Otherwise, when I learn that I didn’t include something that I wanted, I have to rebuild again anyway. This concept, however, does start to get a bit thick when one starts to think about “Master Archives”, “Category Archives”, and “Date-Based Archives”. All in all, it can be done, it’s just a lot of work. Probably less work to simply write my own software.
I’ll write PHP scripts that access the MovableType database directly. I’ll drop my scripts into place and turn off all of MovableType’s archiving so that, essentially, it doesn’t output any files. In other words, I’ll use MovableType as an interface to the database, but my readers will actually never be using it.
This idea went out the door because I figured, if I’m going to do that much work, I may as well write the admin interface as well and rid myself of MovableType all together.
What is funny to me is that, in all of the thought I put into this, there was one option that I just never considered. Brad Choate writes tons of MovableType plugins and interesting hacks and tips for getting MovableType to do things it wasn’t written to do. Last October, he wrote about yet another way to do exactly what I’ve been trying to do: have MovableType output small PHP scripts that merely set native PHP variables equal to the data representing each post, and then calling a function that executes Smarty to render the page.
I don’t particularly like his idea any more than I like any of the others that I had. His solution still doesn’t address MovableType’s comment system and the templates embedded within that portion of it. MovableType uses baked content (pages that are generated and stored on disk) for the weblog, but fried content (pages that are built dynamically everytime they are requested) for comments and TrackBack listings. Additionally, the whole idea still becomes overly complex once you dig into “Category Archives”, “Date-Based Archives” and “Master Archives”.
My point is simply this: even when you think you’ve exhausted all possibilities, you haven’t. There is always one more option. There is always one more possibility.