I've started work on a kind of plugin for my site to facilitate using MarkDown encoded text files for pages on my site. It works at the moment on my internal testing site (setup just for the purpose of testing :)), but I'm thinking a thorough overhaul of the way my site backend works might be a good idea.
I'm trying to decide wether or not I want it to be database powered. I don't know if I do, as that means writing a front end (when a plain text editor, or emacs over ssh or otherwise) does equally well for editing text files. Actually scratch equally well, better.
Perhaps XML powered menus/meta data? But then that means extra files lying around. If it were stored in a database it would be quite simple to cache a copy of the MarkDown processed content. But then it would be quite easy to do with the file system (that also depends on wether it's faster to check file update times than run MarkDown, I suspect it might be). Smarty has caching code, so I might look into that (at least for doing things like creating directories, file names, age etc.).
A hybrid system might work - text etc. stored as files, menus in the database (and then assigned to files/folders?).
(This would have no impact on my blog which is powered by WordPress. I have no real desire to write my own blogging software, especially when someone else has done a damn decent job of doing it for me.)
One more option would be to expand/hack at/jump up and down on WordPress and get it to power more of my site (by getting rid of the /category/ at the start of category urls, would probably largely do it), and then making it so the side menu didn't show you categories for the whole site in certain sections (er, not that it's there at the moment - think of the list shown on the browse page).
Possibilities, possibilities.
subscribe to the doubleshot feed