When I have more time, I need to check out this tutorial by Jaza on how to modify Drupal to make a nice organization system.

I've rebuilt kief.com using new software, a PHP-based content management system called Drupal. I didn't have any particular problem with my old software, Movable Type, I changed because I wanted to learn how Drupal works. Movable Type is designed for use in a weblog format, with backwards-chronological list of posts, which is fine for kief.com. But I've been wanting to create a new website which will have a more complicated format which I think Drupal is well-suited for.

The choice of Drupal is significant for me in that it is written using a language/technology I haven't worked with before, PHP. This isn't out of any desire to learn PHP, I would actually prefer to use Java, which is what I work with professionally. However, I've been farting around with Java-based content management for years, and it's actually been a big obstacle for me starting the kind of website I would like to have, for several reasons.

Part of the reason I haven't been able to get a Java-based, content/community-oriented website going is exactly because I am a Java programmer. Whenever I have started on one of these projects in the past, I inevitably get bogged down fiddling with the software, and usually end up wanting to write big chunks of the system myself. The software is never quite done the way I want it, so I spend all my time coding. Since I don't have gobs of free time for this kind of project, I never get anywhere with it. Since the projects I want to do are usually building websites rather than writing software, this is counter-productive.

This problem is exacerbated by the state of Java content management systems. There are plenty of frameworks out there that can be used to build a content-oriented site, but nothing that you can just drop into place and start using. I particularly like JPublish, and also Daisy, but either one (or both) would take a lot of work to get going with.

The reason I've started playing with Drupal is that it's oriented towards the type of site I would like to start - mixing community (blogs, forums, comments), and old-style traditional content. It has some fairly large gaps - it doesn't handle images very nicely yet, and it seems awkward to create pages that collect different types of content in useful ways, such as section hubs and monthly archives. But it's technical architecture looks very clean, solid, and extensible, and there is plenty of activity with modules that can do the kinds of things I'm interested in.

Of course none of this actually guarantees I will get a new site underway any time soon, there is still plenty of work to do.

I'm a bit slow on this one, but Anthony Eden has reacted to some of my earlier comments on JPublish by publicly mulling over his plans for 2.0. He's going to come up with an architecture for storage, something it lacks now, and hopefully a way to get content into the system. He's also thinking about what modules it needs.

JPublish's model for finding data, templates, and meta-data is very nice, but there are no tools for entering any of these things, other than by plopping them into the file system. That's the best way to manage data as files, since there are plenty of tools available. But for those who want to keep a lot of content in a database, we need some tools to manage that content.

One thing that will be interesting to see is whether Anthony moves over to a JPublish-based blog package at some point. He's a big booster of Roller, which looks like it is on the way to becoming a primo Java blogging package, but JPublish would be a good platform to build a blog/wiki/forum type thing on top of, something like what Russell has been talking about. Of course Roller is here now and rapidly being improved by a community, and I haven't seen any momentum for building something like it on JPublish, so I guess it's a wheel thing.

One thing Anthony mentioned as a goal for JPublish 2.0 is:

In general I am going to try to factor out as many of my own components as possible and start using other peoples components so that I can focus on items which are really important in JPublish such as the repository system.

This is one of the reasons I decided* not to use Cofax: it implements its own database persistence, templating, and pretty much everything else, and IMO spreading development effort over so much shows in that each of these is mediocre when compared with components available off the shelf, such as Velocity, OJB, WebWerk, etc. There are some things I like about Cofax, in particular the way it finds page templates is brilliantly flexible. But I decided that refactoring Cofax's framework to implement standard components would be more work than reimplementing its clever bits on another framework.

(* Back when I was looking to get into CMS consulting, which it doesn't look like I'll be doing after all)

Anthony has released JPublish 1.2. I've played around with this, and written a module which is in the CVS repository but which I have let languish a bit. As I've mentioned before, I spent some time looking at CMS possibilities, and settled on JPublish.

I wouldn't really call JPublish a CMS, it's more like a CMS kernel, basically a simple, clean, well-architected web application framework. It uses Velocity for templating, and has a nice model for selecting page content, template, and meta-data based on the incoming path.

One thing it lacks is a good storage model. most of the components that come with it are file system based, which isn't going to scale well. There is database code, but it is based on hard-coded SQL, so if you want to add new objects to the framework, you're going to hard-code it.

I fantasize about building ObjectBridge support for it, and making it all more bean-based, probably using BeanUtils and Digester, but these would be a major change in architecture. And since it doesn't look like I'm going to be doing much CMS work after all, I'm not going to have anything like the cycles to commit.

