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

O tym jak odchudzić bazę, czyli usunąć kopie/rewizje/revisions wpisów WordPress bazując na własnym zapytaniu SQL – część II
W poprzednich wpisach dotyczącym czyszczenia wordpress z wpisów typu revision przedstawiłam jak działa WordPress oraz co można znaleźć w sieci o usuwaniu zbędnych wersji wpisów wordpress i dlaczego to, co można znaleźć jest nie do końca dobre. W dalszej części wpisu pokażę Wam co zrobić, żeby napisać je lepiej a na pewno bardziej optymalnie.

Przed lekturą tego artykułu bardzo proszę o zapoznanie się z wymienionymi wyżej wpisami. W bieżącym będę często podawać je jako źródło dodatkowych informacji

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

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

Banery reklamowe użyte w artykule odsyłają do wybranych ofert kont osobistych, kont oszczędnościowych lub lokat – szczegółowe informacje na stronie oferty.

Jak wyszukać wersje wpisów?

Na początku wykonaj zapytanie:

SELECT * FROM wp_posts WHERE post_type='revision'

obejrzyj zwracane dane, które mamy zamiar wyczyścić i pomyśl, czy na pewno chcesz je usunąć.

Co będziemy usuwać z bazy danych?

Zanim zdecydujesz się na usunięcie powyższych danych, przyjrzyj się proszę przykładowi, na postawie którego pokażę Ci co tak naprawdę będziemy usuwać z bazy danych (są to rzeczywiste dane pobrane z mojej bazy) oraz jak w prosty sposób zrobić kopię danych, które zamierzasz usunąć

Jest sobie w bazie danych ten właśnie wpis, w chwili wykonywania zrzutu ekranu jest to szkic (ID=759) wykonując poniższe zapytanie znajduję informacje:

SELECT ID, post_title, post_type, post_status, post_name, post_parent
FROM wp_posts
WHERE id = 759 or post_parent = 759

wordpress revision czyli jak odchudzić bazę danych cz. 2

Zapytanie zwróciło wpis o ID=759 oraz wpisy z nim powiązane (post_parent = 759). O wpisach typu attachment/inherit wspominałam poprzednio. W bieżącym interesują nas tylko post_type = revision.
Powyżej prezentowałam dane w oparciu o szkic, poniżej rzeczywisty wpis 100 zł w programie poleceń od Inteligo – możesz go oczywiście obejrzeć w blogu. Po wykonaniu poniższego zapytania MySQL zwrócił mi:

SELECT ID, post_title, post_type, post_status, post_name, post_parent
FROM wp_posts
WHERE id = 896 or post_parent = 896

select post_type=revision and post_name autosave or revision

Jeżeli chcesz w swojej bazie wyszukać analogiczne dane (zakładając, że masz włączony autosave i revision), wybierz w miarę „świeży” wpis, weź jego ID i użyj zapytania SQL, które podałam powyżej.

Jak pewnie zauważyłaś/-eś jest tu jeden rekord z rodzaju „autosave” (ID=1099, post_name = 896-autosave-v1) – przypominam, że są to dane automatycznie zapisywane przez WordPress oraz dwa rekordy rodzaju „revision” (ID=926 i 974, post_name = 896-revision-v1) – wersje, które powstają między innymi po naciśnięciu przycisku „Zapisz szkic”. Szczegółowo opisałam to we wpisach wymienionych na początku tego artykułu – zapoznaj się proszę też z nimi.

Dążymy do tego, żeby w procesie odchudzania bazy danych usunąć z niej wpisy post_type = revision, przy czym mogą to być wszystkie dane tego typu albo tylko „autosave” lub tylko „revision”.

Tak możesz wykonać kopię usuwanych danych

Podejrzewam, że Twój dostawca wykonuje backup danych. Ale najlepiej zawsze liczyć na siebie

Na początku utwórz tabelę _revs, która będzie miała strukturę dokładnie taką samą jak wp_posts, ale nie będzie zawierała żadnych danych (warunek where 1=2). Użyj do tego takiego zapytania:

create table wp_posts_revs as select * from wp_posts where 1=2

Jeżeli masz już tabelę o takiej nazwie, to po prostu nadaj inny surfix i użyj go też dalej. Po wykonaniu SQL w Twojej bazie danych powinna powstać tabela wp_posts_revs nie zawierająca żadnych danych – sprawdź to. Do tej tabeli będziemy kopiować dane, które zamierzamy usunąć z tabeli „produkcyjnej”.

W analogiczny sposób możesz oczywiście wykonać kopię tabeli wp_posts razem z danymi:

create table wp_posts_bkp as select * from wp_posts

Przyjęłam sobie, że z będę usuwać rewizje wpisów starsze niż 1 dzień, a co za tym idzie do tabeli wp_posts_revs załadujemy wszystkie wpisy typu revision (opcja 1) używając zapytania z warunkiem 1 dzień:

INSERT INTO wp_posts_revs
SELECT * FROM wp_posts
WHERE post_type='revision'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Note: CURDATE() zwraca datę bez części godzinowej np. 2015-12-26, czyli przykładowy warunek

post_modified <= '2015-12-26'

