Changing "up" to a Raspberry Pi2 for use as my in-house webserver here in Technology Towers actually gives me a good opportunity / excuse to revisit the Neanderthalic way I've been doing things around here, to see if it's still the best (rather than simply [as I fear it may be] the laziest) approach. Though if forced to change my (forgive the word) "technology" I would currently face over 3,500 sets of edits just for the files that constitute my prolix ¬blog, let alone all my other web page files.
A mildly sobering thought.
With effect from the end of March 2016, the "external" pages of the 'molehole' web site are all now being served, as static HTML files, from somewhere up in the Amazon AWS cloud. Exactly as (sort of) predicted at the bottom of this page, in fact. This is a carefully-calculated risk on my part. I've decided, after nearly a decade of running 'molehole' in its present format, that its present structure, layout, and "philosophy" suits my needs for the foreseeable future, so I'm trading off the possibility of easy structural change (tinkering with the set of just ten "navigational" SSIs) with the (I hope) faster (and certainly easier and more reliable) publishing process that AWS enables me to use.
Converting all the files actually took just under 10 seconds — running a smart piece of Python script on BlackBeast Mk III. It was this script, in fact, that made the project feasible. Brian wrote it for me (partly as an educational exercise for his own purposes). His Python walked (slithered) the entire file structure "underneath" ˜david replacing every SSI by the HTML code that it specified. It also examined every hypertext link thoughout 'molehole' changing all those that linked elsewhere within 'molehole' to end in ".html" rather than ".shtml" but leaving strictly alone all non-molehole links that also had .shtml files as their target.
Ironically, my old-fashioned approach of using ˜david as the home directory under which the entire web site "sits" made the task a whole lot easier (he assures me). And, just as important, the changes could also easily be rolled back — if necessary — simply by inverting the processing logic of his Python. It's amusing to see that there's something of a growing fashion for simple, static HTML particularly for little personal hobbyist projects like 'molehole' as it massively reduces the attack surface available to the nastier denizens of the web. I now predict that the next change to 'molehole' will see it using SSL to encrypt all the page transfers from the server to your web browser.
Give it time!
... docs on configuration options for molehole's chosen internal webserver (lighttpd) say I'm still OK to carry on using mod_ssi and my four simple SSIs (detailed below) to finish building each page on the server before actually serving it back to me (by squirting it along the electric string across Technology Towers from the Pi2 to BlackBeast). Or wirelessly over to the Android Tablet wherever I happen to be in the house.
I can therefore, if I choose, simply ignore "the use of this module is strongly discouraged" because the four SSIs I use on each page are trivial, and thus pose no risk of overloading the Pi2. Which is, after all, known to be about 6x the CPU performance of the Pi that I already know from the last two years of daily use is perfectly adequate and fit for purpose.
However, there is actually an argument to be made for doing away with my use of SSIs completely, and thus making each of my web pages completely static. Read on!
Dynamic web pages?
The first two SSIs (Header 0 and Header 1) form the HTML header material that brackets the local page's title as I wish it to appear on the very top of your web browser's window:
Header 0 looks like this: <!--#include virtual="/~david/SSIs/header0.html" -->
It pulls in these four lines of HTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head>
<title>molehole.org | title of the web page goes here</title>
Header 1 looks like this: <!--#include virtual="/~david/SSIs/header1.html" -->
It pulls in these further lines of HTML:
Blimey! I don't seem to have touched my CSS file since 2010. See what I mean about laziness?
The third SSI (Header 2) fetches an appropriately-highlighted "navigation bar" to splash across the top of every web page. So, for example, every ¬blog page has the word "diary" highlighted in orange:
Header 2, for diary_navigation, looks like this: <!--#include virtual="/~david/SSIs/diary_navigation.html" -->
It pulls in the HTML appropriate for each major area of 'molehole' and its corresponding top line of site navigation:
<div id="navcontainer"> <ul id="navlist"> <li><a href="/~david/index.html" title="homepage">home</a></li> <li><a href="/~david/audio/index.html" title="Audio">audio</a></li> <li><a href="/~david/bits/index.html" title="Bits">bits</a></li> <li><a href="/~david/books/index.html" title="Books">books</a></li> <li id="active"><a href="/~david/diary/retiring.html" id="current" title="Diary">diary</a></li> <li><a href="/~david/texts/index.html" title="Quotes">quotes</a></li> <li><a href="/~david/dvdav/index.html" title="Video">video</a></li> <li><a href="/~david/dcm_autre.html" title="Other">other</a></li> <li><a href="/~david/help/help.html" title="Help">help</a></li> <li><a href="/~david/sitemap.html" title="Sitemap">sitemap</a></li> </ul> </div>
Header 3, for the bottom copyright line, looks like this: <!--#include virtual="/~david/SSIs/copyright.html"-->
This final SSI just pulls in the copyright line at the foot of the page and terminates the HTML file:
</div> <div class="footer">© <a href="/~david/help/dcm_contact.html">David Mounce</a>. </div> </body> </html>
Anything that isn't an SSI is my scintillating page content, of course :-)
Static web pages?
If I could no longer use SSIs, but didn't want to change anything else, I would make every web page completely static by permanently importing the content of these four SSIs into each and every page at the appropriate points in each file. This would make no difference to the way serving occurs inside my living room. However, it would allow CloudFlare to have the full range of 'molehole' external web content to fall back on whenever the external server — the one in Texas that hosts a subset of my full web site — has to nip out for a measles vaccination, or some target practice shooting at immigrants with measles, or to put another dollar in the electricity meter.
Of course, it would also increase (by the combined size of these four SSIs) the total size of each web page that I fetch from, and put back on, either of the servers, though by a fairly trivial amount.
Junior continually gently nags advises me, from time to time, of the benefits (to him) of (my) going fully static. I suspect he's simply plotting to get the whole shooting match re-hosted on Amazon's AWS. [Pause] Just had a brief chat with him. He points out that actually it might be quite sensible to keep all my SSIs, but to write a script to 'expunge' them en route to the server, and re-insert them on the way back from the server. That way, I could still make quick global changes to the site. He's right, of course. Particularly if he volunteers1 (or can be bribed) to write the script.
The last major change to molehole's site "structure" was when I added this "bits" area (for stuff about PCs and tech toys other than audio or video). It meant tinkering with each of the nine "main navigation" SSIs that existed back then to add in the tenth. While I don't currently expect to perturb the structure any further, every page also carries the copyright date. And the SSI is very convenient for updating that in just the one file rather than many thousands of the things. (On the other hand, I could always just remove the date, of course.)