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.


Zanim przejdziesz dalej, prosimy: zatrzymaj się na chwilę i polub nasz profil na fb, dziękujemy :)

 

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)”:

DELETE a,b,c FROM wp_posts a

Niestety, są one bezmyślnie kopiowane. Pewnie nikt z kopiaczy 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ć?

 

Dlaczego DELETE a,b,c FROM wp_posts a … jest nie do końca dobrze napisane?

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.

Co (niby) dzieje się w zapytaniu zacytowanym na początku?

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:

wordpress tworzy kolejne revision

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 bazie są rekordy dla draft dla revision brak

 

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.

 

wp_posts i wp_postmeta statusy wpisów

Ł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.

 

 

Poleć lub udostępnij znajomym WordPress revision – czyli jak odchudzić bazę danych cz.1?
i polub bankomaniacy.pl na fb

 

Wybrane najlepsze:

BGŻOptima lokata BEZKARNA

 

Karta kredytowa Citi i voucher Ole Ole

 

mBank - 3,5% Lokata na powitanie

 


Podziel się opinią / komentarzem

Podaj wynik działania: trzy odjąć jeden. Odpowiedź wpisz słownie*  

2 komentarze

  1. mika pisze:

    Będzie, będzie, być może nawet w ten weekend. Inne obowiązki zabierają mi zbyt dużo czasu, ale szkic wpisu już mam napisany.
    A ponieważ w tym artykule będę modyfikować zawartość bazy danych (być może inni czytający ten artykuł także), więc to co napiszę i udostępnię, musi być najpierw dokładnie sprawdzone.

  2. Janunsz Kamiński pisze:

    Dziękuję za ciekawy wpis! Czekam na kolejny odcinek.