Using nginx with Server-Side Includes (SSI) - unusual template?

Hi,
This is not exactly an 'issue' or a 'question' — treat it more as a 'minor annoyance' and/or grumbling about how things didn't quite work as I expected.
I have very, very rarely used Server-Side Includes (SSI) in the past, because, at some point in time, these were ridden with all sorts of bugs and security issues. I have no idea if this is still the case — but it used to be in the olden days when I used Apache, and I've been consistently using nginx for the past half-decade or so — but, in general, I avoid turning it on.
Recently, however, I had to set up again a very ancient site (for historical/archival purposes), from 2008 or thereabouts, which is basically just a handful of old HTML 4 (or 3...) snippets — enough to show 'something' on a browser with minimalistic CSS1 styling. And to make matters worse, this 'site' is actually a collection of four different sites (one of which even uses a snippet of PHP for doing very simple queries), and I thought that I could, at the very least, add some fancy web design using a simple (and free) Bootstrap-based theme, basically to give at least three of the four sites a consistent look & feel, and make them all look much better.
Easy to do with a PHP templating system, of course, but clearly overkill in this case (I may even be able to replace the PHP snippet with JavaScript at some point and get rid of PHP totally, thus saving a sliver of CPU & memory resources).
I thought that at least I could do some pseudo-templating using SSI, which would at least save some so-called development time, by keeping common blocks in single files (e.g. header, navigation, footer, and so forth). Hardly the best way to deal with this (and, yes, I could also use JavaScript to accomplish the same thing), but the kind of quick & dirty solution that I love to do
From a philosophical point of view, you can use SSI in two different ways (at least under nginx): either you enable it in a directory (or several directories), or you make it work only for specific extensions (.shtml in the case of ISPConfig). When clicking on the SSI checkbox in the admin backend, ISPConfig just adds

Code:

        location ~ \.shtml$ {
            ssi on;
        }

to that vhost's .host file.
This is obviously enough, but it has two teeny tiny problems (thus my nagging!). First and foremost, it means that it will be clear to anyone looking at the HTML that most links will point to '.shtml' and not '.html', thus immediately alerting potential hackers that SSI might be enabled. I try not to give too many hints to hackers (especially those that are so obvious...), so this is a bummer — I just have to trust that the nginx folks know what they are doing and have secured the whole SSI environment as much as it is technically possible to do so.
The other annoyance, of course, is that you will not only have to change all your instances of 'index.html' to 'index.shtml' but also manually include on the configuration of the site — on the 'nginx directives' option — at the very least something like:

Code:

        index index.shtml;

This is the kind of one-liner that gets easily forgotten — especially after moving the site after years or decades — and afterwards letting you wonder about what's wrong. But naturally enough it does what it's supposed to do.
I would personally prefer that there were two options for turning on SSI, e.g. either make it directory-based ('everything inside these directories will be SSI-enabled; everything else won't') or, well, if SSI is limited to a specific kind of file extensions, allow either the file extension to be changed (changing it to plain 'location ~ \.html' would be more than enough for most purposes!) or the 'index' directive to be added automatically for 'index.shtml'.
Oh, I'm quite aware that I can change all of that on the templates for ISPConfig3, and it's not that hard to do — at least assuming that I wish a consistent behaviour for all SSI-enabled websites. Because I just have one (and possibly a second one soon — another legacy from 2003 which I've 'inherited'...), it's hardly worth the trouble. But if for some reason SSI becomes all the rage again, it would be nice to be able to configure it from the admin backend in a more intuitive way — one that will continue to work flawlessly in future versions of ISPConfig (as opposed to 'hacking' templates, which may or may not work in the future...).
This is just one idea. I have many more But this one seems to be reasonably simple to implement at some point, assuming, obviously, that it's worth the trouble — and that there are many people out there using SSI in their ISPConfig-administered websites.

 

Thanks, Till! That's pretty much what I had in mind — but I agree, I haven't seen SSI for quite a while now, although, on the other hand, I do have a few ancient legacy sites to keep up, and because they're not really going to be maintained any more, it's pointless (at least from my perspective) to push those old designs into a modern CMS... so, a bit of SSI here and there, and I get something reasonable to maintain for another decade or two...