The second rename was not my idea
Defer Forms for Contact Form 7 has had two names before this one. The first rename was mine — the old name said nothing about what the plugin did, and its folder name broke a wordpress.org naming rule I'd rather have caught earlier. That one I chose, on my own schedule.
The second was not a choice. It went into wordpress.org review under its new name and came back rejected: the name led with a generic word and sat too close to an existing plugin's. Review doesn't negotiate. You get a reason and a rename.
The part worth writing down isn't the naming — plenty has been written about naming things. It's that a rename looks like a one-line change and isn't one, the moment the plugin has been installed anywhere.
A name is not just a label
The visible rename — the string in the plugin header, the text in the admin menu — took an afternoon. Everywhere else the old name was actually encoded took four more releases to find and fix, one at a time:
- The database table. Submissions, roles, everything the plugin stores lived under a table prefixed with the old internal short name.
- The developer hooks. Seven of them, documented, with real signatures — anyone
who had already filtered on
old_prefix_submission_createdneeded to know it was now something else, not silently stop firing. - The REST namespace. Every request the builder makes goes through it. Miss one reference and the admin looks fine until you open the one screen that calls it.
- Post meta keys, script and style handles, admin page URLs. The last one meant telling people to update their own bookmarks — a genuinely small cost, and still a cost, and still something I had to remember to say.
None of this shows up in a diff of the plugin's header comment. All of it is the actual rename.
The migration has to run once, and only once
The database table was the one that mattered most, because it's the one with a visitor's data in it. Renaming a table isn't a decision you make in code and walk away from — every install that already has the old table needs something to run, once, that moves its data to the new one before anything tries to read from the new name and finds nothing there.
That migration shipped in the same release as the prefix change. It checked for the old table, moved what it found, and got out of the way — the kind of code that is easy to write defensively and easy to forget about afterward, because once it's shipped it mostly just sits there working correctly for installs that need it and doing nothing for installs that don't.
Sitting there is not free, though. Every release after that carried one more piece of logic whose entire job was reasoning about a table name nothing was going to use going forward. That's a real, if small, tax — one more thing to read when you're trying to understand what a fresh install actually does, one more thing that could in principle misfire against data it was never meant to touch.
Knowing when it's safe to delete
The migration came out four releases later, and the reason it was safe to remove is the part I'd actually recommend paying attention to: not "it's probably fine by now," but a specific, checkable claim — this plugin has never been distributed under its old internal prefix. Every install anyone could download from that point on was already past the rename. There was no table for the migration to ever find, on any install that didn't already exist before the code was written, and there never would be one again.
That's a different thing from "nobody's complained." It's a claim about the distribution history, and it's the kind of claim you can actually check rather than assume. Dead code that runs a permission check first and does nothing is safe. Dead code you're only fairly sure is dead is a liability wearing the same clothes.
What I'd do differently
Rename the internal prefix in the same release as the visible name, not four releases later. Splitting them meant the plugin spent a stretch of its life with a public name that didn't match anything in its own codebase — which is confusing to read, and is exactly the kind of gap a second, unplanned rename can catch you in the middle of. The visible name is the one wordpress.org reviews. The internal one is the one that actually has to be right, and it deserves to move on the same day.