![\"Two](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/loeschbefehle-en.png\")
The Two-Step Pattern That Replaces the Dry Run<\/h2>\n
Every destructive command has a harmless sibling that takes the same filter. The The backup line has a detail worth keeping: without a path, A direct The first row is the one that surprises people. Deleting a post does not delete the images in it – attachments are posts in their own right, with their own IDs, and they survive their parent. A site cleaned of a thousand old posts therefore still carries a thousand posts’ worth of media, which is where the disk space actually went.<\/p>\n The comment count row is the cheapest to fix and the easiest to forget: after any bulk comment deletion, Without With Transients are a cache with an expiry stored alongside the value. It is also the step that most reliably reclaims nothing. Space freed by deleted rows is already reused by InnoDB for new rows; the file on disk only shrinks if a great deal was deleted and nothing has been written since. Worth running once after a large cleanup, at a quiet hour, and not worth putting in a nightly cron – which is precisely where it usually ends up.<\/p>\nwp post delete<\/code> has wp post list<\/code>; wp comment delete<\/code> has wp comment list<\/code>. Running the list first with --format=count<\/code> answers the only question a dry run would have answered: how many rows is this about to remove.<\/p>\n# 0. a backup, outside the document root\nwp db export \/home\/pi\/backup-$(date +%F).sql\n\n# 1. count, with exactly the filter that will be used\nwp post list --post_type=revision --format=count\n\n# 2. delete, with exactly the same filter\nwp post list --post_type=revision --format=ids | xargs -n 100 wp post delete --force<\/code><\/pre>\nxargs<\/code> in the last line is not decoration. Substituting several thousand IDs directly into the command line runs into the argument length limit, and the failure arrives after some of the work is done rather than before any of it – which is the one situation the whole exercise was meant to avoid.<\/p>\nwp db export<\/code> writes the dump into the current directory, and the current directory during a WordPress command is usually the document root. A full database dump with a guessable name, served over HTTP, is a worse outcome than anything the cleanup was going to fix.<\/p>\nTwo Ways to Remove the Same Row<\/h2>\n
wp post delete<\/code> calls the same function the editor calls. It removes the post meta, the comments, the comment meta and the term relationships, and it fires the hooks that let plugins remove whatever they attached elsewhere – a search index entry, a cache, a row in their own table.<\/p>\nDELETE FROM wp_posts<\/code> removes one row. Everything that referred to it stays, unreachable and invisible: no query joins to a post that is gone, so the rows simply never appear again. That is tolerable until an ID is reused, and post IDs are reused after a database import – at which point the new post silently inherits the old one’s custom fields and comments.<\/p>\nWhat Each Command Actually Touches<\/h2>\n
\n\n
\n \nCommand<\/th>\n Removes<\/th>\n Leaves behind<\/th>\n<\/tr>\n<\/thead>\n \n wp post delete <id> --force<\/code><\/td>\npost, meta, comments, term links<\/td>\n the attached media files and their attachment rows<\/td>\n<\/tr>\n \n wp post delete <attachment> --force<\/code><\/td>\nthe row and the files on disk, all sizes<\/td>\n references to the URL inside other posts<\/td>\n<\/tr>\n \n wp post delete <revisions><\/code><\/td>\nthe revisions and their own meta rows<\/td>\n the parent post, untouched<\/td>\n<\/tr>\n \n wp comment delete --status=spam<\/code><\/td>\ncomments and comment meta<\/td>\n the per-post comment counts, until a recount<\/td>\n<\/tr>\n \n wp transient delete --expired<\/code><\/td>\nonly transients whose expiry has passed<\/td>\n every transient stored without an expiry<\/td>\n<\/tr>\n \n wp db optimize<\/code><\/td>\nnothing<\/td>\n a table lock for the duration of the rebuild<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n wp comment recount<\/code> puts the numbers back in agreement with the rows. Nothing breaks without it; the counts are simply wrong, everywhere, quietly.<\/p>\nThe Trash Is Not a Backup<\/h2>\n
--force<\/code>, deleting moves a post to the trash, which is a status change and nothing more. The row stays, the meta stays, the media stays, and the space is not freed – a trash emptied once a month is a housekeeping habit, not a safety net.<\/p>\n--force<\/code> the post skips the trash entirely and there is no undo inside WordPress at all. The only thing standing between a mistyped filter and a lost month is the dump written in step zero, which is the reason it is step zero.<\/p>\nExpired Is Not the Same as All<\/h2>\n
wp transient delete --expired<\/code> removes those whose time has passed and is safe by construction: anything it deletes was already invalid.<\/p>\n--all<\/code> is a different command wearing the same name. It also removes transients stored without an expiry, and some plugins use exactly those as their only storage for something that was expensive to compute – a licence check, an inventory, a rendered menu. Nothing breaks visibly; the site simply spends the next hour rebuilding things nobody asked it to rebuild, and one or two plugins behave as if they had just been installed.<\/p>\nOptimising Is a Rebuild, Not a Tidy-Up<\/h2>\n
wp db optimize<\/code> runs OPTIMIZE TABLE<\/code>, and for InnoDB that is not an optimisation but a full rebuild of the table plus its indexes. The table is locked for writes while it happens, which on a small blog is a second and on a large wp_postmeta<\/code> is long enough for visitors to notice.<\/p>\n