![\"Zwei](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/loeschbefehle-de.png\")
Das Zweischrittmuster, das den Probelauf ersetzt<\/h2>\n
Zu jedem zerst\u00f6renden Befehl gibt es ein harmloses Geschwister, das denselben Filter annimmt. Zu Das Die Sicherungszeile enth\u00e4lt eine Feinheit, die im Ged\u00e4chtnis bleiben sollte: Ohne Pfad schreibt Ein unmittelbares Die erste Zeile \u00fcberrascht am h\u00e4ufigsten. Einen Beitrag zu l\u00f6schen, l\u00f6scht die Bilder darin nicht – Anh\u00e4nge sind eigene Beitr\u00e4ge mit eigenen Nummern und \u00fcberleben ihren Erzeuger. Eine um tausend alte Beitr\u00e4ge erleichterte Seite tr\u00e4gt also weiterhin tausend Beitr\u00e4ge an Medien mit sich, und dort ist der Plattenplatz auch geblieben.<\/p>\n Die Zeile mit den Kommentarz\u00e4hlern ist am billigsten zu beheben und am leichtesten zu vergessen: Nach jedem gr\u00f6\u00dferen Kommentarl\u00f6schen bringt Ohne Mit Transienten sind ein Zwischenspeicher mit einer neben dem Wert abgelegten Frist. Es ist zugleich der Schritt, der am verl\u00e4sslichsten nichts zur\u00fcckgewinnt. Platz aus gel\u00f6schten Zeilen wird von InnoDB bereits f\u00fcr neue Zeilen wiederverwendet; die Datei auf der Platte schrumpft nur, wenn sehr viel gel\u00f6scht wurde und seitdem nichts geschrieben. Einmal nach einem gro\u00dfen Aufr\u00e4umen zu einer ruhigen Stunde lohnt sich – in einem n\u00e4chtlichen Cron aufgehoben zu sein lohnt sich nicht, und genau dort landet der Befehl f\u00fcr gew\u00f6hnlich.<\/p>\nwp post delete<\/code> geh\u00f6rt wp post list<\/code>, zu wp comment delete<\/code> geh\u00f6rt wp comment list<\/code>. Die Liste zuerst mit --format=count<\/code> zu fahren, beantwortet die einzige Frage, die ein Probelauf beantwortet h\u00e4tte: um wie viele Zeilen es gleich geht.<\/p>\n# 0. eine Sicherung, außerhalb des Web-Verzeichnisses\nwp db export \/home\/pi\/sicherung-$(date +%F).sql\n\n# 1. zählen, mit genau dem Filter, der gleich verwendet wird\nwp post list --post_type=revision --format=count\n\n# 2. löschen, mit genau demselben Filter\nwp post list --post_type=revision --format=ids | xargs -n 100 wp post delete --force<\/code><\/pre>\nxargs<\/code> in der letzten Zeile ist keine Zierde. Mehrere tausend Nummern unmittelbar in die Befehlszeile einzusetzen, l\u00e4uft in die L\u00e4ngenbegrenzung der Argumente, und der Fehler kommt, nachdem ein Teil der Arbeit erledigt ist, statt bevor irgendetwas geschehen ist – also genau in der Lage, die das ganze Vorgehen vermeiden sollte.<\/p>\nwp db export<\/code> den Abzug in das aktuelle Verzeichnis, und das ist bei einem WordPress-Befehl meist das Web-Verzeichnis. Ein vollst\u00e4ndiger Datenbankabzug mit erratbarem Namen, \u00fcber HTTP ausgeliefert, ist ein schlimmeres Ergebnis als alles, was das Aufr\u00e4umen beheben sollte.<\/p>\nZwei Wege, dieselbe Zeile zu entfernen<\/h2>\n
wp post delete<\/code> ruft dieselbe Funktion auf wie der Editor. Der Befehl entfernt die Metadaten, die Kommentare, die Kommentarmeta und die Begriffsverkn\u00fcpfungen, und er l\u00f6st die Haken aus, \u00fcber die Erweiterungen entfernen k\u00f6nnen, was sie anderswo angelegt haben – einen Sucheintrag, einen Zwischenspeicher, eine Zeile in ihrer eigenen Tabelle.<\/p>\nDELETE FROM wp_posts<\/code> entfernt eine Zeile. Alles, was auf sie verwies, bleibt liegen, unerreichbar und unsichtbar: Keine Abfrage verbindet sich mit einem Beitrag, den es nicht gibt, also tauchen die Zeilen schlicht nie wieder auf. Das ist tragbar, bis eine Nummer erneut vergeben wird – und Beitragsnummern werden nach einem Datenbankeinspielen erneut vergeben. Dann erbt der neue Beitrag lautlos die eigenen Felder und die Kommentare des alten.<\/p>\nWas jeder Befehl tats\u00e4chlich anfasst<\/h2>\n
\n\n
\n \nBefehl<\/th>\n Entfernt<\/th>\n L\u00e4sst stehen<\/th>\n<\/tr>\n<\/thead>\n \n wp post delete <Nr> --force<\/code><\/td>\nBeitrag, Metadaten, Kommentare, Begriffe<\/td>\n die angeh\u00e4ngten Dateien und ihre Anhangszeilen<\/td>\n<\/tr>\n \n wp post delete <Anhang> --force<\/code><\/td>\ndie Zeile und die Dateien auf der Platte, alle Gr\u00f6\u00dfen<\/td>\n Verweise auf die Adresse in anderen Beitr\u00e4gen<\/td>\n<\/tr>\n \n wp post delete <Revisionen><\/code><\/td>\ndie Revisionen und deren eigene Metazeilen<\/td>\n den Beitrag selbst, unangetastet<\/td>\n<\/tr>\n \n wp comment delete --status=spam<\/code><\/td>\nKommentare und Kommentarmeta<\/td>\n die Kommentarz\u00e4hler je Beitrag, bis zum Nachz\u00e4hlen<\/td>\n<\/tr>\n \n wp transient delete --expired<\/code><\/td>\nnur Transienten, deren Frist verstrichen ist<\/td>\n jeden Transienten, der ohne Frist gespeichert wurde<\/td>\n<\/tr>\n \n wp db optimize<\/code><\/td>\nnichts<\/td>\n eine Tabellensperre f\u00fcr die Dauer des Neuaufbaus<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n wp comment recount<\/code> die Zahlen wieder mit den Zeilen in \u00dcbereinstimmung. Ohne das geht nichts kaputt; die Z\u00e4hler sind blo\u00df falsch, \u00fcberall und lautlos.<\/p>\nDer Papierkorb ist keine Sicherung<\/h2>\n
--force<\/code> verschiebt das L\u00f6schen einen Beitrag in den Papierkorb, und das ist eine Status\u00e4nderung und sonst nichts. Die Zeile bleibt, die Metadaten bleiben, die Medien bleiben, und Platz wird nicht frei – ein einmal im Monat geleerter Papierkorb ist eine Pflegegewohnheit und kein Sicherheitsnetz.<\/p>\n--force<\/code> \u00fcberspringt der Beitrag den Papierkorb vollst\u00e4ndig, und innerhalb von WordPress gibt es \u00fcberhaupt kein Zur\u00fcck. Zwischen einem vertippten Filter und einem verlorenen Monat steht allein der Abzug aus Schritt null – deshalb ist es Schritt null.<\/p>\nAbgelaufen ist nicht dasselbe wie alle<\/h2>\n
wp transient delete --expired<\/code> entfernt die, deren Zeit verstrichen ist, und ist von der Anlage her ungef\u00e4hrlich: Was gel\u00f6scht wird, war ohnehin ung\u00fcltig.<\/p>\n--all<\/code> ist ein anderer Befehl im selben Gewand. Er entfernt auch Transienten ohne Frist, und manche Erweiterungen verwenden genau die als einzigen Ablageort f\u00fcr etwas, dessen Berechnung teuer war – eine Lizenzpr\u00fcfung, einen Bestand, ein fertig gebautes Men\u00fc. Sichtbar geht nichts kaputt; die Seite verbringt blo\u00df die n\u00e4chste Stunde damit, Dinge neu zu bauen, um die sie niemand gebeten hat, und ein oder zwei Erweiterungen benehmen sich, als w\u00e4ren sie gerade installiert worden.<\/p>\nOptimieren ist ein Neuaufbau, kein Aufr\u00e4umen<\/h2>\n
wp db optimize<\/code> f\u00fchrt OPTIMIZE TABLE<\/code> aus, und bei InnoDB ist das keine Optimierung, sondern ein vollst\u00e4ndiger Neuaufbau der Tabelle samt ihrer Indizes. F\u00fcr die Dauer ist die Tabelle f\u00fcr Schreibzugriffe gesperrt, was bei einem kleinen Blog eine Sekunde dauert und bei einer gro\u00dfen wp_postmeta<\/code> lange genug, dass Besucher es merken.<\/p>\n