Mint ahogy a legtöbb modern dinamikus weboldal, úgy a WordPress is adatbázisban tárolja az összes beállítást, tartalmat és minden általunk hozzáadott anyagot. A legtöbbek számára közismert, hogy itt a MySQL adatbázisról beszélünk, bár egyes esetekben az adatbázis szoftver MariaDB is lehet. Szerencsére a kettő rendszer teljesen kompatibilis egymással (és a WordPress-el is). A MariaDB a MySQL úgynevezett “fork”-ja, azaz a MySQL-ből fejlődött ki, de már teljesen saját úton jár. Előnye a jobb teljesítmény, a több funkció és az aktívabb fejlesztői közösség. Természetesen számunkra bármelyik opció tökéletesen megfelel, legtöbbször úgy is a tárhely szolgáltató dönti el, hogy melyik alternatívát telepíti a szerverre. Saját VPS vagy dedikált szerver esetén érdemes azonban a MariaDB-t installálni.
Az alapok
Alap kérdés ugyan, de sokszor felmerül, hogy elég-e FTP-n keresztül a tárhelyünkről lementeni az összes fájlt ahhoz, hogy a weboldalunkat biztonságban tudhassuk és bármikor visszaállíthassuk adatvesztés vagy egyéb probléma esetén. Nos erre a válasz a NEM! Az adatbázisról történő biztonsági mentés nélkül csak félmunkát végeztünk, ugyanis az összes bejegyzésünk, oldalunk, beállításunk és minden tartalmunk a MySQL adatbázis tábláiban található amely fizikálisan egy teljesen eltérő helyen tartózkodik a szerveren, nem található meg a weboldalunk fájlrendszerében. A fájlrendszer mentésével mindössze csak annyit érünk el, hogy meg lesznek a bővítményeink, sablonjaink és a médiatárba feltöltött képeink/anyagaink. Minden egyéb, amit a vezérlőpulton keresztül hoztunk létre az adatbázisban van, tehát a teljes biztonsági mentéshez elengedhetetlen a fájlrendszer ÉS az adatbázis mentése. Erre a folyamatra léteznek már nagyon jó bővítmények, amelyek elvégzik helyettünk a munka nehezét. Itt az oldalon is írtam már részletes cikket például a BackWpUp bővítményről, érdemes ezt használni a teljes biztonsági mentéseink létrehozására.
Gyakori kérdés még, hogy mekkora adatbázis szükséges a WordPress mellé, erre viszont már nehezebb válaszolni. Egy alap blog oldal, amely mindössze havi pár darab személyes bejegyzést fog tartalmazni, legtöbbször beéri 10-50 megabyte adatbázis területtel is, azonban egy WooCommerce webshop több ezer termékkel (és ezek variációjával), valamint jó néhány egyéb bővítménnyel már könnyen elfoglalhat több száz megabyte adatbázisterületet is. Szerencsére manapság már egyre ritkábbak az olyan tárhely szolgáltatók, ahol korlátozzák a MySQL adatbázis méretét, de ha mégis ez lenne a helyzet, akkor természetesen érdemesebb minél nagyobb adatbázis csomagot választani (persze mérlegelve, hogy az oldal milyen célra is készül és hogy várhatóan mekkora is lesz az adatbázis felhasználtsága). Sajnos a telepített pluginek többsége is elég sok szemetet hagy maga után (még eltávolítás után is), ezért is érdemes törekedni az elérhető minél nagyobb MySQL méretre.
Szintén visszatérő kérdés, hogy hogyan is hajthatók végre kézi műveletek az adatbázisban (például egy adminisztrátor felhasználó hozzáadása vagy meglévő felhasználó jelszavának kézi megváltoztatása), hol és miként lehet ezt elérni és hogyan tudjuk manuálisan böngészni az adatbázis táblák tartalmát. Ezen műveletekre szinte minden szolgáltató biztosít felületet és alkalmazást, nekünk pedig a PHPMyAdmin nevű szekciót kell keresni. cPanel, Plesk, ISPConfig és szinte az összes népszerű tárhely kezelő felület menüpontjai között alapértelmezetten megtalálhatjuk, de az egyéni fejlesztésű panelek 99 százalékában is ott lesz ez a kis adatbázis menedzselő webes felület. A használata természetesen igényel némi szakértelmet és mivel könnyen kárt és adatvesztést is okozhatunk, ezért csak olyan felhasználóknak ajánlom a használatát, akik tisztában vannak azzal, hogy mit is csinálnak. Bárminemű adatbázis módosítás előtt kötelező a biztonsági mentés!
Felépítés
A WordPress alapértelmezetten 11 táblát hoz létre és használ az adatbázisban, bővítmények telepítésével ez a szám természetesen nőni fog, de nézzük most végig, hogy melyek is ezek az alap táblák és mi is a főbb szerepük.
wp_commentmeta: A hozzászólásokkal kapcsolatos metaadatokat tárolja
wp_comments: Ebben a táblában foglalnak helyet maguk a hozzászólások
wp_links: A blogroll linkeket tárolja, ez a funkció már nem támogatott
wp_options: Itt tárolódnak az oldalunkkal és a bővítményekkel kapcsolatos beállítások
wp_postmeta: A tartalmakkal kapcsolatos meta információkat tárolja
wp_posts: Itt vannak maguk a bejegyzések, az oldalak és minden további egyedi bejegyzés típus is
wp_terms: A kulcsszavak és kategóriák helye
wp_terms_relationships: A kapcsolati információkat tárolja a bejegyzések, kategóriák és kulcsszavak között valamint a linkek és a link kategóriák között
wp_term_taxonomy: A kategóriák, linkek és kulcsszavak leírásait tárolja
wp_usermeta: A felhasználókkal kapcsolatos meta adatokat tárolja
wp_users: Ebben a táblában vannak maguk a felhasználók
További információ a táblákról: https://codex.wordpress.org/Database_Description
Lehetséges problémák
Amivel szinte minden WordPress felhasználó találkozott élete során az a következő hibaüzenet.
Jelentése mindössze annyi, hogy a WordPress képtelen kapcsolatot létesíteni az adatbázis szerverrel, ezáltal természetesen az oldalunk sem fog addig betöltődni amíg a fenti probléma meg nem oldódik. Ilyenkor jobb esetben csak karbantartás van a tárhelyünk szerverén és ezért ideiglenesen nem érhető el az adatbázis szerver (frissítik, éppen újraindul, stb.), ilyenkor csak várnunk kell és általában néhány percen belül meg is oldódik a gond és egy újratöltés után már a jól ismert weboldalunk köszön vissza. Azonban ha ez nem így történne és egy általunk végzett módosítás után jelent meg a hibaüzenet, akkor szinte biztosak lehetünk benne, hogy mi okoztuk a bajt. A probléma megoldásának első lépése mindig a wp-config.php fájl ellenőrzése legyen. Ha ebben végeztünk kézi változtatásokat, akkor nagy valószínűséggel sikerült módosítani az adatbázis kapcsolat paramétereit is, de nem ritka, hogy egy bővítmény hibás beállítása okozza a problémát. Első lépésként ellenőrizzük az adatbázis szerver nevét (ez az esetek túlnyomó többségében localhost kell, hogy legyen), majd az adatbázis felhasználóját, jelszavát és nevét. Ha ezeket nem ismerjük, akkor a tárhelyünk webes felületén tudjuk őket kikeresni (természetesen a szolgáltató is segíthet) és ha szükséges akkor az adatbázis felhasználó jelszavát is megváltoztathatjuk és a frissen generált jelszót adjuk meg a wp-config.php-ben a régi helyett.
A szekció, amit a wp-config.php-ben keresünk a következő:
// ** MySQL beállítások - Ezeket a szolgálatótól lehet beszerezni ** // /** Adatbázis neve */ define('DB_NAME', 'adatbázis_neve'); /** MySQL felhasználónév */ define('DB_USER', 'felhasználónév'); /** MySQL jelszó. */ define('DB_PASSWORD', 'jelszó'); /** MySQL kiszolgáló neve */ define('DB_HOST', 'localhost'); /** Az adatbázis karakter kódolása */ define('DB_CHARSET', 'utf8'); /** Az adatbázis egybevetése */ define('DB_COLLATE', '');
Az adatbázis kódolásához és az adatbázis egybevetése részhez ne nyúljunk, a többit pedig csak akkor módosítsuk, ha a fenti hibaüzenet megoldásán dolgozunk. Fontos megőrizni a szintaktikát, tehát ne töröljük ki az aposztrófokat egy helyről sem, mert már ezek hiánya is problémát okoz.
Ritkább eset, de nem egyszer találkoztam már olyan oldallal is, ahol egyes adatbázis táblák megsérültek, ilyenkor szintén nem fog üzemelni a weblap egészen addig, amíg ezek a hibák ki nem lesznek javítva. Szerencsére a WordPress lehetőséget ad a beépített javító funkció használatára, de ehhez nekünk is be kell segítenünk pár lépéssel. A dolgunk mindössze annyi, hogy a wp-config.php fájl végére (a define(‘WP_DEBUG’, false); alá) beillesztjük a következő sort:
define('WP_ALLOW_REPAIR', true);
Ezzel engedélyezzük a rendszernek, hogy elvégezze a szükséges javításokat és az optimalizálást.
Ezután már csak meg kell nyitnunk a következő linket: http://www.oldaladcime.hu/wp-admin/maint/repair.php
A következő kép fog minket fogadni:
Nyugodtan nyomjunk meg az alsó, javítás/optimalizálás gombot és reménykedjünk, hogy a rendszer képes lesz kijavítani a hibákat. Ugyanez a művelet egyébként elérhető és elvégezhető PHPMyAdminon keresztül is az egész adatbázisra vonatkozóan, tehát ha az szimpatikusabb, akkor kezdhetjük ezzel is (először az adatbázis/táblák kiválasztása, majd a lenyílóból a javítás és/vagy optimalizálás kiválasztása).
Karbantartás
A MySQL adatbázis maga nem igényel túl sok karbantartást, akkor is működik, ha hozzá sem nyúlunk, azonban érdemes alkalmanként kitakarítani belőle a szemetet. Ezzel egyrészt csökkenthetünk a méretén, másrészt gyorsíthatunk is a weboldalunkon, ha kigyomláljuk belőle a felesleget. Ehhez létezik egy nagyon sokoldalú és bevált eszköz, a WP-Optimize nevű bővítmény. Segítségével eltávolíthatjuk a kéretlen és általunk nem jóváhagyott hozzászólásokat, a kukába helyezett tartalmakat, a lejárt tranzienseket és minden olyan hátrahagyott maradék tartalmat, amire a rendszerünknek már nincs szüksége és amik csak a helyet foglalják. Ezeken felül képes még egyetlen kattintással optimalizálni és töredezettségmentesíteni a teljes adatbázist, ami szintén igen hasznos funkció. Természetesen mindezt automatán is elvégzi egy általunk beállított időintervallumban (például heti egyszer), amit érdemes is rögtön konfigurálni.
Ami a leginkább képes megnövelni az adatbázis méretét az a WordPress automatikus revízió, azaz változat mentése. Ha készítünk egy bejegyzést, majd 5 alkalommal módosítunk rajta, akkor a rendszer ötször tárolja ezt el az adatbázisban, hogy ha szükséges, akkor minden módosításunkat vissza tudjuk vonni. Ez kétségkívül nagyon hasznos funkció, sokakat sokszor húzott már ki a csávából, azonban felesleges egy bejegyzésből 100 variációt tartani, ezért érdemes azt is korlátozni, hogy mennyi legyen a maximálisan megtartható változatok száma. A WP-Optimize ebben is tud segíteni, például beállíthatjuk, hogy csak az utolsó 2 hét adatait tartsa meg, a többit pedig törölje.
Ha ennél mélyebben szeretnénk belenyúlni a revíziók kezelésébe, akkor manuálisan is kontroll alá vonhatjuk a változatok számát, ehhez a következő sort kell a wp-config.php végéhez adnunk (szintén a define(‘WP_DEBUG’, false); alá):
define( 'WP_POST_REVISIONS', 3 );
Értelemszerűen a hármas szám helyére kerüljön az az érték, amennyi változatot szeretnénk egyszerre megtartani.
WooCommerce
Nemrégiben volt dolgom egy oldallal, ahol az adatbázis mérete elérte a tárhelyhez kiszabott 100MB-os limitet, ezért korlátozás alá került az egész honlap. A WordPress mellett csak a WooCommerce futott néhány egyéb bővítménnyel és pár száz darab termékkel. Természetesen ezeknek nem szabadna ekkora foglalást generálni, úgyhogy mélyebben is belenéztem az adatbázis tábláiba. Ami rögtön feltűnt az az, hogy a wp_options tábla abnormálisan nagy méretű, ezt pedig a _wc_session_xxx és a _wc_session_expires_xxx rekordok okozták.
Ebben az esetben a megoldás a következő MySQL lekérés futtatása volt PHPMyAdminen keresztül:
DELETE FROM wp_options WHERE option_name LIKE '_wc_session_%' OR option_name LIKE '_wc_session_expires_%'
Ugyanezt a műveletet már a WooCommerce is képes elvégezni a legújabb verzióiban, bár ez nem minden esetben tud teljesen lefutni a PHP korlátozásai miatt (időtúllépés), ezért érdemesebb PHPMyAdminon keresztül dolgozni.
Ha hasonló esettel találjuk szembe magunkat, akkor érdemes ellenőrizni, hogy nincs-e kikapcsolva a WordPress cron funkció, ugyanis a megléte nélkül nem fognak lefutni az automatikus karbantartó funkciók és nem kerülnek törlése az adatbázisból a fölösleges rekordok sem. A wp-config.php NE tartalmazza a következő sort (ugyanis ezzel kapcsoljuk ki a WordPress beépített feladatütemezőjét): define(‘DISABLE_WP_CRON’, ‘true’);
Konklúzió
Érdemes odafigyelnünk az adatbázisunk méretére, mindig töröljük a szükségtelen és kéretlen hozzászólásokat, korlátozzuk a revíziók/változatok maximális számát és időnként optimalizáljuk az adatbázisunkat akár PHPMyAdmin, akár a WP-Optimize bővítmény segítségével. Ha szeretnénk csökkenteni a MySQL lekérések számát, ezzel egy időben pedig levenni a terhet az adatbázis szerverről és gyorsítani a weboldalunk betöltési idején, akkor érdemes valamilyen gyorsítótárazást is aktiválni, erre az egyik legjobb módszer a W3Total Cache bővítmény, amelynek beállításáról már részletesebben is írtam korábban.