Oh, well, it'll be interesting to see where JPublish goes, it has a lot of promise. I'm just waiting for someone to build a blogging package with it!

One of the advantages of using a popular, established package like Movable Type is the support available. Brad Choate seems to be an alpha MT guru, and has written a number of useful plugins, including KeyValues, which is a hack for storing metadata in extra fields of MT entries as well as category, and blog descriptions. This seems like an easy way for me to store my per-category link lists, so I've been using it. I ran into a problem, posted a question in Brad's comments section, and less than an hour after sending him a copy of my offending code he emailed me updated code which fixed my problem. Thanks, Brad!

Brad maintains that although Movable Type is not intended as a general purpose CMS, it can be coaxed to do a lot more than its authors intended. MT does have the core of a good CMS inside it, but its code is rather locked into its special-purpose application as blogging software. It's template management limits pages to be indexes or archives based on categories or date, and its tag library is similarly restricted. These can be creatively abused to do more than they were intended, but it would be nice if the authors rearchitected it a bit to allow the core to be more easily repurposed for non-blog uses.

The really useful thing about MT is it's got a great model for baking web pages. There are a baskillion web page frying systems whose templates are processed at runtime, ASP, JSP, PHP, et. al. Even more down-to-earth systems like Turbine fry their pages, although Velocity does offer baking functionality with DVSL.

MT bakes its pages when the content or the template changes, and whats more, offers a plugin architecture that makes it easy to extend what happens at bake-time. Since it puts out flat files, pages which really need to be fried, because they have elements which change at view-time (e.g. user personalization), can be produced with whatever frying template code you need.

If the MT authors refactored their code to move the blogging-specific features outside the core of MT, the core could become a very strong web application framework. Of course it would help if they open sourced that bit (they could keep the blog-specific MT stuff under the current semi-open license), but that's a different story.

I've hacked up a bit of code to let me include category specific links in the sidebar on my category index pages. MTPerlScript looks like a useful prototyping tool - you can play around with different ways to implement some functionality, then move it into a plugin when you're happy with it.

I'm not satisfied with the way I've done the links functionality, because it doesn't make it easy to manage the links via the web interface. I could make templates to generate each link file, but that seems like too much hassle to set up. I guess lists of links could be managed like a blog, with each link an entry, but that's awkward also. It probably needs a new data type with a different configuration page, but MT doesn't make that easy to pull off.

Here's my code:

$category = "";
$links_file = "../templates/links/${category}_links.html";
if ($category && -f $links_file) {
if (!open(LINKS, $links_file) ) {
print ("");
} else {
print " Links";
while() {
next if ( /^s*#/ || !/S/ );
if ( /^s*(S+)s+(.+)/ ) {
my ($url, $name) = ($1, $2);
print "

";
}
}
}
} else {
print "";
}

I've played around with a few different blogging packages, and so far I like MT well enough. It's a mature piece of software compared with most of the alternatives, and I like the fact that it is both server based and produces flat output. My only gripe is that it is, in fact, a blogging package. This means it's designed with the blogging paradigm firmly in mind, so it's hard to twist and bend it to do exactly what I want.

My main gripe is the templating language doesn't have quite enough oomph to it. It offers a set of tags useful for making blog-shaped pages, but not much else. There are no conditionals - I can automatically create a list of links to each category in the sidebar, but it can't recognize the current category and mark it up differently - leaving it unlinked and flagging it with an icon, for example. I can't tell it to leave certain categories out.

I also can't easily add different data types or fields to the typical blog entry. I want to treat books specially, so I can automatically create Amazon links with my affiliate code. Plus bookmarks. I want to have a different set of links for each category page.

It's possible to stretch and bend MT in ways it wasn't obviously intended, but writing Perl plugins looks like the best way to get the functionality I want. It shouldn't be necessary, though, the MT templating architecture ought to be a bit more flexible than it is.

In the end I settled on MT for kief.com because I don't want to bother either writing Yet Another Goddam Blogger, spend a lot of time helping an existing blogger like Roller, or build blogger functionality on top of a framework like JPublish.

I was seriously considering these things a few weeks ago, because I was planning to get into online publishing as a line of consulting work, but it now looks like I'm going to take on a lot of Unix sysadmin work, so I won't have the cycles to spare. So MT will let me run my site with a minimum of hassle, and if I do get some cycles maybe I'll tackle some of those minor annoyances.