Plaidophile

trikuare.cx evaporates in just under two months. I'm kind of dragging my feet on moving everything over to this domain because I'm not sure whether I should do the easy way (just move the directories over, mod_rewrite them, keep using my same crappy CMS), the moderately-difficult-and-potentially-annoying way (use MovableType to emit the HTML for each thing, using its subcategory support and so on), or the extremely-difficult-and-still-potentially-annoying way (make my own dynamic db-driven CMS which allows me to assign arbitrary amounts of metadata to everything and makes the whole site searchable and sortable with a variety of views).

I think the middle-of-the-road approach is probably the best. It'll be somewhat less work than writing an entire db-management app, and also let me automagically generate RSS feeds and so on, which is pretty useful.

Also, doesn't MT allow weblogs to display entries from other weblogs on the same system?

The main problem with MT is that it's not really set up in a way which makes it easy to manage a big pile of files, though. It seems pretty fugly to have a file which is like /stuff/music/songfight/Attack_Of_The_Show.mp3 and where its corresponding stuff/music/songfight/Attack_Of_The_Show.html just links to it with the /stuff/blahblahblah on it. A tailor-made CMS would do a better job of handling that.

Also, I've not done any PHP/SQL in a while, and I kinda feel like I should flex that muscle a bit.

On the other hand, it'd be really cool if I could just put the files into the directory structure and somehow associate metadata with them and then have it Just Work. And hey, my webserver runs OSX 10.4, which has that kind of stuff at the filesystem level! Maybe I should just learn how to use mod_index and the various OSX metadata-manipulation tools instead. Or even if I don't do that (I should keep my site portable) I could just tie stuff to the filesystem, like for each file in a directory, provide a link to it, any text included in an associated .desc file, a link to a generated HTML page with the content in a .info file if it exists, and a thumbnail if there's a .thumb.jpg or whatever. Then just make a lot of use of local stylesheets to change the display in a useful way (for things like 4800).

But like, for some things I'd really like there to be some form of structured metadata which could be arranged into a table, like on my music page. But then that means some sort of database which isn't queried on a per-file basis, which gimpy metadata files would be.

Argh, and there's just so many stupid other things to worry about too. Like how exactly to generate and serve up the detailed information files (probably use mod_rewrite or something, I guess), and whether to use mod_index or just stuff index.php files into each directory which includes library functions and provides the actual view of the individual files, or what. And I'd really like to avoid things which would turn every file view into a CGI parameter (like /stuff/music/songfight/?attackoftheshow rather than /stuff/music/songfight/attackoftheshow.html) but I also really don't like the idea of doing blanket mod_rewrite rules which would hide the file behind a mod_rewrite handler which ends up just calling a PHP script anyway. On the other hand, the mod_rewrite handler could be replaced with a static generation script like what I already have now, if it becomes necessary.

I also don't like any solution which keeps the actual source files visible (though this is already the case on trikuare.cx). Not that it really matters if people look at the .blah.mp3.info file or anything since they'll not see anything which isn't already included in the blah.html but it seems like I should try to maintain encapsulation or something.

This seems very much like a job for Cake, or something.