APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Another idea about a basic CMS structure

© July 2011 Anthony Lawrence

I have long had a "dynamic to static" model for this website. That is, most of the pages are actually static but are stitched together from dynamic inputs.

Yeah, that's probably confusing, isn't it? Let's try a simpler explanation: I have a program (a Perl script) that pulls together the separate elements of a page (the header, the style sheets, the text, the ads, the comments) and writes them out to the static page that your web browser actually requests. Within the text file that contains the actual content are directives that tell the script exactly what to do with the page. For example, a directive might say "No Comments" or "Comments Closed" or "Put the main Google ad HERE rather than where you'd put it ordinarily".

The separation of content from presentation gives me the power to change things very quickly - not quite as quickly as fully dynamic pages would (ala Wordpress) but I gain the advantage of faster loading static pages.

The component files have been held in a directory that mirrors the directory structure of the website. So, for example, the components that make up this page are found in /data/text/Web and are named "basic-cms.something", with the main "something" being ".text" and with it containing both the text and the various directives that tell the script how to build the page.

This all works, but the script itself has become quite complicated over the years as directives have been added. Sometimes the directives conflict or need to cause other directives to change their actions slightly. It works, but it is getting messy.

How to fix it

My thought now is to start replacing this with something similar but possibly less complicated. I haven't fully fleshed this out yet, but my basic idea is that in /data/Web there would exist a directory "basic-cms.dir" and within that would be files that can be simply catted together to create the actual static page. I'm thinking a structure something like System V init scripts: P000 through P999 with 0* being headers, 1* being above the text content, 2* being left side column, 3* for right side column content, 4* for the main text, 5* after the text, 8* for Comments and 9* for footers.

Some of these would simply be links to common files. For most pages, 99% of the header is identical, so P000 is probably a link. P099 is the closing "^lt;/headgt;" tag (also a link) and P050 would be the meta tags specific to the page.

If I needed to add a new line in headers, I could either modify the static common files or create a new P051 file, which could either be a common link everywhere or specific to certain pages.

The text portion (the actual content) would probably be broken out by paragraphs - 400 being the first, 402 the second, and so on. If I want to insert something in every page after the second paragraph, I just create a link from 403 to that thing. If I don't want that on one or more specific pages, I just leave it out.

Of course scripts would create these skeletons originally and scripts would handle adding comments after approval. Also, nothing says that a particular file can't contain Javascript, PHP or an <!--#include line.

But is this less complex?

I'm not sure yet. I think the idea has possibilities and I'm going to play with it a bit. My present script would pay not attention to anything named ".dir" anyway, so I could just leave it alone or modify it so that it short-circuits and does the "cat *" if it finds that ".dir" file.

if (-e $file.dir) {
 system("cat $file.dir/* > $html/$file.html");

This might be a boondoggle or it might have potential. I need to kick it around a bit. As always, your thoughts and comments are appreciated.

Why not..

Although I should probably pre-answer a question that may come from new readers: Why don't I just use an existing CMS like Wordpress or Drupal?

It's about control. When it comes to my stuff, I want to control it. I may be tempted by Drupal or Ruby on Rails, but at the end of the day, I want total control and I don't want to be constrained in any way but someone else's code. It's that simple.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> An idea for a simple CMS for web pages.


Inexpensive and informative Apple related e-books:

Take Control of Apple Mail, Third Edition

Take Control of Parallels Desktop 12

Digital Sharing Crash Course

Take Control of Preview

Take Control of iCloud, Fifth Edition

More Articles by © Anthony Lawrence

Fri Jul 15 02:36:11 2011: 9623   AndrewSmallshaw


By the sounds of it I suspect I'd be thinking in terms of m4 here. Instead of a mass of files for each and every page you'd essentially have one file with directives to include standard files on the correct position. It's smart enough to look in a standard search path for included files so you'd only need a central copy of each distinct element. Customisation of those files for each specific use is doable as well, so for example dropping in a page-specific title and meta tags in a standard page header shouldn't be a problem.

If you're not familiar with m4 you should be able to get a rough idea of whether it's going to fly in twenty minutes or so, and while the GNU m4 manual is one or two hundred pages long you can get a useful working knowledge in perhaps a couple of hours.

Of course, the web technologists would no doubt be advocating XSLT here, but my experience is that in contrast to m4 the learning curve is pretty much vertical. It seems the whole XML thing is broken down into too many component parts, and you need to be proficient in each of them to achieve any constructive at all. I probably spent the equivalent of a couple of days looking at that stuff before deciding it really wasn't worth the effort.

Fri Jul 15 02:49:39 2011: 9624   TonyLawrence


Although I do not use m4, the concept is exactly what I do now. As I explained, it has disadvantages because of conflicting directives and special cases, it gets complicated very fast.

Sat Jul 16 02:11:21 2011: 9627   KarlKowallis


I had the same issue and situation. I was coming from a PHP driven site that was almost entirely assembly of parts. My solution was to use txt2tags (txt2tags.sf.net) as an underlying text format for the content and then I built a custom makefile to stitch the pieces together and generate the appropriate HTML from the raw text. I did it that way so that only changed pieces would need to be rebuilt based on the dependencies that were discovered in the files.

At this point I've started seeing the limitations of my approach. There are a few open source packages that do similar things, but I haven't fully embraced any of them. One of the features I haven't build yet is some templating type functionality. Making large changes was certainly easier than with static pages, but wasn't easy.

Unfortunately I can't link to my home page because I am between providers at the moment and haven't moved hosting. For more than a decade a friend was hosting my site for free, but I need to change that.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he, by peddling second rate technology, led them into it in the first place, and continues to do so today. (Douglas Adams)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode