WordPress revision – czyli jak odchudzić bazę danych cz.1?

O tym jak odchudzić bazę, czyli usunąć kopie/rewizje/revisions wpisów WordPress bazując na własnym zapytaniu SQL – część I

Dlaczego bazując na własnym zapytaniu SQL? Bo te znalezione w sieci są do bani! Ktoś kiedyś napisał jedno, udostępnił je, ale pewnie nie przemyślał wszystkiego, a pozostali bezmyślnie je kopiują i dodatkowo wklejają na swoich stronach.

W dalszej części wpisu pokażę Wam dlaczego tak jest.

Jest to wpis autorski, utworzony na podstawie obserwacji działania WordPress. Uszanuj to. Jeśli chcesz go zacytować, to podaj źródło informacji.

We wpisie używam prefiksu wp_ przypisanego z automatu dla domyślnej instalacji WordPress (zmienna $table_prefix) – użyj właściwego dla Twojej instalacji.

Jak już wspomniałam w poprzednim poście, pomagam mężowi prowadzić blog, zajmuję się w głównej mierze stroną techniczną. Poznając technikalia WordPress, przyszedł w końcu czas na przyjrzenie się temu, co jest w bazie danych. A tam kilka tabel, w tym główna tabela, w której siedzi to, co napiszesz, czyli wp_posts, a w niej mnóstwo wpisów typu revision.

Jeżeli udało Ci się zapoznać z tym jak działa WordPress revision, to będzie Ci łatwiej zrozumieć to, o czym napiszę w dalszej części. ps) wpis zawiera banery reklamowe, szczegółowe inf. na podlinkowanych stronach.

 

Usuwanie WordPress revision

Zobacz co znalazłam w sieci o usuwaniu revision z WordPress? To samo, co możesz i Ty znaleźć. Google -> „wordpress usuwanie revision” -> klikam kilka znalezionych linków i na wielu stronach znajduję to samo zapytanie:

DELETE a,b,c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type='revision';

Super, myślę sobie, pewnie ktoś się natrudził, napisał, przetestował, inni teraz z tego korzystają – słowem szacun. Nic podobnego!

Jeśli wpiszesz w wyszukiwarce „DELETE a,b,c FROM wp_posts a„, to Google zwraca „Około 1 120 wyników (0,30 s)”:

Niestety, są one bezmyślnie kopiowane. Pewnie nikt z kopiarzy nie zadał sobie trudu aby sprawdzić co to zapytanie robi, czy to co wykonuje ma sens, a może jest bezsensowne i nie należy tego powielać, tudzież przed umieszczeniem na swojej stronie warto je poprawić?

 

DELETE a,b,c FROM

Dlaczego DELETE a,b,c FROM wp_posts a … jest nie do końca dobrze napisane? Ale pomimo tego jest namiętnie kopiowane!

W skrócie dlatego, że próbuje usuwać to, czego nie ma i nie ma prawa być w bazie danych. Po prostu Wordpress działa inaczej, niż założył autor zapytania.

Optymistycznie zakładam, że być może silnik WordPress działał inaczej we wcześniejszych wersjach, aczkolwiek to bardzo optymistyczne założenie.

Zapytanie usuwa wpisy z tabel wp_posts, wp_term_relationships, wp_postmeta, przy czym zapytanie zbudowane jest tak, że w dwóch ostatnich tabelach może nie być danych.

No właśnie. Autor zapytania założył, że w wp_term_relationships, wp_postmeta może nie być danych. Tych danych rzeczywiście nie ma, ale tych danych nie może tam być, ponieważ silnik bloga nie wpisuje ich do tych tabel dla wpisów o statusie revision.

Żeby nie być gołosłowną posłużę się danymi z poprzedniego wpisu:

Mamy rekordy o ID = 689, 690, 691, 692, 693. Super! Spróbujmy zatem dla nich wyszukać dane w wp_term_relationships

SELECT * FROM wp_term_relationships WHERE object_id in (689, 690, 691, 692, 693)

Nie wklejam wyniku, bo nie ma co wklejać, gdyż MySQL zwrócił pusty wynik (zero wierszy). Więc ta część zapytania SQL jest bez sensu. Błędne założenie.

Dla dobrze napisanego zapytania SQL w bazie danych nie powinno szukać się tego, czego z góry wiadomo, że tam nie znajdziemy! Szukamy tylko tego, co w niej jest. A w tym przypadku danych nie ma i nie ma i nie ma prawa być, gdyż kolumna object_id z tabeli relationships wskazuje na na tabelę wp_posts, ale nie dla wpisów tymczasowych.

To samo zapytanie, które wskazałam powyżej, ale dla właściwych danych

SELECT * FROM wp_term_relationships WHERE object_id in (682, 683, 684, 685, 687, 688)

już zwraca dane i są to wpisy dla rekordu o statusie draft, ale nie revision:

 

W kolejnej części zapytania SQL jest odwołanie do wp_postmeta, i tak jak poprzednio wykorzystam  ID = 689, 690, 691, 692, 693 (identyfikatory z wp_posts):

SELECT * FROM wp_postmeta WHERE post_id in (689, 690, 691, 692, 693)

I znowu zapytanie nic nie zwraca, bo w wp_postmeta nie ma wpisów dla statusu revision.

 

Łatwo to sprawdzić łącząc obydwie tabele i sprawdzając jakie są w nich statusy wpisów:

SELECT distinct p.post_status FROM wp_posts p, wp_postmeta m where p.ID = m.post_id

Zapytanie zwraca statusy: draft, publish, inherit, trash, auto-draft, ale dziwnym trafem jakoś nigdzie nie widać revision.

Czyli druga część zapytania z początku wpisu też jest bez sensu.

 

Jak to napisać inaczej, bardziej optymalnie?

O tym w kolejnej odsłonie  W tym wpisie to tyle, mam nadzieję, że nie zanudziłam Cię zbytnio i że to, co napisałam jest w miarę zrozumiałe, nie jest zbyt informatyczne.

A tak jak wspomniałam, w kolejnym pokażę Ci co zrobić, żeby napisać to zapytanie bardziej optymalnie, jak zrobić kopię danych itd.

Pamiętaj, że jest to wpis autorski, utworzony na podstawie obserwacji działania WordPress. Uszanuj to. Jeśli chcesz go zacytować, to podaj źródło informacji.

Zapraszam też do zapoznania się z wpisem brakujące dane: entry-title, author, updated, którego jestem współautorką, a który dotyczy błędów strukturalnych oraz do zapoznania się z tym jak działa WordPress – link na początku wpisu.

 

👉 Najlepsze promocje (wybrane):

4% Lokata FACTO (lokata bez konta) ⭐ Facto Opinie i oprocentowanie

Pierwsza pożyczka Vivus za 0 zł – od 100 do 5000 zł od Vivus na 61 dni z RRSO 0%

Vivi raty – logowanie, kontakt i opinie – poznaj ViviRaty (dawniej Zaplo)