WordPress revision – jak działa wersjonowanie w WordPress?

O revision w blogu, czyli wersjonowanie wpisów, czyli jak działa WordPress, gdy tworzysz nowy wpis.

Postanowiłam zająć się odchudzaniem bazy danych z wpisów typu revision, ale najpierw chciałam przyjrzeć się temu jak działa WordPress. W dalszej części prezentuję moje obserwacje.

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 (zmienna $table_prefix) – użyj właściwego dla Twojej instalacji.

Pomagam mężowi prowadzić blog, zajmuję się w głównej mierze stroną techniczną, jestem też współautorką jednego z wpisów (o tym później).

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. Postanowiłam się im przyjrzeć.

(ps we wpisie umieszczono banery do ofert lokat, kont osobistych czy kont oszczędnościowych – zaprasza do odwiedzenia strony, szczegółowe informacje na wskazanych stronach)

Jak działa WordPress?

Na początku o tym jak działa wordpress – wszystko sprawdzone organoleptycznie, czyli dodanie nowego wpisu i obserwacja co się dzieje. Krok pierwszy draft/szkic:

Gdy rozpoczynasz pisać nowego posta, tak jak ja pisząc ten, podajesz tytuł artykułu i przechodzisz do części poświęconej głównemu tekstowi. Nie wiem, czy zwróciłaś/zwróciłeś na to uwagę, ale gdy wyjdziesz z pola z tytułem strony, WordPress z automatu utworzy link do nowego wpisu.

Co wówczas wydarzy się w bazie danych? WordPress bez Twojej ingerencji doda ten wpis jako szkic, tak jak w przykładzie poniżej:

wordpress autosave po utworzeniu tytułu wpisu

Zaczynasz pisać tekst wpisu. Czy coś się dzieje w bazie danych? Ależ oczywiście. Tworzą się autozapisy tego, co piszesz, posty o statusie draft/szkic, z widoczną datą posta:

wordpress draft autosave

Przy pisaniu artykułu, ale jeszcze przed wciśnięcie przycisku Zapisz szkic albo Publikuj, wszystko to, co napisałam, z automatu zapisuje się w bazie danych. WordPress ma taki swój autosave.

Możesz się o tym łatwo przekonać, na belce widać stan, np.: Szkic został zapisany 21:40:33 (podobne operacje wykonywane są co kilka minut). Wpis ten (autosave), rekord w bazie danych o statusie draft (szkic).

Jeśli zwróciłaś/zwróciłeś uwagę, że to ten sam czas, jaki widnieje przy rekordzie o ID=682, to brawo dla Ciebie za spostrzegawczość
Być może też zastanawiasz się czym jest rekord o ID=683? To info o załączniku (status=inherit), w tym przypadku o pierwszym z obrazków dołączony do tego posta.

Dobrze. W zasadzie do tego momentu nie musisz się niczym przejmować. W bazie danych nie ma zbędnych danych, które wymagałyby usunięcia.

Zapisz szkic

Klikam „Zapisz szkic” i patrzę co dzieje się w bazie danych. Czyli piszę, piszę i dochodzę w końcu do wniosku, że trzeba to zapisać (save), czyli wykonać własny szkic tego, co utworzyłam.
Stan przed zapisem prezentuje poniższy obrazek (przypominam, że post_status=inherit to dodawane przeze mnie załączniki):

wordpress stan przed Zapisz szkic

Klikam w końcu Zapisz szkic, stan w bazie bezpośrednio po zapisie szkicu:

wordpress bezpośrednio po Zapisz szkic

Jakie można wyciągnąć wnioski po porównaniu dwóch powyższych obrazków? Na pewno został dodany nowy rekord o ID=686 o statusie revision, czyli od tego momentu WordPress rozpoczyna wersjonowanie wykonywanych przez Ciebie modyfikacji artykułu. Od teraz wystarczy, że dodasz czy usuniesz kropkę w tekście (czytaj zmienisz cokolwiek), naciśniesz Zapisz szkic i w bazie zostaje zapisana kolejna wersja tworzonego przez Ciebie dokumentu, do których możesz wrócić, jeśli zajdzie taka potrzeba.

Jeżeli jesteś w tym momencie postu, to brawa dla Ciebie za wytrwałość, mam nadzieję, że zbytnio nie przynudzałam i że opisałam to w miarę przystępnym i nieinformatycznym językiem.

Mamy już w bazie danych niezbędne dane, na podstawie których będziemy mogli przejść do analizy zapytań SQL krążących w internecie, zapytań do usuwania zbędnych wpisów o statusie revision.

Podsumowanie

Po chwili namysłu zdecydowałam się podzielić zagadnienie na dwie, może nawet trzy części.

W tym wpisie przedstawiłam w jaki sposób działa wordpress, gdy tworzysz nowy wpis. W kolejnym (może dwóch) przejdziemy do meritum, czyli pokażę Ci, że zapytania SQL do usuwania revision, które krążą po internecie i o których wspomniałam poprzednio są do bani, a mimo to są bezmyślnie kopiowane i udostępniane na wielu stronach.

BTW: przez kilka minut, w trakcie których dopieszczałam ten wpis, wordpress utworzył 5 kopii wpisów o statusie revision:

wordpress tworzy kolejne revision

Żeby nie było, wiem o opcji WP_POST_REVISIONS. Jednak w domyślnej instalacji WordPress opcja ta jest wyłączona, co sprawia, że nie ma żadnych ograniczeń na liczbę wersji wpisów.

Nie ukrywam, że na potrzeby przygotowania tego artykułu, opcję WP_POST_REVISIONS celowo wyłączyłam.

Ciąg dalszy nastąpi …

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

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.