If you're considering developing a content management system of
any magnitude from scratch, it's probably a good idea to sit down with a scratch pad and think through how you will
approach the project. What languages will you use? How are you going to store files? Will this be for a single developer (for just personal use) or will you have levels of access (for use in development teams, or for developer-client use)? My assumption is, for your first time, you probably want to start with basic functionality and options. However, from a professional developer's viewpoint, you should always consider scalability with any project you might put to code. Let's look at some examples.
Dirt Simple CMS - the humble beginnings
When I started doing freelance Web building as a teenager, the clients were quite happy to let me do all the work, including updating content and managing resources like photos, etc. The projects were simply promotional sites and didn't need to be updated more than once a month. As I got older and more skilled, clients became more demanding, and I had less time on my hands. Time to look into investing in a self-sustained content management system and let go of control of content. So I sampled a few simple CMS's out there, having been fully disenchanted with the full-service systems available, and ultimately decided to build my own.
My first attempt at a simple CMS used mostly Javascript and a tiny scrap of PHP for updating data. I pulled out Ben Alman's
.hashchange() jQuery plugin, and then played with that using a little AJAX and a single JSON file to store the entire site content -- only about six pages. Eh, it serving its purpose. So what if the site can't be crawled by Google. It took me all of a single afternoon to code it. (I'll post about that project later.) Also, you know that scalability thing we talked about earlier? Using a NoSQL database system like JSON or XML won't really scale well when it comes time to store and manage large sites using more complex queries. So play with NoSQL, if you must, but when you're ready to get down to business, go ahead and pull out a SQL database.
A Better (Yet Still Simple) CMS
The next iteration of our homemade management system should, as I mentioned, include a full-service SQL like MySQL or MSSQL. And since we're saving data to a server, you will need, of course, a familiar server-side language, like
PHP or ASP. Put down that Javascript reference, because we're going to do this properly, which means progressive enhancement comes
after we've made a functional, SEO-friendly CMS. And it wouldn't hurt to brush up on Regular Expressions to do some data parsing as well. I would have considered suggesting a little mod_rewrite using .htaccess for this iteration, but you can still create a fully functional yet simple CMS without needing to manipulate URL requests just yet. Later we'll get into virtual file systems, which is ultimately what I'm going to use. For our simple CMS we just need a way to create templates and to query and display the appropriate content for the pages. We're still creating the pages manually, just like we did back in high school Web Design class, and adding in the template with server-side code. (I'll also post some examples, and maybe a tutorial, for this concept later.)
Automated All The Way
There are probably more subtle iterations we could discuss before setting loose on a full-service CMS, but I'm getting impatient. Lets jump right into a fully automated CMS, which, for large projects and/or a team of more than one, is going to be necessary from the word
go. We don't want to create pages manually. Heck, we don't really even need pages to exist until they're requested by the user. I'm a strong proponent for never writing duplicate code if it is unnecessary; and truthfully, when is it every really
necessary? But automation proposes new challenges. How will you create virtual file systems? How will your content editors create and manage the files? How will end-users request them? One approach is to store new pages in a database table and use mod_rewrite to redirect page requests, which I plan to do. These, I'll admit, are not simple concepts, and there are many common and disputed schools of thought on how best to create and manage tables for a virtual file system; and there is more than one way to use .htaccess for URL redirects (if .htaccess is even the route you would like to take). My boss commonly reminds me to "do the simplest thing that works". So I'm going the route that makes the most sense and is easiest to implement for me. (These topics will probably be posted about the most on this blog.)
Wrapping up
I know this post was not exactly instructional, but hopefully it's brought up some things to consider before tackling this kind of project. If you think of anything I may have missed (and of course, I've skipped over a plethora of topics that might be appropriate to discuss at the 10,000 foot view) please comment.
