The Plugin-Author Check-In Checklist

The idea behind this check-in is the one Iris named in the episode: the code, when you went back to it, was working. This isn’t a code-quality check. It’s a contract check — confirming the plugin you put your name on is still doing what the readme promises, on the WordPress version most of your install base is actually running.

Step 1 — Confirm the install base

Open the plugin’s page on the WordPress.org directory. Note:

• Active installs (rounded to the nearest 10 / 100 / 1000)
• Last updated date
• Tested up to WordPress version
• Requires PHP

If “tested up to” is two major WordPress versions behind, your plugin is still installing on sites you have no idea about, on a stack you no longer claim to support. That gap is the contract issue.

Step 2 — Read the readme, then read the code

Side-by-side, on the same screen:

• Does the readme accurately describe what the plugin does?
• Are the screenshots current?
• Is the FAQ answering questions people actually ask, or questions you anticipated when you wrote it?
• Does the “upgrade notice” section say anything about the last change, even if it was years ago?

Then open the main plugin file. Read it the way a stranger would read code with your name in the header.

• Does the code do what the readme says it does?
• Are there functions that exist but aren’t called anywhere?
• Are there links in the comments or admin notices that point to URLs that don’t exist anymore?
• Is there a settings page that loads dead links to third-party services?

Step 3 — Functional check on current WordPress

On a staging environment running the current stable WordPress and current stable PHP:

• Activate the plugin
• Visit each admin page the plugin adds
• Trigger each user-facing feature the plugin provides
• Check the browser console and PHP error log for warnings, notices, deprecation messages

Three failure modes to look for specifically:

1. PHP deprecation warnings — the plugin uses something WordPress core has deprecated. Still works; about to stop working.
2. Dead third-party integrations — social-sharing buttons that point to services that no longer exist, API endpoints that have changed, OAuth callbacks that don’t authenticate anymore.
3. Silent failures — features that the readme says work but don’t actually do anything because some dependency has shifted under the plugin.

Step 4 — The contract questions

These are the questions only you can answer:

• If I were installing this plugin today, for the first time, would I be okay with what it does?
• Would I be comfortable with my name in the header?
• If the answer is no, am I willing to either (a) rewrite it to a current standard, or (b) remove it from the directory?

The eleven-year answer in episode 1 was “rewrite.” That’s the harder path. Removing from the directory is also a valid answer — and a more honest one than letting the plugin keep installing under a name that isn’t standing behind it.

Step 5 — Document the decision

In a CONTRACT.md file at the root of the plugin repo (or in a private note if the repo isn’t public):

• Date of this check-in
• WordPress and PHP versions tested against
• Findings
• Decision: maintain / rewrite / remove
• Next check-in date

The check-in itself becomes the contract — a written record that you looked, what you saw, and what you decided to do about it.

When to do this

For most plugin authors with names in headers, once a year is enough. The major WordPress release cadence is roughly twice a year; a once-a-year check-in catches the gap before it widens.

If you have multiple plugins, alphabetize them and do one per month. After twelve months you’ve reviewed everything.

Built to go with episode 1 of Sites I’ve Never Seen, and the source essay What You Owe the People Still Running Your Old Code.