Uninstall leftovers the WordPress.org review still misses

Many plugin teams test activation, settings, and one happy path, then call it done. Uninstall gets skipped until a support thread says “I removed your plugin and my database is still full of your stuff.”

WordPress.org review catches many important issues, but uninstall residue is still a practical risk you should verify with human QA in wp-admin before release.

What “leftovers” usually means

• Options rows in wp_options with your prefix still present after uninstall.
• Cron events still scheduled, continuing to fire against code that is now gone.
• Custom tables left behind unintentionally.
• Uploads and temp files never removed or documented.
• User capability / role changes that are not reverted.

Some data retention is valid when users explicitly choose it. Silent retention by default is the problem.

Why static checks are not enough

Static review can confirm your uninstall file exists. It cannot prove the full install → use → deactivate → delete path behaves correctly in a realistic environment with actual state.

That final path needs a human run with a checklist and recording.

A practical uninstall QA brief

1. Start in a fresh sandbox with your plugin installed and activated.
2. Create residue on purpose: save settings, run any setup wizard, create plugin-owned records, and trigger scheduled tasks if possible.
3. Deactivate and delete via wp-admin plugins screen.
4. Verify cleanup checklist: options keys, custom tables, scheduled cron, uploads/temp files, and role/cap changes.
5. Record evidence: where each check passed or failed, with timestamps.

Use isolated sandboxes so every tester starts from the same state: WordPress plugin sandboxes.

Keep-data toggle: make it explicit

If your plugin has legitimate reasons to preserve data, gate it behind a clear setting (for example, “Keep data on uninstall”). Then test both branches:

• Keep-data off: uninstall should remove plugin-owned artifacts.
• Keep-data on: uninstall should preserve exactly what you document, no more.

Ambiguous behavior creates support debt and harms trust.

Submission format that is easy to review

Ask testers for structured evidence, not essays:

• Completed / blocked outcome.
• Checklist row per artifact class (options, cron, tables, files, roles).
• Timestamp to each failure in recording.
• Severity and reproducibility notes.

This lets you approve or reject quickly and rerun the same brief after fixes.

On QATested

QATested WordPress plugin testing gives each tester an isolated wp-admin so uninstall checks are comparable. Post the uninstall brief, require recording, and review against one checklist. Related: what Plugin Check can’t see in real wp-admin · briefing conflict tests · post a Structured QA test.