Clean up a WordPress database with 18 verified sweep types, one click at a time
Set up a database optimizer WordPress sites can actually trust: every sweep counts what it would touch, lets you preview real examples first, and deletes through core WordPress functions — never a blind DELETE statement against your live data.
- 18 whitelisted sweep types across posts, comments, users, terms and options.
- Preview up to 400 real items before deleting anything.
- No cron, no schedule — every sweep is a deliberate click.
- Uses core wp_delete_post()/wp_delete_comment(), not raw SQL.
Database optimizer WordPress: what does the module actually clean?
This is what a database optimizer WordPress sites get with TheOneWP: TOWP_Database_Optimizer exposes 18 whitelisted sweep types, each with its own count(), sweep() and details() method. An admin sees a live count and percentage per type, can preview up to 400 real examples before committing, and triggers cleanup one type at a time or all at once with "Sweep All." Deletion goes through core functions like wp_delete_post() and wp_delete_comment() where WordPress has one, processes up to 1,000 rows per click, and finishes with an OPTIMIZE TABLE pass scoped strictly to the site's own tables.
Every WordPress site quietly fills up
Revisions, auto-drafts, spam comments and expired transients build up in the background on every WordPress install, and nothing in core ever clears them out automatically.
A blind "clean everything" button is its own risk
A cleanup tool that deletes without showing what it is about to touch is asking an administrator to trust it blindly — the wrong assumption about "unused" data can remove something that still mattered.
Raw SQL deletes skip WordPress's own cleanup
Deleting posts or comments with a direct SQL statement instead of the WordPress functions built for it can leave orphaned meta, stale cache entries or hooks that never fire behind.
Count first, preview, then sweep
Every operation follows the same verified pattern: know the number, see real examples, then delete through the function WordPress itself would use.
18 sweep types, one whitelist
Every sweep name is checked against a fixed list before anything runs — nothing outside those 18 operations is possible.
See before you sweep
The details view returns up to 400 real titles, authors or meta keys so a sweep is never a guess about what "orphaned" actually means here.
Core deletion functions, not raw SQL
Posts, revisions and comments get removed with wp_delete_post(), wp_delete_post_revision() and wp_delete_comment(), so WordPress's own related cleanup still runs.
The complete database optimizer WordPress feature set
Every capability below exists as a real method, whitelist entry or UI control in the verified code.
18 sweep types, five categories
Posts, comments, users, terms, options and a final table-optimization pass — every type maps to a real, whitelisted operation.
Details before deletion
Up to 400 real examples per sweep type, so an administrator sees exactly what a sweep would remove before running it.
1,000-row batches per click
Each sweep processes up to 1,000 rows at a time, with the count and percentage updating live so a large backlog can be worked through in stages.
Sweep All, one operation at a time
A single button runs every non-empty sweep in sequence — never in parallel — with a beforeunload warning if you try to navigate away mid-run.
Default terms and non-post taxonomies excluded
The "unused terms" sweep skips each taxonomy's configured default term, and taxonomies not tied to any post type are excluded entirely.
Scoped OPTIMIZE TABLE pass
The final optimization step only ever targets tables carrying the site's own $wpdb->prefix, discovered fresh with SHOW TABLES LIKE.
Run a database optimizer WordPress cleanup in four steps
Review before deleting, then let Sweep All handle the rest in sequence.
Open the dashboard
Each sweep type shows its current count and percentage of the relevant table as soon as the page loads.
Check details on anything unfamiliar
Expand a row's details to see up to 400 real examples before deciding whether to sweep it.
Sweep individually or run Sweep All
Clear one type at a time, or let Sweep All work through every non-empty row in sequence.
Re-run for large backlogs
If a count does not reach zero after 1,000 rows, click Sweep again — the row updates live each time.
Where a real sweep makes a difference
The module fits sites where accumulated data has grown large enough to matter.
Content-heavy sites with years of edits
Years of autosaved revisions and stale auto-drafts add up in wp_posts and wp_postmeta without anyone noticing.
Sites with an active comment section
Spam and unapproved comments accumulate quietly until the comments table is doing far more work than it needs to.
Agencies doing routine maintenance
A quick pass through the dashboard before a migration or performance audit clears out data that has no reason to be copied along.
Cleanup with nothing hidden
Every design choice in the verified code favors transparency and WordPress-native behavior over speed alone.
Assets load only on the DB Optimizer screen
The verified implementation keeps its footprint limited to the page where it is actually used.
Hook-scoped CSS and JS
The dashboard's stylesheet and script enqueue only when the current admin page hook matches the DB Optimizer screen.
Batched, not bulk-deleted in one query
A 1,000-row limit per sweep keeps any single click from issuing an unbounded delete against a very large table.
Counts cached per request
Excluded taxonomies, excluded term IDs and the site's table list each compute once per request and get reused across the page.
Every sweep name checked before anything runs
The AJAX layer validates capability, identity and intent before a single query touches the database.
Capability check on every request
Both the sweep and details AJAX handlers require manage_options before doing anything else.
Whitelisted sweep names
The submitted sweep_name must match one of the 18 hardcoded entries in $valid_sweeps, rejecting anything else with a 400 response.
Per-operation nonces
Sweep and details actions each verify their own nonce, scoped to that specific sweep name rather than one nonce for every operation.
Prepared queries for dynamic values
Wherever a query includes excluded taxonomies or term IDs, the values pass through $wpdb->prepare() with placeholders — never string-concatenated directly.
Reads WordPress's own taxonomy and post type registry
The supplied code integrates through native WordPress data functions rather than assumptions about site structure. No compatibility claim beyond the verified implementation is assumed.
get_taxonomies() / get_post_types()
Exclusion logic reads the live taxonomy and post type registry, so custom post types and custom taxonomies are accounted for automatically.
Core post and comment functions
wp_delete_post(), wp_delete_post_revision() and wp_delete_comment() — the same functions other plugins already expect to fire.
towp_sweep_sweep / towp_sweep_details
Both the sweep result message and the details payload pass through filters before the AJAX response is sent.
TheOneWP versus common alternatives
Compare a real database optimizer WordPress implementation with typical dedicated cleanup plugins or a manual phpMyAdmin pass.
| Capability | TheOneWP DB Optimizer | Other common solutions |
|---|---|---|
| Preview before deleting | Up to 400 real examples per sweep type | Often shows only a count, not what is behind it |
| Deletion method | Core wp_delete_post()/wp_delete_comment() where available | Some tools issue raw DELETE statements directly |
| Scheduling | Manual only — no cron, no silent background runs | Some plugins schedule automatic cleanup by default |
| Table scope | Strictly this site's own $wpdb->prefix tables | Varies; manual SQL carries no such guardrail |
| Default term protection | A taxonomy's default term is excluded automatically | Manual cleanup can remove a default term by mistake |
| Bulk action behavior | Sweep All runs sequentially, one type at a time | Varies; some tools run everything at once |
| Administration | One TheOneWP dashboard, submenu or standalone | May require a separate plugin and its own menu |
Clean up with confidence, not guesswork
A few habits keep database cleanup safe on any size of site.
Back up before a first large sweep
Deletion through core functions is reliable, but a fresh backup costs little and removes any doubt before a big cleanup.
Check details on anything you did not expect
If a count looks larger than expected, open its details before sweeping — it is a 400-item preview, not a blind trust exercise.
Re-run large sweeps in stages
A count that does not hit zero after one click just has more than 1,000 rows — click again rather than assuming something went wrong.
Finish with Optimize Tables
Run the table-optimization pass after a large sweep so the freed space is actually reclaimed at the storage engine level.
Avoid assumptions the code does not support
The module has a defined, verified scope — a few assumptions outside it cause confusion.
Expecting it to run automatically
There is no scheduled event anywhere in the module. Nothing gets swept unless an administrator clicks a button for it.
Assuming one click clears an unlimited backlog
Each sweep processes up to 1,000 rows; a very large backlog needs the button clicked more than once.
Closing the tab mid-Sweep-All
The beforeunload warning exists because navigating away mid-run can leave a Sweep All pass incomplete — wait for the "done" status instead.
DB Optimizer FAQ
These answers come directly from the verified class, its AJAX handlers and the admin dashboard view.
How many sweep types does DB Optimizer actually cover?
Eighteen, all validated against a hardcoded whitelist: post revisions, auto-drafts, trashed posts, orphan/duplicate/oEmbed post meta, unapproved/spam/trashed comments, orphan/duplicate comment meta, orphan/duplicate user meta, orphan/duplicate term meta, orphan term relationships, unused terms, transient options, and a final table-optimization pass.
Does it delete posts and comments directly with SQL?
Only for meta rows, options and duplicate cleanup. Posts, revisions and comments go through wp_delete_post_revision(), wp_delete_post() and wp_delete_comment() — the same core WordPress functions any other deletion uses, so related cleanup and hooks still fire normally.
Can I see what will be deleted before running a sweep?
Yes. Each sweep type has a details() method that returns up to 400 actual titles, authors or meta keys for that operation, so an administrator can review real examples before clicking Sweep.
What happens on a site with more than 1,000 items to clean?
Each sweep click processes up to 1,000 rows. On a large backlog, the row's count and percentage update after each run, so clicking Sweep (or Sweep All) again continues where the previous batch left off.
Does "unused terms" risk deleting a taxonomy's default term?
No. The module excludes each taxonomy's configured default term ID (the one stored in its default_{taxonomy} option) before building the unused-terms query, so the fallback term a taxonomy needs cannot be swept away.
Does Optimize Tables touch tables from other plugins?
No further than the site's own WordPress installation. The table list comes from SHOW TABLES LIKE with the site's own $wpdb->prefix, so only this install's own tables are ever included.
Does DB Optimizer clean the database automatically on a schedule?
No. There is no cron job or scheduled event in the module — every count, sweep and optimization runs only when an administrator clicks a button.
What stops someone from triggering a sweep on a completely different table?
The AJAX handler checks the submitted sweep name against a fixed whitelist of 18 valid names before doing anything else, on top of the manage_options capability check and a per-sweep-name nonce.
Stop guessing what's safe to delete.See it, then sweep it.
Use a database optimizer WordPress admins can actually verify: real previews, core deletion functions, and a whitelist that never lets a sweep touch the wrong table.