Over the past few months, while paid website-making work has been thin on the ground, I’ve been using my free time to churn through my to do lists and am now slowly crossing off items from the “Someday” list that I thought I’d never get round to. The latest, and lengthiest, has been to re-build my site. This is now done and it hopefully looks no different.
I had two aims. The first was to scrap the over-complicated home-brewed PHP framework and Smarty templating in favour of a more vanilla Movable Type (MT) site. The second aim was to belatedly get my head round MT v4’s tags and ways of doing things.
One of the dilemmas with making a website around any weblog-oriented CMS is how to incorporate all the bits of the site that aren’t a weblog. These days other standalone pages are no problem because MT, WordPress, etc, let you create hierarchies of pages that have little to do with all the webloggery organisation. But if you have some pages that are more complicated, integration can be tricky. This is probably why most Web 2.0 sites that have associated “site news”-type weblogs keep the weblog entirely separate from the rest of the site — integration is just too difficult to be worth it.
For me, the trickiest bit of integration is my database of what I’ve been reading. It’s dynamically generated from a MySQL database with PHP and none of its data comes from the MT CMS. So last time around I approached the site as being a PHP/MySQL site in which some of the PHP pages (all the webloggy ones) had data that happened to be generated by MT: the MT templates put all of the data about weblog entries and categories and monthly archives into PHP arrays which, when a page was viewed, were sent to the same kind of Smarty templates used by the rest of the site.
This slightly cumbersome arrangement had all the advantages and disadvantages of both static and dynamic sites:
- Much of the site required occasional rebuilds in MT. (Bad)
- Changes to Smarty templates appeared across the site instantly. (Good)
- There was a chance pages might be slow to display because so much was dynamic. (Bad)
- Because so much was prepared while rebuilding by MT there was less realtime database access than a completely dynamic site. (Good)
Which was all very well but for a personal site it seemed a bit over-engineered and so this time round I decided to approach things from a different angle: Instead of trying to fit the MT-generated content into my PHP framework I’d simply add the few necessary PHP-generated bits into a conventional MT site.
This was probably more feasible than when I last worked on the site because MT is so much more powerful. Now most of the site is purely static, generated entirely by MT, with just some of the sidebar widgets (Last.fm, Flickr, Reading, etc) pulling stuff live out of a database with PHP.
The most clunky part is how I’ve integrated all those Reading pages: these PHP-heavy pages are now Pages within Movable Type’s CMS. It feels nasty to have Pages in MT that are nothing but heavy PHP — it’s a bad interface to edit code in for a start — but it does mean that menus and sidebars and other common parts are easily integrated across every part of the site. If I started creating more sections of the site that needed to be dynamic this solution could get tiresome rather quickly.
As I say, hopefully you’ll notice no difference to how the site looks and works although I’d hope pages load slightly speedier.
In the next post I’ll write about a few Movable Type annoyances and tips I came across.