Annak ellenére, hogy a WordPress egy ellenőrzött környezet, ahol a hibák sokkal ritkábban fordulnak elő, mint egy tipikus szoftverfejlesztési környezetben, mindig van egy ablak vagy ajtó, amelyen keresztül bemászhatnak a problémák.
Általános szabályként elmondható, hogy minél nagyobb rugalmasságot biztosít egy eszköz, annál több lehetséges hibával találkozhat.
A WordPress esetében nagy a rugalmasság, és ezért rengeteg a lehetséges hiba. Nyílt beépülő modul architektúrája van, amellyel funkciókat adhat hozzá a CMS-hez; Önnek van webszervere, tárhelyszolgáltatója, adatbázis-kezelő rendszere és hálózata. Mindezek az összetevők független tényezők, amelyek hozzájárulnak a potenciális problémák részarányához.
A felmerülő problémák közé tartozik a lassú teljesítmény, a helytelen vagy sérült tartalom, a hibaüzenetek, és ami a legrosszabb: a halál fehér képernyője (WSoD), ami azt jelenti, hogy webhelye összeomlott, és azonnali beavatkozást igényel.
Még az enyhe teljesítményproblémák – például a 2 másodpercnél rövidebb késleltetés – miatt is aggódnia kell, mert ez károsíthatja (és károsítja) SEO stratégiáját és pozícióját a keresőmotorok eredményei között. Ez pedig közvetlenül azt jelenti, hogy napról napra egyre kevesebb a látogató, mert manapság a gyors válasz minden, különösen a mobilfelhasználók számára.
Éppen ezért kulcsfontosságú, hogy rendelkezzen olyan eszközökkel, amelyeket bármikor használhat, amikor úgy érzi, hogy webhelye nem működik megfelelően. És még ha igen is, mindig van hova javítani a teljesítményén vagy a használhatóságán.
Mi az a hibakeresés?
A hibakeresés olyan feladat, amelyet a fejlesztők végeznek, hogy észleljék és eltávolítsák programjaik hibáit (más néven hibákat). Speciális eszközök segítségével történik, amelyek segítségével láthatja, mi történik a programban, miközben az fut.
Néha a hibakeresési munka legnehezebb része a hibát okozó komponens, parancs vagy utasítás pontos meghatározása. Ehhez a fejlesztők ugyanazt teszik, mint egy orvos, akinek diagnózist kell felállítania: elemzi a tüneteket, és szükség esetén néhány vizsgálatot végez a probléma forrásának azonosítására. Az orvosi tanulmányok szoftverfejlesztési megfelelője egy megfigyelő eszköz, amely információkat nyújt a webhely belső működéséről.
Lássunk néhány lehetőséget.
Tartalomjegyzék
WP_DEBUG
A WordPress beépített hibakeresési segédeszközzel rendelkezik, amelyet gyakran figyelmen kívül hagynak. Ez egy WP_DEBUG nevű „zászló”, amely minden alkalommal elindítja a hibakeresési módot a WordPressben, amikor az aktiválásra kerül. A WP_DEBUG aktiválásakor egy napló jön létre, amely rögzíti a webhely összes tevékenységét. Ha elolvassa ezt a naplót, megtudhatja, hogy mi nem működik megfelelően a WordPress webhelyén.
A WP_DEBUG bekapcsolásához némi kódolást kell végrehajtania a wp-config.php fájl szerkesztésével, és a szükséges sorok hozzáadásával, hogy a webhely minden tevékenységet rögzítsen a naplóban. Ez a kódolási feladat nem mindenkinek való: nagyon körültekintően kell eljárni a wp-config.php fájl szerkesztésénél, mert ha egy sort vagy akár egy karaktert eltévesztünk, előfordulhat, hogy a weboldal működése leáll. Ezenkívül készítsen biztonsági másolatot webhelyéről/fájljairól, mielőtt bármit tenne. Ha elrontja a dolgokat, visszaállíthatja a biztonsági másolatot, és mindent visszaállíthat a normál kerékvágásba.
A wp-config.php fájl szerkesztéséhez használja a tárhelyszolgáltató fájlkezelőjét, vagy egy FTP-kliens segítségével töltse le a fájlt, és nyissa meg helyileg a kívánt szövegszerkesztővel. A fájl a WordPress telepítésének fő könyvtárában található. A megnyitás után keresse meg azt a sort, ahol a WP_DEBUG definiálva van. Így kell kinéznie:
define( 'WP_DEBUG', false );
Ha nincs ilyen sor, keresse a következő megjegyzést:
/* That’s all, stop editing! Happy blogging. */
és adja hozzá a következő sorokat a megjegyzés fölé. Ezek a parancsok arra utasítják webhelyét, hogy naplózza az összes hibát azok megjelenítése nélkül, ami hasznos a nyilvánosan elérhető webhelyeknél:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
Mentse el a módosított fájlt, és ha FTP-t használ, töltse fel webhelyére. Ezután próbálja meg előidézni a hibát (vagy várja meg, amíg megtörténik), és ellenőrizze a debug.log fájlt. A WordPress telepítésének wp-content mappájában találja meg. Megnyithatja egy szövegszerkesztővel, és megkeresheti a hibaüzeneteket, amelyek felfedik, hogy mi okoz problémát a webhelyén.
Ezt követően ki kell kapcsolnia a naplózást úgy, hogy a wp-config.php fájlban hozzáadott vagy módosított sorokban a „true” értéket „false”-ra módosítja.
WPDB hibajelentés
Ha tudja vagy gyanítja, hogy webhelye adatbázisa problémákat okoz, engedélyezheti a WPDB hibajelentést. Ez is igényel némi kódolást. Miután engedélyezte a hibajelentést, utasíthatja webhelyét, hogy kezdje el megjeleníteni az adatbázis-hibákat a képernyőn.
Ne tegye ezt egy élő webhelyen, hacsak nem törődik azzal, hogy a látogatók hibaüzeneteket kapnak a képernyőjükön. Jobb, ha egy bemutató webhelyet használ (az alábbiakban leírtak szerint), ahol mindent tesztelhet, amit csak akar, anélkül, hogy mindenki láthatná, mi történik a motorháztető alatt.
Ezeknek a hibajelentéseknek vagy naplóknak az olvasása bizonyos technikai ismereteket igényel, csakúgy, mint például egy röntgen leolvasásához orvosi ismereteket. Meg kell fejtenie néhány programozási, hálózatépítési vagy adatbázis-zsargont, de valószínűleg megtalálja a webhelyét érintő gyökérproblémát, majd segítséget kér valakitől, aki meg tudja oldani az adott problémát.
Az adatbázis-hibajelentések generálásának megkezdéséhez adja hozzá a következő sort a wp-config.php fájlhoz (a hibakeresési napló létrehozásához korábban leírt módon):
define( 'SAVEQUERIES', true);
Ha ezt az értéket igazra állítja, az adatbázis elkezdi tárolni a webhely összes lekérdezését. Ezután ellenőrizheti az egyes oldalkérések által okozott lekérdezések számát és az egyes oldalkérésekben használt parancsokat. A lekérdezések képernyőn történő megjelenítésének egyik módja az alábbi sorok hozzáadása a téma PHP-fájljához a végrehajtási folyamaton belül:
global $wpdb; print_r( $wpdb->queries );
Ha végzett a hibakereséssel, távolítsa el ezeket a sorokat, hogy visszaállítsa a webhely normál működését.
Színpadi webhely használata
Az átmeneti webhely a tényleges webhely egy klónja, ahol tesztelheti a változtatásokat vagy az új funkciókat, mielőtt élesbe lépne velük. Az is jó ötlet, hogy egy átmeneti webhelyet használjon a problémák hibakeresésére vagy a viselkedésének figyelésére, mert ez megadja a szabadságot, hogy mindent kipróbáljon, anélkül, hogy megzavarná webhelye tényleges felhasználóit.
Fontos, hogy egy állomásozó webhely pontosan tükrözze a tényleges webhely tartalmát és szerkezetét. Amikor új tartalommal vagy új kiegészítőkkel (főleg beépülő modulokkal és témákkal) frissíti a WordPress-webhelyet, frissítse a állomáshelyet a tényleges webhely másolatával. Ily módon, ha probléma lép fel az élő webhelyén, akkor képes lesz megismételni azt a staging környezetben.
Sok felügyelt WordPress tárhelyszolgáltató kínál állomáshelyet, amely hozzáadott értéket jelent fizetett tervéhez. Ez a legfelhasználóbarátabb módja egy színpadi környezet kialakításának, ahol kockázat nélkül játszhat és kipróbálhat dolgokat. Ha azonban tárhelyszolgáltatója nem kínálja fel ezt a lehetőséget, létrehozhat egy állomáshelyet a WP staging csatlakoztat. Ez a beépülő modul megkönnyíti a webhely klónozását, majd úgy használja a klónt, mintha az igazi lenne. Mindig tudni fogja, ha a színpadi környezetben van, mert a képernyő tetején egy narancssárga sáv jelzi ezt.
Ha szereti bemocskolni a kezét, bármikor létrehozhat egy állomáshelyet manuálisan egy aldomainben, feltéve, hogy a tárhelyszolgáltató lehetővé teszi, hogy aldomaint adjon hozzá fiókjához. Az állomáshely ilyen módon történő létrehozásának folyamata kissé körülményes lehet, ezért ha kezdő vagy a WordPress használatában, érdemes egy másik lehetőséget használni.
Query Monitor
A neve félrevezető lehet, mert Query Monitor sokkal többet tesz, mint a lekérdezések figyelését. Ez egy teljes fejlesztői panel a WordPress számára, amely lehetővé teszi a szkriptek, stíluslapok, API-hívások, adatbázis-lekérdezések, PHP-hibák és egyebek hibakeresését. Egyes speciális funkciók lehetővé teszik az Ajax hívások hibakeresését és a felhasználói képességek ellenőrzését.
Miután telepítette és aktiválta, a Query Monitor a leghasznosabb módokon kezdi megjeleníteni a webhely viselkedésével kapcsolatos információkat.
Például összesített adatbázis-lekérdezéseket jelenít meg az azokat elindító függvények, beépülő modulok vagy témák szerint csoportosítva. Az adminisztrátori eszköztár menüje az aktuális oldal élő statisztikáit jeleníti meg, minden hibakeresési információval, amelyre szükség lehet a megoldandó probléma felméréséhez.
A Query Monitor használatával fokozatosan szűkítheti a keresést a hibákra bővítmény vagy téma szerint, amíg meg nem találja azt, amely rontja webhelye teljesítményét vagy hibás működést okoz. A WordPresshez hasonlóan a Query Monitor is teljesen ingyenes és nyílt forráskódú.
Korábban Firebug néven ismerték, Firefox fejlesztői eszközök a Firefox speciális, fejlesztők számára készült változata, amely a legújabb fejlesztési funkciókat és eszközöket kínálja. Nem kifejezetten a WordPress-re vonatkozik, de nagyon hasznosnak bizonyul a webhelyek hibakereséséhez.
A Firefox Developer Tools és a népszerűbb Chrome DevTools összehasonlítása elkerülhetetlen. Ha így tesz, a Firefox tömör elrendezése kiemelkedik. Például rákattinthat a jobb gombbal bármelyik elemre, hogy előhívja az ellenőrző lapot, és a webkonzol gazdag kimenetet kínál az objektumok nyomtatásakor, és sokkal több információt jelenít meg, mint csak a nevét. Extra információkat nyújt bizonyos típusokhoz, lehetővé téve az objektum tulajdonságainak részletes vizsgálatát és gazdagabb információval szolgál a DOM elemekről.
Az Inspector eszközzel megvizsgálhatja és módosíthatja az oldal HTML- és CSS-kódját, lehetővé téve ezt a helyileg a Firefoxban vagy egy távoli eszközön, például a Firefox for Androidon betöltött oldalakkal.
A webkonzol minden információt megjelenít, amelyre szüksége lehet egy weboldallal kapcsolatban: JavaScript, hálózati kérések, CSS, figyelmeztetések, hibaüzenetek és a JavaScript-kód által kifejezetten naplózott tájékoztató üzenetek. Lehetővé teszi továbbá a weboldallal való interakciót JavaScript-kifejezések közvetlen végrehajtásával az oldal kontextusában.
Új ereklye
Az APM (Application Performance Monitoring) iparág egyik legnagyobb szereplőjeként Új ereklye egy kereskedelmi termék, amelyet világszerte fejlesztők ezrei használnak naponta, hogy teljesítménybetekintést kapjanak szoftvertermékeikről. Olyan beépülő architektúrával rendelkezik, amely lehetővé teszi, hogy harmadik felek további funkcionalitást biztosítsanak, így gyakorlatilag végtelen számú technológia figyelhető meg ezzel az eszközzel.
A 9,37 dollártól 200 dollárig terjedő árkategóriával gazdagépenként havonta professzionális hibakeresési feladatokra készült. Kibővített tanulási görbét is hordoz, tehát amellett, hogy pénzt költ a megoldásra, időt is kell fektetni a használat megtanulására. A New Relic felhasználói nagyra értékelik, hogy könnyen integrálható az APM- és infrastruktúra-felügyeleti alkalmazásokba.
Kinsta lehetővé teszi a New Relic egyszerű integrálását a MyKinsta irányítópultjáról.
Debug Bar
Debug Bar a WordPress adminisztrációs sáv hibakeresési menüjéből elérhető bővítmények készlete, amely a hibakeresési információk széles skáláját mutatja. Lehetőségei közé tartozik a konzol, rövid kódok, konstansok, bejegyzéstípusok, cron, műveletek és szűrők, tranziensek, távoli kérések, valamint listaszkriptek és stílusfüggőségek. Ez egy nyílt forráskódú bővítmény, így ingyenesen használható.
A fő beépülő modul, a Debug Bar biztosítja az alapfunkciókat, amelyeket a többi beépülő modul is kibővít. Működik a WordPress által kínált beépített hibakereső jelzőkkel, mint például a WP_DEBUG és a SAVEQUERIES. Ha ezek a jelzők aktívak, a Debug Bar hasznos hibakeresési információkat ad hozzá, például PHP figyelmeztetéseket és MySQL-lekérdezéseket, így megkímélheti a naplófájlok keresésének és olvasásának fáradságát.
A Debug Bar menü minden opciója biztosítja a hibakeresési teljesítmény egy részét. A konzol például olyan konzolt biztosít, amelyben tetszőleges PHP kódot futtathatunk, ami kiválóan alkalmas változók tartalmának tesztelésére (többek között felhasználásra). A Cron információkat jelenít meg a WordPress ütemezett eseményeiről, például a következő esemény időpontjáról, az ütemezett események számáról, az egyéni ütemezett események listájáról stb. A műveletek és szűrők egy másik lehetőség az aktuális kéréshez csatolt horgok megjelenítésére. A Műveletek lapon az aktuális kéréshez kapcsolt műveletek láthatók, míg a Szűrők lapon az összes szűrőcímke, valamint a hozzájuk kapcsolódó funkciók láthatók.
Hibakeresés mindenkinek
A hibakereső eszközöket többnyire szoftverfejlesztő szakemberek számára tervezték. De még ha nem is fejlesztő, ha csak egy WordPress-blogot tart fenn, akkor is hasznos, ha legalább alapvető ismeretekkel rendelkezik webhelye figyeléséről és hibakereséséről. Ezzel olyan információt adhat a fejlesztőnek, amely segít megtalálni a probléma forrását, és ha rosszul érzi magát, megspórolhatja az orvos munkáját, ha saját maga méri fel a hőmérsékletét. mielőtt a kórházba menne.
Tanuljon meg néhány módszert, amellyel pénzt kereshet WordPress-szakemberként.