The Tech

For my fellow nerds, talking back-end infrastructure is always fun. The current answer to that is:

• OS - Debian Bookworm (12)
• Hosting - OVH VPS, 2 vCore, 8GB RAM, 80GB SSD
• Server - Nginx with HTTP2
• Nameservers - Mine, Bind9 on this machine and my mail server
• Language - Primarily PHP
• Frameworks/CMS - Custom
• SSL - Let's Encrypt
• VCS - Git

The website has gone through several iterations and so too has the hardware and software. Some changes have been practical. For instance the site started out running in a Linux Container (lxc) on Debian Wheezy (7) on my desktop computer attached to a static IP on my home internet connection. That machine was a heck of a lot more powerful than the VPS, but it lived and died at the whims of TekSavvy's DSL line and the Ottawa power grid. Other changes were not necessary but I made them just out of curiousity. It started out as a very vanilla Apache installation, but I administer Apache servers at work and thought I'd expand my skillset. Similarly, I used to just use the DNS services provided by my registrar but having never run my own name servers, I thought I'd learn that as well (this one also saved me a few dollars a year, but that wasn't the point). Early on I added HTTPS support. Despite the fact that there's no real privacy need for it, Let's Encrypt just makes that process so easy that it would seem silly not to set it up.

Everything was initially pretty much static HTML with a lot of copy-pasting, then I split the duplicate stuff into JavaScript files using document.write functions and loading them on each page that they were needed. That reduced the need to apply changes across multiple pages but also meant that processing had to be done on the client-side and was dependent on a JavaScript enabled browser. It did also allow me to get the primary functions of the CMS working, including to programatically generate all of the common elements for page blocks given just the variable content strings and images. This was still not ideal because it was: 1) inefficient - it meant sending the complete contents of an article or list page even when only a handful of items might be rendered. 2) static - plain JavaScript cannot access the filesystem to know what content needs to be loaded, so I had to maintain separate files that listed all of the directories that needed to be included.

I'm pretty happy with where things are at right now. I will continue to update the software that is currently in use, but I doubt it will change significantly aside from adding features to my PHP code. I may upgrade to a more powerful VPS if that becomes necessary, but this would be more likely to happen if I add on additional services like GitLab or NextCloud. Web traffic is unlikely to take me down any time soon. UPDATE: It did happen, at the time of writing, the VPS had 1 core and 2GB of RAM. I did end up installing a Git server, moved my email filter to a VM on this same machine and run a bunch of other containers and applications here now.

The Code

The following discusses the basic mechanics of how pages on the site are generated. There are only a few basic classes of pages and then a few special cases that are still relatively static.

Common Files

There are a few visible page elements that are used on most or all pages, however there are also several that work in the background that are quite important. The obvious visible examples are "header.php" which loads the top banner. There is then also the social media column on the left, creatively loaded by "left.php". Then there is the Social/Contact boxes loaded with "contact.php" which don't exist on all pages but which are pretty widespread. Many other visible elements like the banner on the homepage are written to be as modular as possible, but have not yet found uses elsewhere.

The only visible thing that is particularly notable about the header is the Easter Egg explaining the site name, as discussed earlier. That said, it does serve a few other purposes. Notably, it loads the "lightbox" functions which display and hide the large images. It also uses those functions for an optional "Under Construction" shade which it defines but hides by default. Finally, it also loads in some CSS.

Both the left panel and the "Social" section of the Contact block fetch their links from a specific file. This file lists my social media details as an associative array including the name of the social media site, the location of the image used and the external link to my profile on that site. Each of the two blocks then loads it in using it's own rules. The site is mostly mobile-friendly in that the content re-flows and generally fits nicely onto a small display, however it is not actually responsive to the actual page width given that PHP does not get that information. As a result the "Social" section only display 3 images with the rest hidden under the fold because this seems to be the most that will fit on really small displays before line-wrapping. One of the images used, I cannot recall which, was pulled from a creative commons site and altered slightly and I made the rest to replicate that style with Inkscape.

There is a "page.php" file which is pretty much the first thing to load on almost every page. It doesn't generate anything visible on the page but is essential to making other things work. For instance, it processes the URL arguments to determine what content to load. It sets up the base URL that will be used for most of the links on pages. It sets the meta tags in the \ so that the title of the browser tab and the description of the page reflect its contents. It also loads the Google site verifaction, viewport size and other basic page information. Another fairly unused thing that it loads is error reporting code. This is used if an invalid URL argument is provided, but is flexible enough to do a lot more. I just haven't added tests for some things that I normally would if this were something I was being paid to support.