I need to make a confession: I have a bit of a nerdy obsession with Content Management Systems. This probably stems from the fact that I’ve built several, worked with a number of internal bespoke systems, and have also been involved in implementing an off-the-shelf solution for a number of large sites. As an addition, I’ve also worked with—and built—several blog publishing systems, which can be viewed as the most basic bespoke CMSs. The upshot of all that is that I’ve spent so long on CMS related problems, solving them has become a rewarding experience.
Recently, I’ve been building a new blog platform, in Django, called “nef-blog”. It’s nothing special; just a quick self-build solution that will get me off of Wordpress. However, I’m still not entirely happy with it, since it will still be building my blog pages at request time (otherwise known as “frying” pages). This seems like a needless overhead and, for good performance on popular posts (I do have some), will probably still require some form of caching solution. I’d much rather have the choice of implementing a mixed fried and baked solution—where “baked” pages are generated by some form of printing process, and the output is stored on the file system and served at request time.
Several of my peers have also recently been building baking (or “static CMS”) solutions—most of which are available for perusal on GitHub, despite being in varying stages of completion:
This has inspired me to attempt to develop a new CMS; but before I do that, I thought I’d lay down a sort of treatise of things to take into account when designing and developing a CMS. These are simply my own thoughts on the subject, and I’d definitely welcome some discussion; I’d definitely like to be able to update this post in the future with new information garnered from the web developer community.
Categories: