Már sokadszor futottam bele egy olyan hibába WordPress alatt, amelynek nem annyira triviális a megoldása és sokan nem tudnak róla, sőt sokszor észre sem veszik. A WordPress-ben többféle beépített bejegyzés típus, azaz post_type van. Ami a mostani cikket érinti, az a változat, vagy más néven revision. Ez arra jó, ha szerkesztünk egy oldalt (page), vagy bejegyzést (post), – illetve egy olyan egyedi bejegyzés típus, ahol engedélyezve van a revision -, ott a módosítás pillanatában készül róla egy mentés, ahova bármikor „visszatérhetünk”, azaz visszaállíthatjuk az adott, mentett állapotot. A WordPress ilyenkor a post_content-t, azaz a tartalom részt menti el a revision-be másolatként, az egyéb beállításat (formátum, kategória, stb.) nem. Jól tud jönni, ha valamit elrontunk, vagy törlés után véletlenül felülírunk, így vissza tudjuk állítani. A WordPress beépített bejegyzés típusai:
- publish: közzétett, „végleges” mindenki által látható, publikus bejegyzés
- future: véglegesre szánt változat, de csak a jövőben megjelenő bejegyzés
- draft: vázlat, szerkesztés alatt álló bejegyzés, csak megfelelő jogosultsággal bejelentkezett felhasználók látják
- pending: függőben lévő állapotú bejegyzés
- private: csak adminisztrátorú jogosultságú felhasználók bejelentkezve látják
- trash: lomtárban lévő törölt bejegyzés
- auto-draft: automatikusan mentett változat, melyet a WordPress megadott időközönként ment el az adatbázisban, ha mi nem tesszük meg
- revision: ha egy bármilyen vázlatot újra elmentünk, vagy egy közzétett bejegyzést frissítünk, akkor keletkezik belőle egy változat, ún revision
Természetesen lehetséges egyedi bejegyzés státuszt definiálni, mint ahogy pl. a WooCommerce is teszi ezt, a megrendelésekhez tartozó wc-pending, wc-processing, wc-on-hold, wc-completed, wc-cancelled, wc-refunded, wc-failed típus definíciókkal.
A revision-ök száma alapértelmezett nincs korlátozva, így ha gyakran mentünk egy oldalt, vagy bejegyzést, úgy korlátlan számú változat keletkezik belőle. Képzeljük el, hogy ha egy főoldalt gyakran változtatunk (vagy épp egy új weboldalt készítünk az ügyféllel folyamatosan egyeztetve, bővítve, módosítva), akkor hány darab revision jön belőle létre? Több száz, vagy akár több ezer is. Ezek a revision-ök a `wp_posts` táblában vannak tárolva és szépen fokozatosan hízlalják az adatbázist, ami egy nagyobb oldalnál akár több száz Mbyte méretű is lehet. A MySQL adatbázisok úgy épülnek föl, hogy egy adatbázis sor (ez esetben a wp_posts táblában) után automatikusan létrejön egy új sor, ahová a revision létrejön. Ezeket a sorokat az SQL indexeli (sorszámozza), és amikor a WordPress lekérdezi egy adott oldal tartalmát, az mindig a legutolsó sorban van, tehát a többezer vagy akár sor végefelé. Ez egy nagyméretű adatbázisban sokszor másodpercekbe is kerülhet, ami egy weboldal böngészése, vagy szerkesztése közben érezhető lassulást okozhat. Miközben ezt a cikket írom, látható alul, hogy hány revision jött létre:
A WordPress SQL adatbázis táblájában ez a valóságban így néz ki:
Az Elementor egy ún. page builder eszköz, azaz meglévő elemekből drag n drop módszerrel tudunk tartalmat felépíteni. Az ehhez hasonló page builder eszközök megnyitották az utat a weboldal készítéshez az olyan embereknek is, akik nem értenek a HTML leíró nyelvhez (amiből egy weboldal áll) és JavaScript-hez sem. A legnépszerűbb page builder eszközök WordPress alá:
- Elementor
- WP Bakery Page Builder
- Divi Builder
- Beaver Builder
Én is használok Page Buildert, mert gyorsan el tud készülni vele egyszerűbb weboldal, vagy landing oldal. Az AI megjelenésével és a Page builderek elterjedésével sajnos megjelentek az olyan „fejlesztők” is, akik összekattintgatják a weboldalt egy ilyen page builderrel és nem ismerik a HTML nyelvet, a CSS-t, a JavaScript-et. Sőt egyáltalán nem tudják, hogy mi van a WordPress motorja mögött és hogyan vannak ezek az adatok struktúrálva és tárolva. Az Elementor eleve az amatőr felhasználókra céloz, akik gyorsan, látványos oldalt akarnak létrehozni és sokszor futnak hozzám olyan problémával az oldal tulajdonosai, vagy üzemeltetői, hogy a weboldaluk lelassult, a szerkesztés közben is érezhetően várakozni kell, míg elmentenek, létrehoznak egy bejegyzést vagy oldalt.
Az Elementor nem teljesen úgy hozza létre és tárolja a revision-öket, mint ahogyan a WordPress szabványa megkövetelné. Az Elementor az adatok nagy részét ugyanis a postmeta táblába hozza létre, ami a WordPress adatbázis legkritikusabb része, mivel ez a legnagyobb méretű, hiszen itt van a legtöbb sor egymás után. Ráadásul míg egy tartalom Elementor alatt elkészül, az sokszor lesz elmentve, így az adatbázis csak hízik és egyre lassabb lesz annak indexelése.
Ezért ha lassú egy Elementor alapú oldal, először mindig megnézem, hogy mekkora a wp_posts és a wp_postmeta tábla mérete. Ha nagy, akkor gyaníthatóan ez a gond. Ilyenkor ezeket a lépéseket szoktam végrehajtani
- Törölni az összes revision típusú bejegyzést az adatbázisból
- Törölni az revision bejegyzésekhez tartozó postmeta sorokat is az adatbázisból
- Maximalizálni és beállítani egy kezelhető revision számot, pl. 25-öt
- Optimalizálni a wp_posts és wp_postmeta táblákat
Először megnézhetjük, hogy hány revision (Változat) van az adatbázisban. Itt nyilván a „wp_” prefixet cserélni kell az aktuális adatbázis prefixre, én most az alapértelmezett „wp_” prefixet használom az alábbi lekérdezésekhez.
SELECT COUNT(*) AS revision_count
FROM wp_posts
WHERE post_type = 'revision';Erre valami hasonló választ kapunk:
Ha itt valami hasonlóan nagy szám van, akkor sejthető, hogy ezzel van a gond. Jöhet a törlés:
DELETE FROM wp_posts
WHERE post_type = 'revision'
AND ID NOT IN (
SELECT ID FROM (
SELECT ID
FROM wp_posts
WHERE post_type = 'revision'
ORDER BY post_date DESC
LIMIT 25
) AS keep_latest
);Ebben a példában több, mint 12.000 revision volt az adatbázisban:
Majd az ottmaradt felesleges postmeta sorok törlése is:
DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;Látszik, hogy nem kevés sor törlődött ezáltal:
Ha ez is kész, akkor szerkesszük vagy tegyük be a következő sort a wp-config.php fájlba.
define( 'WP_POST_REVISIONS', 25 );Ezzel jelentősen csökkenthetjük a WordPress adatbázis méretét és ezáltal a szerver terhelését is.
Az előbbi példában így nézett ki a két tábla mérete a törlés előtt:
Ez pedig utána:
Majdnem 400 MB-ot nyertünk ezzel, ami a fenti példaoldalnál majdnem a felére csökkentette az adatbázist, ezáltal a sebességnövekedés is érezhető volt:
Mindenkinek gyors és eredményes weboldal fejlesztést!
