Welcome to the blog portion of the website.
I’ve had some sort of personal website for more than 20 years and have explored a number of ways to do what I want it to do. I want it to:
- Store a handy list of links. I don’t move around as much as I used to, but it’s nice to have a curated list of URLs available at whatever machine you happen to be using. Often times I need some links while I am using a computer where I either can’t or won’t log into some service to sync these. So, having a list I curate at a URL I control and can remember is handy.
- Store and serve project information. These are long form articles / papers describing my woodworking projects, documentation for SCA projects , and papers on other topics as needed. Also, reference materials for various things like identifying old hand tools.
- Serve Files. I don’t want to kill my bandwidth, but having a place to stash PDFs and the like is nice.
- Topical and spontaneous writing. Shorter articles, comments, thoughts, and works in progress.
- Simple. When blogs first came onto the scene I wrote my own system. It was more flexible and feature rich than the early versions of things like Blogger. But, that was a time sink. Back then it was as much about learning and exercising my development skills. These days, I am focused on content. I don’t want to fiddle with tech.
- Maintainable. The software is stable (i.e., it doesn’t lose or trash my hard work). It is easy to back up and make safe copies that I can redeploy should that be necessary.
- Practical and Secure. It has to be able to be deployable on my hosted website with it’s limited execution environment (i.e., written in Perl, PHP, etc.) rather than something that requires an actual server (Java, Ruby, Python) which would up my hosting costs. And simple to lock down.
After decades of trying different systems, there isn’t anything that nails all these requirements. So, what we have here is a hybrid approach.
My main website is a MediaWiki instance, the software that drives Wikipedia. It has a lot of features, a large user base for support, is free, is written in PHP which I understand well enough to hack around a bit.
It nails requirements 2, 3, and 7 pretty well, but it’s poor at 4, sucks at 5 and 6, and is harder than it should be at 1.
For requirement 4, the editor sucks, linking the page so it can be found is problematic. Yes, there are plugins that make a blog like feature, but they are clunky. And the editors still suck.
Setting up MediaWiki (requirement 5) isn’t hard, exactly, but it’s a little fussy. Here is where the flexibility causes problems. You need to find, install and configure the plugins you want. Then, in order for it to be usable (by someone not you), you have to plan your category taxonomy carefully or you will be forever tweaking the tags.
And requirement 6…It’s hard to back it up. Not hard hard, but there are several step to execute before you come away with a ZIP file on your local machine that has all the pieces to redeploy the site. The data is stored in a MyPHP database, but a ton of metadata is stored in the wiki code tree in hash tables implemented as folders. To do the whole thing, there’s like an 8 step process to go through via SSH. Tedious, but necessary. I have been burned here.
I let the wiki lie fallow for a couple of years, it still worked, mostly. For some reason image files were wonky and thumbnails didn’t work right. So I set out to fix things, plus I needed to add a bunch of new projects and generally sweep up.
It broke. Like, became a slowly cooling cloud of vapor. That sucked. DreamHost backs up your website and your DB tables for you, so I contacted support and had them restore a backup from last month to a separate DB and the files to a parallel tree so I could conduct an autopsy and figure out what went wrong.
The wiki is written in PHP. And, PHP apps tend to be highly sensitive to the version of PHP you are running. Somewhere over the last couple of years something MediaWiki was depending on changed or was removed. IDK. I updated MediaWiki, the hosting company automatically upgrades PHP for you to a minimum safe level. You can manually go up to a more recent level if you want. So I upgraded both and it just stopped working at all.
After a few wasted evenings on this, I gave up. I did a clean install of the latest version on the latest PHP and started over. One window on the old broken original wiki, one in the new and copy/pasted crap over. Yes, there is an export/import feature. It didn’t work. Plus I was afraid of contaminating the new site since I had no idea what broke things. Play it safe, move things slowly. Back up often.
After a month or so, the new site was done, backups saved in 3 places and all it good. I guess. So I don’t have a solve for number 6 other than to take my own backups regularly and try not to let bit rot break things.
To solve #1, I supplement the wiki with a static HTML page at a URL I can remember. Back when I fiddled a lot, I hacked together this page that implemented tabbing using some JavaScript and simple CSS. It was a way to store hundreds of links in an organized fashion that didn’t require a large screen to display. That is to say, I wanted to be able to get to any given link without scrolling. I know, old school.
By “modern” web design and programming standards, it’s pretty primitive. But simple is a virtue here. If I were to waste the time to reimplement the whole thing in CSS, I’d end up with a more complicated page (code-wise) and be encouraged to lean on a library or two for some functionality. Something that bloats the page size, could break, might be insecure. Meh, simple HTML, easy to edit and if it’s been a while only takes me a couple of minutes to refresh my memory on how it works.
That brings us to solving for number 4, shorter writing. A blog seems to be the right answer here. But, the MediaWiki implementations just suck. WordPress is much better, but it sucks at a lot of the things I like/need about the wiki.
So, I installed them side by side. Stop trying to pound a square peg into that round hole.
I know blogs are considered old school these days. They seem way too deliberate I suppose. Too much like “writing”. It’s much easier to bang out a few lines on what they had for dinner or latest TV binge fest on Facebook or Twitter.
That’s never appealed to me. If I am going to bother to write, I aim for something cogent. I don’t want people feeling like they wasted 5 minutes of their life reading my posts. So they tend to be long and composed of complete sentences. According to my wife way too long for Facebook. Walls of text she calls them. Apparently anything that interrupts high speed doom scrolling is frowned upon.
So a blog seems to be the way to go for writing. I’ve had several in the past. Some I tried to keep up daily and even managed for a couple of years. But that got old. This one will not be daily, unless I feel like it. But I doubt I will feel like it for long. If I have something to say, I will say it. Expect months with little action and others that are packed.