Brad Williams and I have shared a few Bobby Tables
jokes while working on the manuscript for Professional WordPress
. SQL injection attacks are nasty, somewhat common, and often require a complete rebuilding of your site to purge and move on.
index.html for my site, ensuring that all traffic would see an apology and not an attack vector.
Without laying public blame, I’m not sure if it came in through a backdoor in my service provider, or via the front door of my WordPress installation, and my (former) server provider refuses to share logs or other information that might exonerate my own site administration. This is the last straw with said provider; last summer it was performance issues (that were also blamed on me, not their shuffling of MySQL instances) and their continued promotion of add-on services. If I thought their basic services were well-run, I wouldn’t be so annoyed.
Upon discovery, I did what any reasonably panicked person would do: dumped the WordPress content in an extended XML file, wrote some scripts to edit out all of the bad stuff (and remove Google AdWords short codes that were in about 250 entries, since I no longer use AdWords on the site), set up a new hosting account with a new provider (BlueHost, at Brad’s suggestion), and re-loaded all 650+ pages and posts. The longest time pole in the tent was getting the DNS entries updated (since I did two updates, one when I took down the site and one when I moved it to a new provide, and had to wait for the first one to propagate).
There’s still a lot to do — I need to hand-edit the photos (since I didn’t download them first); sidebars, theme work, Google Analytics, and other decoration. At the same time, this forces me to work on a few things that I’ve had in notes but not in action plans – theme updates, cleaning up sidebars, adding in appropriate SEO hooks, and most of all, a conviction to stay up to date with WordPress updates.
Like Frosty, I’m back, need to put that magic hat back on my head, and ready to play again.