There are two main reasons that you might build a website with maintainability in mind:

1. You plan to update it regularly
2. You are the type of person who will go to ridiculous lengths to avoid tedium and redundancy in favour of generality. The type of person who expects user-error.

Many different systems are available for managing your website. Personally, I prefer to avoid them. But they’re great for some specific situations.

I’ve spent a lot of time over the past few years, envisioning and testing different possible solutions to this problem. I have never before been happy with the result for long. Hopefully, my experience with this problem and perhaps even my newest attempt at a solution is of use to you.

CMSs

There are many different Content Management Systems, and they are being increasingly used to power websites. I have used a few, and even written a few. I can see how they would be good for certain websites, and I have seen them horribly misused. Often they are complicated and bloated with unnecessary features, as they try to account for all your possible needs.

If you want to avoid any sort of code, and don’t want to spend the time or money to build a custom system, then they are probably the way to go.

I hate rich text editors as a way to update websites. I mean, sure, they’re great for other purposes, but for a website? They seem to rarely work as one might expect, especially with the external CSS of the site.

Most importantly to me is how disturbingly ugly the HTML that they output is.

Some CMSs make use of textareas over RTEs, or allow you to choose. That way you can write the HTML yourself. But writing clear HTML can be painful without syntax colouring and auto tabbing.

The speed and interface of web-based solutions can be frustrating. As a primary method of maintenance, I decided against a web-based interface.

Files

The advantage of files is that you can batch download them, edit them in your favourite editor (preferably featuring syntax highlighting and auto-tabbing), and upload them.

The file-based solution is just that. Directly modifying the files which make up the site.

As you can probably guess, I had some problems with that. You may remember that I am a proponent for separating data from formatting. In this case, such a separation makes it easier to update youre content. It increases clarity and reduces the risk of ruining your template by inadvertently editing some necessary tag or section of code.

What many people do in this situation is split the template into two files: a file for the top, and a file for the bottom.

I choose not to use this method as I find it distasteful. I will justify this by pointing out that content areas may be spread throughout your template, and are not necessarily restricted to one “middle” section. While a valid argument, I should probably point out that my problem with the method is mostly just a matter of personal preference. I would much prefer to inject data into the template where appropriate.

In the past, I have done this with a data directory which contained, in turn, a directory for each page, as well as a default directory. The default directory would house a file for each content area for which default information was appropriate. Each page directory would contain a file for each content area that was to be filled in with data for that page. The files, themselves, contained only html.
This system worked well, but as I stated earlier, after using it for a while, my displeasure with the method increased. Having to go back and forth between directories in an FTP client was frustrating and time consuming. The obvious solution was to somehow have all the data files in a single directory, which leads to my current solution.

Files: current solution

In a data directory I have places a file for each page on the website. In that file, specific HTML comments divide the information by the content area it is meant to fill. Furthermore, placeholders can be placed into the html for the system to further inject appropriate data, allowing for a dynamic site. And, lately, I’ve been toying with the idea of providing a secondary web-based interface for these data files.

It may or may not end up working well, but I am hopeful.