I'm sitting in another Blue Bottle cafe, this time in Berkeley. These are nice places. Slightly stark, with the plywood-concrete-whiteplastic thing, but the acoustics seem fine and the tables are a good height at which to code. The coffee isn't as good as I had the other day; I'm still on the search for a decently over-roasted moka pot brew; this is as good as I've had though. I don't see why they can't serve a cup with a saucer though—I understand not having napkins, that's a good idea, but without either all I'm left with is a drippy coffee splash on the bench here.
I'm working on my silly little Log404 MediaWiki extension this morning, because I want to be able to retire my WordPress installation and do everything here in the wiki. So far, it's recording, reporting, redirecting, and deleting not-found pages, but I need it to handle redirects better and it seems there's some better way to work with query strings of the log entries. It should also be able to ignore 404s. I'm giving up for the time being on catching 'found' not-found pages such as
example.org/?foo=123 which as things stand just redirects to the Main Page and is not considered a missing page. If one were migrating from a system that treated that as its own page, things wouldn't work. Perhaps it'll be enough to check for unknown query string parameters only for Main Page (because I don't suppose we should be doing it on load of every page in the wiki). That can all wait; at least so far it's going to be possible to catch e.g.
example.org/2018/12/29/foo and quickly redirect it to
Foo or wherever.
Does it need to store both the 404 page name and the whole query string, given that the latter always contains the
title attribute? It might not be, but it might be easier to query this way... oh, and actually, given that the page title is the only thing we can redirect (i.e
/Bar?foo=123 can't be handled separately) it probably does make sense. Why then are we including the query string?