Really? You can't copy and paste 8 times and then visually verify each one? Hell, you could diff them against each other to make sure you're not missing anything in those sections.

I think our culture has put too much of a taboo on copy and paste. It's not the end of the world if you're careful about it. Ideally, yes, you'd have it defined in a single template which then assures you that all pages are identical.... but what happens when the next guy comes and doesn't understand how the templating system works? It may end up costing your client a lot more money because the guy has to spend time figuring out your specific brand of templating, making sure he has the tools to work with it, etc etc. As opposed to simple copy and paste in plaintext, no tools, just content.

That's why you use a static site generator. If the next guy wants to just edit the output of the static site generator, he can, and you're no worse off than if you'd just written it by hand in the first place.

SSI is usually available out of the box, or at worst an .htaccess away.

The downside there is performance overhead.

If a user requests "/foo/bar/baz" you have to allow your webserver to stat "/foo/bar/baz/.htaccess", "/foo/bar/.htaccess", and "/foo/.htaccess" which can be a significant performance hit.

SSIs have similar issues, parsing all files on the off-chance there is some magic that will be required.

This website doesn't need to scale. It doesn't matter.

You know your site best - but I'd suggest that being able to scale is just good practice.

You never know when your site is going to be posted to hacker news, or similar!

Premature optimization, yadda yadda ...

SSI performance overhead in nginx is negligible (you hardly notice any difference with static html, unless you shtml size is many megabytes).

Or, on your basic shared hosting, you'll usually find PHP too. While I'm not advocating a ton of calls to do all sorts of things with databases and who knows what else, a set of PHP includes (and maybe a few additional helper functions) would be similarly useful.

The thing of it is, the next person that looks at the site might not know PHP... then what? You must know HTML to be able to work with a webpage. Anything else is just a further restriction on who can edit the site. Most small businesses get their websites managed by whoever happens to come along with a tiny bit of knowledge. The tiny bit of copy and paste you might need to do to avoid non-HTML is a perfectly good tradeoff to keep the barrier of entry as low as possible for the next poor schmuck who has to go in there and twiddle with things.

A PHP include takes about 1 minute to explain. You don't even need to know PHP, just the include syntax.

nginx certainly doesn't use .htaccess ...

My personal site is static but using minimal PHP to include headers and footers.

I had intended to use a content management system at some point but never got around to it.

make (or a simpler alternative) is also an option in such circumstances.

How so? Would you use basic Unix utils like `cat` to build the final page? I guess you're essentially building a static site generator at that point. Albeit a very simple one with minimal dependencies.

Right, you have a header, a collection of body docs, and a footer. A markdown converter if you'd like. make and then scp transfer or commit to vcs, etc.

As these are common tools there's no cognitive overhead for developers and it can still be automated for users.

Yep! That's a great solution for a lot of sites.