Polecenia usuwania w WP-CLI: których tabel dotyka każde z nich i co pozostawia

Usuwanie danych WordPressa oznacza więcej niż skasowanie wiersza tabeli. Funkcje aplikacji uwzględniają powiązania, liczniki, cache i rozszerzenia. Bezpośredni SQL pomija te procesy. Kluczowe są więc wybór obiektów, skutki uboczne i kopia zapasowa umożliwiająca rzeczywiste odtworzenie.

wp post delete i wp comment delete nie mają wbudowanego --dry-run. Inne polecenia WP-CLI oferują taki tryb. Wstępna lista pokazuje wybrane obiekty, ale nie symuluje hooków ani zmian plików i nie zlicza wszystkich dotkniętych wierszy bazy.

Zapisanie i sprawdzenie listy przed usuwaniem

Przykład Bash eksportuje bazę i zapisuje stałą listę wszystkich rewizji ze statusem inherit. Ścieżka instalacji, adres witryny i prywatny katalog kopii są wartościami przykładowymi wymagającymi dostosowania. Katalog kopii musi znajdować się poza katalogiem publicznym i aliasami serwera WWW.

#!/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"

Przed kolejnym krokiem potrzebne są kontrola identyfikatorów i powiązanych wpisów, poprawny eksport oraz sprawdzone odtwarzanie. Zrzut SQL nie zawiera mediów: usuwanie mediów wymaga także kopii uploads i ewentualnego magazynu zewnętrznego. Spójność kopii działającego systemu zależy od silników tabel i bieżących zapisów. Sam sukces eksportu nie dowodzi pełnej odtwarzalności.

Poniższy osobny etap usuwania korzysta wyłącznie ze sprawdzonego pliku. run_dir musi wskazywać wcześniej utworzony katalog. Rewizje są usuwane trwale; wybór może obejmować autozapisy.

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 ogranicza liczbę identyfikatorów na wywołanie; -r w GNU xargs zapobiega uruchomieniu przy pustym wejściu. Zbyt długa pojedyncza lista argumentów zwykle powoduje błąd już przy uruchamianiu procesu. Wiele partii może natomiast zakończyć się częściowym sukcesem: partie nie tworzą jednej operacji „wszystko albo nic”. Późniejszy błąd nie cofa automatycznie wcześniejszego usuwania. Kontroli wymagają kod zakończenia, logi i pozostałe obiekty. Zapisana lista zapobiega ponownemu wyborowi, ale nie równoległym zmianom systemu; większe porządki wymagają kontrolowanego okna serwisowego.

Co obsługują funkcje aplikacji

Trwałe usunięcie zwykłego wpisu obejmuje powiązane metadane, komentarze wraz z metadanymi, rewizje i relacje taksonomii. Same pojęcia taksonomii, np. kategorie i tagi, zwykle pozostają. Załączniki nie są automatycznie usuwane razem z wpisem; powiązania nadrzędne mogą zostać zmienione. Hooki to wyznaczone miejsca, w których wtyczki mogą uruchamiać własny kod. Umożliwiają rozszerzeniom sprzątanie, ale nie gwarantują kompletnej obsługi każdej wtyczki. Pomijanie wtyczek może również wyłączyć odpowiednie hooki.

Bezpośredni SQL DELETE wiersza wpisu nie uruchamia tych procesów WordPressa. Bez własnych wyzwalaczy lub relacji bazy pozostają zależne rekordy i potencjalnie nieaktualny cache. Takie wiersze nadal można odczytać zapytaniem. Późniejsze ponowne użycie tego samego ID może utworzyć błędne powiązania, ale nie jest nieuniknionym wynikiem każdego importu.

Liczby są przykładowymi identyfikatorami. Wybór spamu zapewnia wp comment list --status=spam --format=ids; wp comment delete --status=spam nie zastępuje listy ID. Przykładowa naprawa potwierdzonej rozbieżności licznika to wp comment recount 123, z identyfikatorem wpisu. Zwykłe usuwanie przez rdzeń nie wymaga z zasady przeliczania.

Kosz i cache mają różne ograniczenia

Bez --force WP-CLI przenosi odpowiednie wpisy do aktywnego kosza. Wpisy już znajdujące się w koszu, rewizje lub wyłączony kosz mogą mimo to oznaczać trwałe usunięcie. Przeniesienie do kosza zmienia także dane administracyjne poza statusem i nie jest niezależną kopią zapasową.

Transjenty są odtwarzalnymi wartościami cache i mogą zniknąć przed nominalnym terminem. --all obejmuje także wartości bazy bez czasu wygaśnięcia. Odbudowa może obciążyć system lub ujawnić błędy wtyczki; zapewnienie, że nic nie może się zepsuć, jest nieuzasadnione.

Przy trwałym cache obiektowym usuwanie pojedyncze i zbiorcze działa inaczej. wp transient delete KEY korzysta z API WordPressa i może usunąć klucz z aktywnego cache. W sprawdzonej implementacji WP-CLI opcje --all i --expired dotyczą natomiast rekordów bazy i zgłaszają ostrzeżenie przy zewnętrznym cache. Obsługiwany backend pozwala opróżnić grupę przez wp cache flush-group; nazwa grupy i zakres wymagają ustalenia. Pełne wp cache flush obejmuje znacznie więcej i zależnie od backendu może dotknąć innych witryn.

Celowa ocena OPTIMIZE TABLE

MySQL zwykle przebudowuje zwykłe tabele InnoDB online przy OPTIMIZE TABLE. Blokady wyłączne występują przede wszystkim podczas przygotowania i zatwierdzania; niektóre ustawienia lub indeksy FULLTEXT wymagają innego przebiegu. MariaDB, silnik i wersja wymagają osobnej oceny. Ciągła blokada zapisu nie jest uniwersalną zasadą InnoDB.

Miejsce po usuniętych danych może zostać ponownie wykorzystane wewnętrznie. Zwrot przestrzeni systemowi plików zależy między innymi od przestrzeni tabel i przebudowy, a nie od braku jakichkolwiek zapisów po usuwaniu. Plan powinien uwzględniać czas, miejsce robocze, operacje I/O i oczekiwanie na blokady. Nie wynika z tego potrzeba bezwarunkowego zadania co noc.

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'