wstawi do tabeli _revs tylko wpisy do 2015-12-26 00:00:00 i starsze. Rekordy zmodyfikowany 2015-12-26 00:00:01 zostanie wstawiony w następnym dniu.
Po wykonaniu SQL sprawdź zawartość tabeli wp_posts_revs – jeżeli tabela zawiera dane, to oznacza, że wszystko to, o czym napisałam powyżej, zostało wykonane przez Ciebie poprawnie, brawo
Note: dygresja – słowo wyjaśnienia nt gwiazdki w zapytaniu SQL. Jeżeli pracujesz z bazami danych czy kodujesz programy korzystające z DB, to pewnie wiesz, że należy unikać zapytań z *. Ładniej i bezpieczniej jest, jeżeli w zapytaniu jawnie wymienisz wszystkie użyte kolumny (opcja 2):

INSERT INTO wp_posts_revs
 (ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_content_filtered, post_parent, guid, menu_order, post_type, post_mime_type, comment_count)
 SELECT ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged, post_modified, post_modified_gmt, post_content_filtered, post_parent, guid, menu_order, post_type, post_mime_type, comment_count
 FROM wp_posts
 WHERE post_type='revision'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Opcja 1 – zapytanie zadziała poprawnie, jeżeli tabele wp_posts i wp_posts_revs będą miały dokładnie taką samą budowę. Jeżeli utworzysz tabelę _revs i nie będziesz modyfikować struktury, to możesz śmiało korzystać z tego rozwiązania. Jeżeli do wp_posts dodasz kolumnę, to musisz pamiętać, żeby dodać ją też do wp_posts_revs.
Opcja 2 – zapytanie zadziała w każdym przypadku, o ile tylko kolumny wymienione w zapytaniu będą istniały w tabelach.

No dobrze, mamy kopię danych (tak na wszelki wypadek), możemy usunąć niepotrzebne wpisy z tabeli wp_posts.

Note: Nie musisz przejmować się rozmiarem tabeli wp_posts_revs. Tabela ta nie będzie w żaden sposób wykorzystywana przez silnik WordPress, więc jej rozmiar nie ma znaczenia. Możesz wrzucać do niej wszystkie wersje wpisów i autosave, bez obawy o wydajność Twojego bloga.

Usuwamy wpisy typu revision z wp_posts

Uwaga!! Począwszy od tego miejsca będziesz modyfikować tabelę, na której oparty jest Twój blog. Osobiście mam duże doświadczenie w pracy z bazami danych i nie obawiam się o ewentualnej utraty czy uszkodzenia danych. Jeśli jednak nie czujesz się w zbyt dobrze w tym temacie, to nie eksperymentuj albo poproś do pomocy kogoś bardziej doświadczonego!
A jeśli już zdecydujesz się na eksperymenty, to koniecznie wykonaj kopię bazy danych / wybranych tabel!

Uprzedzam też, że nie biorę odpowiedzialności za ew. straty w Twoich bazach danych.

Żeby nie było, że nie ostrzegałam.

„SELECT *” z zapytania wymienionego na początku zamieniasz na „DELETE ” i już prawie masz gotowca do czyszczenia bazy danych z revision (dopisałam tylko warunek na datę):

DELETE FROM wp_posts
WHERE post_type='revision'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Jeżeli chcesz usunąć tylko „revision” ale pozostawić „autosave”, to napisz:

DELETE FROM wp_posts
WHERE post_type='revision' and post_name like '%revision%'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Jeśli chcesz zostawić „revision” a usunąć tylko „autosave”, to użyj zapytania:

DELETE FROM wp_posts
WHERE post_type='revision' and post_name like '%autosave%'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Jeszcze raz lojalnie uprzedzam, zanim rozpoczniesz modyfikację danych upewnij się, że wiesz co robisz i koniecznie zrób kopię bazy danych.

Powtórzenie operacji za N dni

Zakładam, że za jakiś czas będziesz chcieć powtórzyć operację czyszczenia revisions. Wystarczy więc, że wykonasz:

INSERT INTO wp_posts_revs
SELECT * FROM wp_posts
WHERE post_type='revision'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY);

DELETE FROM wp_posts WHERE post_type='revision'
AND post_modified <= DATE_ADD(CURDATE(), INTERVAL -1 DAY);

Pamiętaj o ewentualnej kopii danych Twojej bazy danych, zapoznaj się też z tym, o czym pisałam powyżej.

Podsumowanie

Tyle zachodu, żeby dojść do prostego:

DELETE FROM wp_posts WHERE post_type='revision' + warunek na datę

Wiem, wiem, trochę chyba mnie poniosło

W naszej bazie danych przed i po usunięciu rewizji wpisów było odpowiednio:

Mam nadzieję, że wszystko jest w miarę jasne. Jeśli masz jakieś pytania lub uwagi, to wpisz je w komentarzu do tego lub poprzednich postów.

ps) przepraszam, za długi czas zwłoki od wpisu cz. 1. Mikołaj przyjechał z Rózgowic, przywiózł mi rózgę, więc wzięłam się za uzupełnienie dokończenie wpisu o WordPress revision. Rózgowice – miejscowość fikcyjna