After about two and a half years of being "temporarily down for maintenance," the Tag Search function of this blog and that of the art gallery are now back up and running.
I had taken them down in September 2013 when I found an XSS vulnerability. While I'd meant to get them back up quickly, I ended up confusing myself into thinking that the code was beyond repair and abandoned it in favor of writing a new tag search from scratch. (Throwing out your whole existing codebase tends to be a terrible idea, but as with most terrible ideas, it seemed like this time, it was a good idea. It wasn't.)
One roadblock led to another, and I kept setting the project aside in favor of other things. Eventually, I got fed up enough to ask whether that old version was really as irreparable as I'd thought, and it turned out that the bug that looked so daunting was actually fairly trivial to find and fix once I knew where to look.
Here's where things currently stand: The old search is now online again and functional, with a few bugfixes and a cosmetic improvement or two over its previous live version. You can search for one or more tags, and it will return a list of all pages tagged with all the given tags. It ignores search terms that no pages are tagged with.
What it doesn't do, unfortunately, is sort the results. I'd like to have it display the most recent pages first, but currently it doesn't do that. Instead, it's displaying the results alphabetically, according to filename rather than title. I have yet to comb through the code to determine if it's even trying to sort anything, but in any case I'll have to make some bigger changes to enable it to grab post dates in the first place before it can use them for sorting.
Meanwhile, for the "new" version, I have an SQLite database schema mostly hammered out, though I now realize that I'll need to add the post date to that as well. I also have a data-access class that is capable of setting up the database, but doesn't have methods to query it yet. The latest hurdle was deciding how to store dates (since SQLite doesn't have its own specific date/time data type and will let you stick any data of any type into most fields) and updating the schema and database-creation logic to match. Now, of course, I realize that this schema didn't have a place for the post date either, so it would have the same bug as the current version.
So while I'm going to keep that in my back pocket (in the spirit of "don't throw away code that works") so I'll have a starting point if I ever decide to migrate to SQLite, I'm going to keep the current version as the canonical version for now and (as Joel Spolsky recommends in the article linked above) just keep making incremental changes to it until it does what I need and stops being ugly. One day, it will be glorious. In the mean time, it will still work.