The Delete Button Is Not Your Friend
There’s a specific kind of frustration that only web hosting can produce. It’s not the sharp anger of a broken laptop or the dull ache of a slow internet connection. It’s a slow-burning, compounding, recursive irritation that builds across weeks of inexplicable downtime, support tickets that get answered in Kafka-esque generalities, and a control panel UI that seems to have been designed by someone who hated both you and themselves.
So I nuked it. The whole thing. Pulled the plug on a WordPress site I’d been running for a few years and walked away feeling righteous.
The Regret Phase
It turns out I had written more than I remembered. Not in any earth-shattering, posterity-demanding way — just personal notes, technical walkthroughs, observations that no longer existed anywhere except a MySQL database I’d had the foresight to dump before the deletion ceremony. The WordPress install was gone. The theme, the plugins, the media — gone. But the .sql file sat in a folder doing nothing.
Enter Codex
I had the database. I did not have the patience to stand up a local WordPress instance, import the dump, wrestle with PHP version conflicts, fight the MySQL user permissions dialog, and then manually copy-paste every post out of an admin panel just to read my own words back.
So I handed the whole problem to Codex instead.
The workflow was surprisingly clean. I gave Codex the SQL dump and asked it to extract and reconstruct the posts — content, titles, slugs, dates, the works. It parsed the wp_posts table, filtered out the noise (revisions, auto-drafts, nav menu items — the WordPress database is louder than you’d expect), and returned the actual published content in readable form.
From there, it was a straightforward matter of reviewing what had survived and deciding what was worth bringing forward.
What Codex Actually Did Well
The thing that would have taken me the longest — locating and extracting the relevant rows from a database schema I hadn’t touched in over a year — took Codex about thirty seconds. WordPress’s database structure isn’t documented in a way that invites casual browsing. The wp_posts table has twenty-something columns, posts live alongside revisions which live alongside widget data which lives alongside things that are technically posts but are definitely not posts.
Codex navigated all of that without me needing to write a single SQL query from scratch. It interpreted what I was asking for contextually, handled the schema without needing a walkthrough, and surfaced the content in a format I could actually use.
It’s a good reminder that “I have the data” and “I can access the data” are two different problems. The first I solved with a timely database backup. The second Codex solved for me.
The Part I Should Have Done Differently
Backed up the media library. Obviously. The MySQL dump got me all the text — every post, every block of prose, every half-finished thought I’d committed to the editor — but WordPress stores uploaded images on the filesystem, not in the database. Those are gone, and they’re not coming back.
If you’re running a WordPress site right now and you think a database dump is a full backup, it is not. It is half a backup. Go set up an offsite file backup before you finish reading this.
The Silver Lining Nobody Asked For
Losing the old site and rebuilding from the database was, accidentally, a better editorial process than anything I would have done voluntarily. Starting from raw SQL output forces you to read everything you wrote before deciding to publish it again. There’s no “I’ll clean that up later” when you’re manually reviewing exported content. You either move it forward or you don’t.