![\"Dwie](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/loeschbefehle-pl.png\")
Wzorzec dw\u00f3ch krok\u00f3w zast\u0119puj\u0105cy przebieg pr\u00f3bny<\/h2>\n
Do ka\u017cdego polecenia niszcz\u0105cego istnieje nieszkodliwe rodze\u0144stwo przyjmuj\u0105ce ten sam filtr. Do Wiersz z kopi\u0105 zawiera szczeg\u00f3\u0142 warty zapami\u0119tania: bez \u015bcie\u017cki Bezpo\u015brednie Pierwszy wiersz zaskakuje najcz\u0119\u015bciej. Usuni\u0119cie wpisu nie usuwa zawartych w nim obraz\u00f3w – za\u0142\u0105czniki s\u0105 osobnymi wpisami z w\u0142asnymi numerami i prze\u017cywaj\u0105 swojego rodzica. Witryna odchudzona o tysi\u0105c starych wpis\u00f3w nadal niesie ze sob\u0105 tysi\u0105c wpis\u00f3w medi\u00f3w, i tam w\u0142a\u015bnie zosta\u0142o miejsce na dysku.<\/p>\n Wiersz z licznikami komentarzy najtaniej naprawi\u0107 i naj\u0142atwiej zapomnie\u0107: po ka\u017cdym wi\u0119kszym kasowaniu komentarzy Bez Z Transjenty to pami\u0119\u0107 podr\u0119czna z terminem zapisanym obok warto\u015bci. To zarazem krok, kt\u00f3ry najpewniej niczego nie odzyskuje. Miejsce po usuni\u0119tych wierszach InnoDB wykorzystuje ponownie dla nowych; plik na dysku kurczy si\u0119 tylko wtedy, gdy usuni\u0119to bardzo du\u017co i od tego czasu nic nie zapisano. Raz po du\u017cym porz\u0105dkowaniu, o spokojnej godzinie – warto; trzymanie tego w nocnym cronie – nie warto, a w\u0142a\u015bnie tam polecenie zwykle l\u0105duje.<\/p>\nwp post delete<\/code> nale\u017cy wp post list<\/code>, do wp comment delete<\/code> nale\u017cy wp comment list<\/code>. Uruchomienie listy najpierw z --format=count<\/code> odpowiada na jedyne pytanie, na kt\u00f3re odpowiedzia\u0142by przebieg pr\u00f3bny: o ile wierszy zaraz chodzi.<\/p>\n# 0. kopia zapasowa, poza katalogiem serwowanym przez WWW\nwp db export \/home\/pi\/kopia-$(date +%F).sql\n\n# 1. policzyć, dokładnie tym filtrem, który zaraz zostanie użyty\nwp post list --post_type=revision --format=count\n\n# 2. usunąć, dokładnie tym samym filtrem\nwp post list --post_type=revision --format=ids | xargs -n 100 wp post delete --force<\/code><\/pre>\nxargs<\/code> w ostatnim wierszu nie jest ozdob\u0105. Wstawienie kilku tysi\u0119cy numer\u00f3w wprost do wiersza polece\u0144 wpada w ograniczenie d\u0142ugo\u015bci argument\u00f3w, a b\u0142\u0105d przychodzi, gdy cz\u0119\u015b\u0107 pracy jest ju\u017c zrobiona, zamiast zanim cokolwiek si\u0119 wydarzy – czyli dok\u0142adnie w sytuacji, kt\u00f3rej ca\u0142e post\u0119powanie mia\u0142o unikn\u0105\u0107.<\/p>\nwp db export<\/code> zapisuje zrzut do bie\u017c\u0105cego katalogu, a przy poleceniu WordPressa jest nim zwykle katalog serwowany przez WWW. Pe\u0142ny zrzut bazy o odgadywalnej nazwie, wydawany po HTTP, to wynik gorszy ni\u017c wszystko, co porz\u0105dkowanie mia\u0142o naprawi\u0107.<\/p>\nDwie drogi do usuni\u0119cia tego samego wiersza<\/h2>\n
wp post delete<\/code> wywo\u0142uje t\u0119 sam\u0105 funkcj\u0119 co edytor. Usuwa metadane, komentarze, meta komentarzy i powi\u0105zania termin\u00f3w oraz uruchamia haki, przez kt\u00f3re rozszerzenia mog\u0105 usun\u0105\u0107 to, co za\u0142o\u017cy\u0142y gdzie indziej – wpis w indeksie wyszukiwania, pami\u0119\u0107 podr\u0119czn\u0105, wiersz we w\u0142asnej tabeli.<\/p>\nDELETE FROM wp_posts<\/code> usuwa jeden wiersz. Wszystko, co na niego wskazywa\u0142o, zostaje – nieosi\u0105galne i niewidoczne: \u017cadne zapytanie nie \u0142\u0105czy si\u0119 z wpisem, kt\u00f3rego nie ma, wi\u0119c te wiersze po prostu nigdy si\u0119 ju\u017c nie pojawiaj\u0105. Da si\u0119 z tym \u017cy\u0107, dop\u00f3ki numer nie zostanie przydzielony ponownie – a numery wpis\u00f3w przydziela si\u0119 ponownie po imporcie bazy. Wtedy nowy wpis bezg\u0142o\u015bnie dziedziczy pola w\u0142asne i komentarze starego.<\/p>\nCzego naprawd\u0119 dotyka ka\u017cde polecenie<\/h2>\n
\n\n
\n \nPolecenie<\/th>\n Usuwa<\/th>\n Zostawia<\/th>\n<\/tr>\n<\/thead>\n \n wp post delete <nr> --force<\/code><\/td>\nwpis, metadane, komentarze, terminy<\/td>\n za\u0142\u0105czone pliki i ich wiersze za\u0142\u0105cznik\u00f3w<\/td>\n<\/tr>\n \n wp post delete <za\u0142\u0105cznik> --force<\/code><\/td>\nwiersz i pliki na dysku, wszystkie rozmiary<\/td>\n odwo\u0142ania do adresu w innych wpisach<\/td>\n<\/tr>\n \n wp post delete <rewizje><\/code><\/td>\nrewizje i ich w\u0142asne wiersze meta<\/td>\n sam wpis, nietkni\u0119ty<\/td>\n<\/tr>\n \n wp comment delete --status=spam<\/code><\/td>\nkomentarze i meta komentarzy<\/td>\n liczniki komentarzy przy wpisach, do przeliczenia<\/td>\n<\/tr>\n \n wp transient delete --expired<\/code><\/td>\ntylko transjenty, kt\u00f3rym min\u0105\u0142 termin<\/td>\n ka\u017cdy transjent zapisany bez terminu<\/td>\n<\/tr>\n \n wp db optimize<\/code><\/td>\nnic<\/td>\n blokad\u0119 tabeli na czas przebudowy<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n wp comment recount<\/code> przywraca zgodno\u015b\u0107 liczb z wierszami. Bez tego nic si\u0119 nie psuje; liczniki s\u0105 po prostu b\u0142\u0119dne, wsz\u0119dzie i bezg\u0142o\u015bnie.<\/p>\nKosz nie jest kopi\u0105 zapasow\u0105<\/h2>\n
--force<\/code> kasowanie przenosi wpis do kosza, a to zmiana statusu i nic wi\u0119cej. Wiersz zostaje, metadane zostaj\u0105, media zostaj\u0105, a miejsce si\u0119 nie zwalnia – kosz opr\u00f3\u017cniany raz w miesi\u0105cu to nawyk porz\u0105dkowy, a nie siatka bezpiecze\u0144stwa.<\/p>\n--force<\/code> wpis pomija kosz ca\u0142kowicie i wewn\u0105trz WordPressa nie ma \u017cadnego powrotu. Mi\u0119dzy pomylonym filtrem a straconym miesi\u0105cem stoi wy\u0142\u0105cznie zrzut z kroku zerowego – i dlatego jest to krok zerowy.<\/p>\nPrzeterminowane to nie to samo co wszystkie<\/h2>\n
wp transient delete --expired<\/code> usuwa te, kt\u00f3rym czas min\u0105\u0142, i z za\u0142o\u017cenia jest bezpieczne: co usuwa, i tak by\u0142o ju\u017c niewa\u017cne.<\/p>\n--all<\/code> to inne polecenie w tym samym przebraniu. Usuwa r\u00f3wnie\u017c transjenty bez terminu, a niekt\u00f3re rozszerzenia u\u017cywaj\u0105 w\u0142a\u015bnie ich jako jedynego miejsca przechowywania czego\u015b, czego wyliczenie by\u0142o drogie – sprawdzenia licencji, stanu magazynu, gotowego menu. Widocznie nic si\u0119 nie psuje; witryna sp\u0119dza tylko nast\u0119pn\u0105 godzin\u0119 na odbudowywaniu rzeczy, o kt\u00f3re nikt jej nie prosi\u0142, a jedno czy dwa rozszerzenia zachowuj\u0105 si\u0119, jakby dopiero co je zainstalowano.<\/p>\nOptymalizacja to przebudowa, a nie sprz\u0105tanie<\/h2>\n
wp db optimize<\/code> wykonuje OPTIMIZE TABLE<\/code>, a przy InnoDB nie jest to optymalizacja, tylko pe\u0142na przebudowa tabeli wraz z indeksami. Na ten czas tabela jest zablokowana do zapisu, co przy ma\u0142ym blogu trwa sekund\u0119, a przy du\u017cej wp_postmeta<\/code> dostatecznie d\u0142ugo, by odwiedzaj\u0105cy to zauwa\u017cyli.<\/p>\n