Static Website Generation with PowerShell

Static Website Generation with PowerShell

Over the past few days i’ve found myself creating a website to host all my retro software to friends. I started off thinking i’d just craft a quick index.php page and make a fancy directory listing. After thinking about the clutter of hundreds of index files dotted about in each folder I decided on a new approach.

I needed an approach that was a full website, without the hassle of creating a MySQL/MariaDB back end and importing hundreds of thousands of roms, disk images, etc etc. The web pages would be static once generated, with nothing changing as I generally collect full sets of everything I go after anyway, which is why I decided on PowerShell to generate each page for me. Firstly, there’s a main index.html page, which links to every system I currently have software for. Each one of these links then links to another page which is essentially <systemname>-a.html. On these pages it has alpha numeric selection index on the top page so you can skip through all letters of the alphabet. Each one loads an individual page. They may seem cumbersome, but it works and it’s incredibly fast as there’s no server side processing happening in any of the pages, as they are pure html, no JavaScript or php required.

The PowerShell that generates the pages comes in two functions; one which generates all the system pages from # – z and the other to generate a custom index page. The index page has lots of nice transparent PNG images too of each system, so fits nicely with any background colour I settled on for the site. The system page generation takes three variables, $systemName, $directoryPath and $friendlyName. With these 3 variables it can generate 27 pages (one for each letter of the alphabet and a # for the numbers). The script combs through the directory in $directoryPath and generates a nice html enabled directory listing complete with download links. In order to provide the downloads I have my retro share from my NAS mounted directly to the web server as read-only.

The reason I opted for this solution was because the previous solution I was using was to upload everything to my nextcloud instance. Although I had the spare 15TB+, it just seemed like an incredible waste of space, considering I already replicate that share for backups to a secondary NAS. It’s a fair amount of space to throw away to duplicates purely for serving. This solution now works perfectly after spending a few hours at the weekend and tonight and yesterday night working on it. It’s now fully functional. Unfortunately, I can’t link this, as it’s technically a private server as I don’t want Nintendo sending the boys around to knee cap me.

I will, however, be making the code public on my GitHub page at some point soon. It’s currently sat in a repo marked private. Once i’ve given it a thorough test and written some documentation to make it easy to deploy for others i’ll share it. It’s obviously got more uses than just a rom sharing framework and it may give others practical examples for quick generation of static websites containing lots of content that can be automatically combed and turned into entries on a web page.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *