Mainly so that I can remember this, here’s a list of the outstanding problems with the blog that need to be resolved someday.

Todo List - Quest for the One Blog, Part 12

7 August, 2021. 1,372 words.

Mainly so that I can remember this, here’s a list of the outstanding problems with the blog that need to be resolved someday.

Roughly in the order I think they need to be fixed.

Image Hosting

If you browse old posts, you might notice I still haven’t filled in all the images yet. That’s because it’s a pain.

I had intended to keep all my images in directories alongside my text content, but it quickly became apparent it wasn’t a good idea, because putting 4GB of images in a git repository that needs to be pushed back and forth across the web isn’t a great idea.

First I tried putting images on a free image hosting place called imgbb.com, which works fine, but it’s a pain to upload images manually one at a time to any web site, my general life philosophy being that every extra mouse click is time wasted. (I think it’s free. I don’t remember paying anything for it, but the About page doesn’t seem to have a free plan.)

I’ve now worked out a way to use an AWS S3 bucket to hold my images. I create and maintain the images in a directory on my local PC and run a script to synchronize them to a remote AWS bucket “in the cloud,” then reference that bucket in my blog posts. The first post wired up to use this method is this one. Now my images can go from screenshot to blog reference without ever touching an image editor or manual upload. (I still have to copy them from one directory to another on the PC, and run a script to resize and brighten them, but that’s tolerable for now.)

The free AWS plan allows some 5 GB of storage space for free, or something like that. Most everywhere on the Interwebs allows 5 GB for free. And CloudFront, the part of AWS that actually serves the images, allows 50 GB of bandwidth for free. I assume that’s per month, but it doesn’t actually specify that. I guess I’ll find out. (UPDATE: CloudFront, it turns out, is only free for the first 12 months in the AWS Free Tier, so I’ll have to ditch that. I’m told Cloudflare is a free alternative, though I have little experience with it.)

Anyway now I need to go back and re-wire all my older posts to reference AWS instead of imgbb. Then I need to go back through all those years of archived posts and update the image references. I need to strip out the create-5-images-for-every-one that WordPress did to me all those years, and shrink them back down to one-image-per-image for 2013 through 2018. And convert them all to reasonably-sized JPEGs. (Some of them are PNGs… I mistakenly assumed WordPress would convert everything you upload to JPEG, but it didn’t. WordPress is terrible at everything.)

Once that’s done, only text files will be stored in my blog’s git repository, and updating the site will become significantly faster. (UPDATE: I have, in fact, removed all the images from the git repo. Still need to fix images for 2013-2018 though.)

Old Link Redirects

There’s no .htaccess on static web sites, a very significant problem that I utterly failed to anticipate. That means there’s no way to redirect old links to new locations. I have links out there dating back to 2003. The only way to do it in a static site is to duplicate the old paths, which is a pain, and not what I want to do anyway. I want to redirect search engines from the old links to the new links, so they update their databases.

That means I need an Apache dynamic web server somewhere that can redirect links–just a server that is entirely empty of content except a single .htaccess file. With the long-term goal of moving entirely to AWS, I expect I should be able to spin up an Apache server to do that one specific task (and perhaps, also, run an XML-RPC server). It’s overkill for that one specific task, but it’s the easiest way to do it.

(One alternative idea I had was to write a very simple Golang HTTP server that did nothing but redirect links, which I think is a better technical solution, but it’s more work.)

Moving Out Of Shared Hosting

Because of the aforementioned link redirecting, I still have to hold onto my ancient relic of a Linux shared hosting plan. I can’t yet fully disconnect from the ancient past of blogging and enter the modern world of infrastructure-on-demand.

But once I figure out the link redirecting, I’ll be able to move completely into AWS. Hopefully for free, or maybe a couple bucks a month (not counting domain names).

NOTE: Technically, it doesn’t have to go to AWS, it could go just about anywhere that supports serving static files and/or custom domain names and/or very small compute resources. AWS just happens to be the thing I’m most interested in exploring at the moment.

Pingbacks

There’s no pingback implementation on the blog anymore, which means I have no idea if anyone in the WordPress world references my blog.

Pingbacks are implemented with an XML-RPC call from one blog to another, which requires more than a static blog can deliver. And without comments, there’s no way to display pingbacks on posts anyway.

But it would be relatively straightforward to create an XML-RPC server implementation separate from the blog to receive pingbacks. Then I could at least be notified by email or something. (But will pingback clients balk if the pingback link is on a different domain from the blog?)

The question then becomes, where to host the XML-RPC server? It’s another thing that could live on its own compute instance in AWS, or possibly on the same instance as Apache server.

Implementing a way to send pingbacks could be done with a little command-line program that runs on my PC when I add a new post, or possibly built into the site-building process. Maybe there’s something out there that does this already.

There’s no blogroll. I want to add one. I don’t know how. I just know I want the source to be an OPML link from InoReader, so I never have to manually adjust the blogroll and it’s 100% automatic for the rest of my life. And I don’t particularly want a static snapshot of a blogroll to live on each individual post’s page. It’s another somewhat sticky problem for a static site.

Comments

There’s no comment form. A fairly glaring omission to readers.

The implementation of interactive comments on a static site, however, is not a simple thing. It has to be 100% Javascript. I’m reasonably confident nobody likes third-party comment tools like Disqus, and I don’t particularly want to use them either.

I have ideas. It’s complicated. Is it worth the effort? As a web development exercise, sure. As a blog site owner, maybe. I have thoughts and opinions about blog comments that don’t necessarily align with the blogging establishment. Anyway I just don’t have any time to do it right now.

Notifications

There’s no automated posting of new content to Twitter or other social media. It’s not that big of a deal, because surely everyone who cares has put my blog into their RSS feed reader of choice, but it would be nice to figure out a way to send out social media notifications.

A separate service that watches my RSS feed would probably suffice. Just some command-line programs I could schedule on my own PC would be good enough. Hard to find command-line tools to interact with web services, though, particularly Twitter. Twitter is a bit of a stick-in-the-mud about letting people use their API.

Search

There’s no search feature. Another casualty of a static site. This is a pretty low priority fix, because you can search the site, you just have to type it into Google to do it: “searchkeyword site:endgameviable.com”.

Conclusion

The main thing I’ve done by leaving WordPress, apparently, is take a blog that used to be all wrapped up in one convenient but monolothic application, and break it up into a spiderweb of disparate services that all have to work together. Yay microservices!