My new semi-static website and blog

Inspired by this and this (both sourced from Adactio’s website who I sometimes play irish folk music with!) I spent some of my christmas holiday redoing my personal website and blog. It used to be a minimal effort wordpress 'jobby' with an off the shelf theme, and a number of plugins to do things that would take me 10 minutes to do in raw html. Whilst Wordpress is an incredible piece of software, I got annoyed by a number of things: the spam, the loading times, the visual clutter, constantly having to update, the vague sense of being bombarded by bots looking to hack the site and the incessant spam. So I decided to make my blog again without any frameworks. The benefits of not using are framework for me are:

• It is much less likely that security flaws in the framework can be used to access my site. Attackers would have to target me specifically.
• I have full knowledge and control over the whole site
• I have no unused features adding complexity
• I never have to update, things will never be obsolete, and I never have to look at documentation.

I wanted something that loads fast, not necessarily fully static - and I wanted a straightforward way of writing articles (and seeing how they look as they are written).
I call it semi-static because there is no database, or write changes on the live server, but it's not just pure html. I settled on the following guidelines:

• Proper semantic HTML, with an aim to minimise nested elements
• No js requirement for full access to site
• No database
• Accessibility
• No frameworks (Compiled and mature PHP modules allowed)
• No templating other than what PHP offers
• Use of new CSS features that I hadn’t had much practice with
• Homemade local/offline CMS with articles written in html or md
• Continuous-ish integration

PHP is often maligned, and I have experienced frustration with the language, untyped with frameworks such as Drupal, passing around random keyed objects, and requiring this and that everywhere. But using PHP to create this site and blog was a joy! It’s almost like PHP got promoted to its level of incompetence, when really it is the perfect language for these projects. Here are the features I most appreciated during development:

• Built in templating: I love PHP templating, I can have code and calculations throughout a file. I find mustache etc to look nicer, but super cumbersome in comparison. Eventually all those curly brackets start to look the same too and get lost…. Native PHP templating is so convenient.
• Mature libraries: I wanted a yaml parser and functionality to resize images on the fly for my local CMS. Both libraries were easily installed and work perfectly.
• Workflow: I make an edit to a PHP file and I see the output instantly (see my earlier post)

Minor discoveries:

A css trick:

I wanted section and article elements that spanned 100% of the page width (for the background colour), but had content that behaved as it it were centered with a max-width.

I used calc to replicate this behaviour to do padding:

:root {
    --article-padding: calc(10px + (50% - (min(1250px, 100vw) / 2)));
}

A chrome bug:

I encountered this bug in chrome where having transitions set, would cause them to fire on a page load. https://stackoverflow.com/questions/14389566/stop-css-transition-from-firing-on-page-load

This can be stopped by having an empty script tag at the bottom of the site - a bit dirty, but I didn’t want to spend all evening solving this issue, (or give in and use JS).

How does site work:

If you are interested! The site is semi-static, much of the blog content exists in pre-generated files, but the pages themselves are php templates, which I edit directly. I have public directory which contains index.php, and sub directories for each page/area of the site. The pages access header and footer templates. The blog and photos areas of the site, have sub-directories with generated .inc files for full articles and snippets. These pages when loading loop through loading the required .inc files.

The articles are markdown files, with metadata as YAML in the header. I have an update script which uses the markdown filetimes to update any changes to the article, and generate new snippet/article incs, plus the articles own page.

On the dev machine, I output JS which checks to see when the last file was accessed in the whole directory structure.
If an update is detected (e.g. after saving a file in the IDE) the update script is run, and the page is reloaded.
This means I have my markdown editor in one window, and the article in a browser in another window, and as I update the article, it appears on the browser as and when I save (see here).

I push the public folder live with rsync -ru - this could be called

from the update script itself to make live changes, if say my dev server is set up with a different project and I wanted to update my site during a work break :).
The public site does not contain any file_put_contents or anything which writes to or modifies the server - I am planning on adding something like comments at some point, but will cross that bridge when I come to it. I might separate it and use something like firebase, to avoid having to deal with publicly generated content on the live server.

I love this new setup and I was thinking about releasing it low-key - but the reality is that, if you would consider using it, you would probably sooner just want to make your own!