WP-CLI Delete Commands: Which Tables Each One Touches and What It Leaves Behind

Deleting WordPress data means more than removing a table row. Application functions account for relationships, counts, caches and extensions. Direct SQL bypasses these workflows. The important questions are the selected objects, side effects and a backup that can actually be restored.

wp post delete and wp comment delete have no built-in --dry-run. Other WP-CLI commands do provide one. A preliminary list shows the selected objects, but does not simulate hooks or file changes and does not count every affected database row.

A saved and reviewed selection before deletion

This Bash example exports the database and saves a fixed list of all revisions with status inherit. The installation path, site URL and private backup directory are placeholders requiring adaptation. The backup directory must be outside the webroot and any public web-server alias.

#!/usr/bin/env bash
set -euo pipefail
umask 077
wp_path=/srv/www/example-wordpress
site_url=https://example.invalid
backup_dir=/srv/private/wp-backups
mkdir -p -- "$backup_dir"
run_dir=$(mktemp -d "$backup_dir/revisions.XXXXXXXX")
wp --path="$wp_path" --url="$site_url" db export "$run_dir/database.sql"
wp --path="$wp_path" --url="$site_url" post list \
  --post_type=revision --post_status=inherit --posts_per_page=-1 \
  --orderby=ID --order=ASC --format=ids > "$run_dir/revision-ids.txt"
wc -w < "$run_dir/revision-ids.txt"
printf 'Review directory: %s\n' "$run_dir"

The next step requires reviewing the IDs and associated posts, a successful export and a tested restore. An SQL dump contains no media files: media deletion also requires an uploads backup and, where relevant, external-storage backups. Consistency on a live system depends on table engines and ongoing writes. Successful export alone does not prove complete recoverability.

The following separate deletion step uses only the reviewed file. run_dir must identify the directory created earlier. Revisions are permanently removed; the selection can include autosaves.

wp_path=/srv/www/example-wordpress
site_url=https://example.invalid
run_dir=/srv/private/wp-backups/revisions.REVIEWED
xargs -r -n 100 wp --path="$wp_path" --url="$site_url" \
  post delete --force < "$run_dir/revision-ids.txt"

xargs -n 100 limits IDs per invocation; GNU xargs -r prevents execution with empty input. An oversized single argument list normally fails at process startup. Multiple batches, however, may succeed only partially: the batches are not one all-or-nothing operation. A later failure does not automatically undo earlier deletions. Exit status, logs and remaining objects require checking. A saved list prevents reselection, but not concurrent system changes; larger cleanups benefit from a controlled maintenance window.

What application functions handle

Permanent deletion of an ordinary post removes related post metadata, comments and their metadata, revisions and taxonomy relationships. The terms themselves normally remain. Attachments are not automatically deleted together with the post; parent relationships may change. Hooks are predefined points at which plugins can run their own code. These allow extensions to perform cleanup, but do not guarantee complete cleanup by every extension. Skipping plugins may also omit their hooks.

A direct SQL DELETE of the post row does not execute these WordPress workflows. Without custom database triggers or relationships, dependent records and potentially stale cache entries remain. Such rows are still queryable. Later reuse of the same ID can create incorrect associations, but is not an inevitable result of every import.

The numbers are illustrative IDs. Spam selection uses wp comment list --status=spam --format=ids; wp comment delete --status=spam does not replace an ID list. A targeted repair for a demonstrated count discrepancy is, for example, wp comment recount 123, using a post ID. Ordinary core deletion does not inherently require a recount.

Trash and caches have different limits

Without --force, WP-CLI moves eligible posts into enabled trash. Already trashed entries, revisions or disabled trash can still result in permanent deletion. Trashing changes related administrative data as well as status and is not an independent backup.

Transients are disposable cache values and may disappear before their nominal expiry. --all also includes database values without expiration. Rebuilding may cause load or reveal plugin failures; “nothing can break” is not a defensible guarantee.

With persistent object caching, individual and bulk deletion differ. wp transient delete KEY uses the WordPress API and can remove a key in the active cache. In the reviewed WP-CLI implementation, --all and --expired instead operate on database records and warn about external caching. A supported backend allows group flushing through wp cache flush-group; the correct group and scope must be established. A complete wp cache flush affects much more and may reach other sites depending on the backend.

Assessment of OPTIMIZE TABLE

MySQL generally rebuilds ordinary InnoDB tables online for OPTIMIZE TABLE. Exclusive locks occur particularly during preparation and commit; some settings or FULLTEXT indexes require a different procedure. MariaDB, engine and version need separate assessment. A continuous write lock is not a universal InnoDB rule.

Deleted space can be reused internally. Returning space to the filesystem depends on factors including tablespace layout and rebuilding, not on whether any writes occurred after deletion. Planning needs to account for runtime, temporary space, I/O and lock waits. This does not justify an indiscriminate nightly job.

wp db query 'SELECT COUNT(*) FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL'