Suffice it to say, I’d been gotten, and gotten so well that while I could find evidence they’d been there, I couldn’t find the script that was actually doing the damage.
Happily I had a solid backup that predated the hack, and happily, I guess, I hadn’t exactly been active around here since. So how did I handle the problem?
1. Wipe everything. Files, databases, everything.
2. Begin with a fresh installation of WordPress, a brand new database, and a new MySQL user.
3. Gradually rebuild the site.
4. Import tables one by one into the new database.
Unfortunately, I’m stuck in that last step. Here’s the problem: I’ve been running multiple sites via multiple WP installs, and a weakness in any of them threatens the others. (Not to mention the work of keeping all those installations up to date.) So I’ve decided to merge as much as I can into a single multi-site instance. And I figured I’d go ahead and use a subdirectory setup, rather than treating each site as a subdomain, as everything ultimately belongs under the umbrella of plannedobsolescence.net.
But! Because it can’t be that easy! WordPress 3.x, when set up as a subdirectory-based multisite installation, adds the slug “/blog/” to all of the permalinks of the main site. Which would of course be this site. Which means that all of my internal links are now broken, and any inbound links are broken as well.
I’m fighting with mod_rewrite right now, and while I’m hoping to find a better long-term solution than this, for the moment, if you’re looking for something in particular, you may want to scroll to the bottom of the page and search for it.
And if you’re smarter about mod_rewrite than I am (which really, really wouldn’t take much), let me know.