Roll my own CMS?

I’d noticed recently that the ministry website (http://www.winningsideministries.org) had gotten woefully out of date in regard to it’s text content.  The news column on the main page is over a year old and the “about us” page doesn’t reflect the current state of the ministry at all.  I started to update the content but I got all hung up in figuring out whether the site was currently running the testing or stable version from svn, then making sure to upload the right file version, trying to remember to update the right repo…it was a mess.  I’d been using svn for the ministry website because I’d started working on it before I new git; more than that, I couldn’t store it on my free github account due to the fact that the database passwords would be there for the world to see.  The solution to that bit of the problem was simple.  I just set up my own git repo on the same server that hosts my svn repos and moved it there.  Since I was having so much trouble figuring out what version of what files were where, I just downloaded the current working version of the website and based the website off that.  It’s possible that I’ve lost a little bit of work that way, but as badly dissheveled as the codebase was I wasn’t sure that it mattered a whole lot in the long run.

After that I asked myself, “Why am I sitting here editing source code files to update the content of the website?”  Sure, building it that way got it up quick without me having to learn a lot of new stuff before-hand, but it made the maintenance a nightmare.  At that point I realized that for there to be any sort of efficiency in the task of keeping the content up to date I was going to have to completely (or nearly so) separate the content from the code, aka, use a CMS.

There are lots of good CMS’s out there, but most of them are really heavy from what I’ve seen.  A lot of them (like the WordPress CMS that powers this blog) are indeed very blog oriented, making it a bit more complex to have widely varying page setups.  I realize that if I’d spend the time requried I could very well make any one of the CMS’s available do just as good a job of handling our static content pages as it would our dynamic ones, but I wasn’t sure that’s what I wanted to do.  We have a very simple website with (currently) 9 working pages.  It just felt weird to use a CMS that took five times more code than the whole rest of the website.

I came to the conclusion that for our purposes all I really needed was a simple CMS that would take a database full of “page” rows and automatically put the content into the right spots in the Smarty template.  After a bit of playing around, the idea evoloved of using mod_rewrite and a single page-loader php file…a very elegant solution compared to what we had before.  What I needed then was a way to be able to mark up the content in a way that was non-code-oriented…very legible on it’s own, outside of the page itself.  Markdown was the first thing that came to mind.

I love markdown: it’s simple, elegant, and reads just like a plain-text email.  Everything about how it looked screamed, “You want to use me!  Pick me!  Pick me!” and so I did.  The only problem I ran into was the fact that markdown doesn’t support generating anything besides plain html tags—no class names, ID’s, or anything.  That wasn’t a big deal until I tried to add link anchors to our “about us” page…oops.  Can’t do it.  I found that the “extra” version of the PHP Markdown implementation allows adding custom ID’s to header tags, but I didn’t want to limit myself so badly that early on in the game.

Enter the next contender: textile.  Textile isn’t quite as plain-text looking as markdown, but it supports everything I need.  The issue I had with textile is that the version of the parser they have available for download on their website is ridiculously dated, though the link doesn’t say anything about that.  I was having weird problems like the last element of lists being bumped down into their own list…as in a 5 element ordered list would show as elements 1, 2, 3, 4 and 1.  Doing some research, I found out that this bug had been fixed long ago.  When I read that I immediately looked in the source code for some indication of a date…it had been released in 2006.  That’s a problem.  I did find, however, that the textile based CMS called TextPattern included the most recent version of the classTextile.php file (which is all you need to just use the textile parser) so I grabbed that, and the problem was solved.  You should be able to get the latest version here: TXP/classTextile.php:HEAD

I’ve already gotten the few completely static pages on the website converted so now all I have to do is get the mixed static & dynamic pages working.

It feels unbelievably good to confidently type `git rm` so many times in a console.  😉

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: