Kevesebb néha több: rendrakás és hibák elhárítása

Modul 5: Sablonok és bővítmények · Olvasási idő: 9 perc

Tanulási cél: E lecke után képes lesz kitakarítani a bővítményeket, valamint önállóan felderíteni és megoldani egy konfliktust vagy egy fehér oldalt.

Kulcsfogalmak: kikapcsolás vs. törlés, inaktív kód, kritikus hiba, helyreállítási mód (recovery mode), Webhely Egészség, hibaelhárító mód, bővítménymappa átnevezése, WP_DEBUG, WP_DEBUG_LOG, debug.log, hibanapló

A kikapcsolás nem egyenlő a kidobással

A Bővítmények menüben egy bővítményt kikapcsolhat vagy törölhet. A különbség:

• Kikapcsolás: a WordPress többé nem tölti be a bővítményt. A fájlok azonban a wp-content/plugins/ mappában maradnak, és gyakran közvetlenül is lekérdezhetők a webszerveren keresztül. Ha egy adott PHP-fájlban biztonsági rés van, az akkor is megmarad. A betörők ismert, sebezhető fájlokat keresnek, nem aktív bővítményeket.
• Törlés: a fájlok eltűnnek. Egyes bővítmények törléskor az adatbázisban tárolt beállításaikat és tábláikat is eltávolítják, mások viszont meghagyják azokat.

Ha már nem használ egy bővítményt, törölje. A kikapcsolás csak átmeneti megoldás (amíg egy probléma okát keresi). Ugyanez vonatkozik a sablonokra is (2.4 lecke).

Rendrakás: egy állandó kör

Negyedévente egyszer (9.4 lecke) tekintse át a bővítményeit. Minden bővítménynél:

1. Mire való? Ha nem emlékszik rá, derítse ki. Gyakran előfordul, hogy egy bővítményt egykor egyetlen célra telepítettek, majd soha nem távolították el.
2. Még mindig használatban van? Egy diavetítő bővítmény, miközben sehol nincs diavetítő; egy űrlap bővítmény, miközben a kapcsolatfelvételi oldala már másik űrlapot használ.
3. Megoldható nélküle? Tudja ezt már a WordPress, a sablon vagy egy másik bővítmény (5.3 lecke)?
4. Még karbantartják? Mikor frissítették utoljára, még fent van a bővítménytárban?

A rendrakást először végezze tesztkörnyezetben (staging, 8.3 lecke), vagy legalább készítsen biztonsági mentést, és egyszerre csak egy bővítményt távolítson el, hogy tudja, mi romlott el, ha valami elromlik. Figyeljen a shortcode-okra: ha töröl egy bővítményt, amely a [formulier id="2"] kódot szolgáltatta, utána ez a szöveg szó szerint megjelenik az oldalán.

Ha elromlik valami: a kritikus hiba

Egy frissítés, egy új bővítmény vagy egy PHP-frissítés után hirtelen ezt látja:

Súlyos hiba történt a webhelyünkön.

vagy egy teljesen fehér oldalt. Ez azt jelenti: a PHP egy végzetes hiba (fatal error) miatt leállt, mielőtt bármilyen oldal elkészült volna (1.2 lecke). Ennek leggyakrabban az az oka, hogy egy bővítmény vagy sablon nem fér össze valami mással: egy másik bővítménnyel, a WordPress új verziójával vagy a PHP-verzióval.

A WordPress 5.2 óta ilyenkor két dolog történik:

• egy e-mailt küld az adminisztrátori címre, amelyben megnevezi, melyik bővítmény vagy sablon okozta a hibát, és egy különleges hivatkozást is tartalmaz;
• ezzel a hivatkozással bejelentkezhet a helyreállítási módba (recovery mode): ekkor a vezérlőpult működik, a hibát okozó bővítmény átmenetileg ki van kapcsolva, így frissítheti, lecserélheti vagy törölheti azt.

Ezért is olyan fontos, hogy figyelje az adminisztrátori címre érkező leveleket (2.2 lecke).

Önálló felderítés: a lépések

Nem érkezik levél, vagy nem működik a helyreállítási mód? Így tudja saját maga megtalálni a hibát.

1. Nézze meg a hibanaplót

A hiba szinte mindig megtalálható a webszerver vagy a PHP hibanaplójában. A DirectAdmin esetén ezt a domainje naplóinál találja. Keressen egy olyan sort, amely tartalmazza a PHP Fatal error kifejezést, a próbálkozás időpontjával egyeztetve:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Az elérési út elárulja, ki a bűnös: itt a oude-slider mappában lévő bővítmény. A sor többi része elárulja az okot (itt: egy olyan függvényt, amelyet a PHP 8 eltávolított, 8.4 lecke).

2. Kapcsolja be a debugnaplózást (ne a képernyőn való megjelenítést)

Ha a hibanaplóban nincs semmi használható, akkor a wp-config.php fájlban (a „ne szerkessze ezen a ponton túl” sor fölött) állítsa be a következőket:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

A WordPress ekkor minden hibát a wp-content/debug.log fájlba ír, anélkül hogy azokat a látogatóknak megmutatná. Ezt soha ne hagyja tovább bekapcsolva a szükségesnél: a debug.log fájl olyan mappában van, amelyet a webszerver elérhetővé tesz, és aki ismeri a címét, elolvashatja. Ebben elérési utak, néha felhasználónevek és más, egy betörőnek hasznos információ is szerepel. Keresés után kapcsolja ki újra, és törölje a debug.log fájlt. Vagy állítsa be, hogy a WordPress a naplófájlt a webmappán kívülre írja a WP_DEBUG_LOG értékénél megadott elérési úttal (például '/home/gebruiker/logs/wp-debug.log', ha a tárhelyszolgáltatója ezt engedélyezi). A 7.4 leckében ellenőrzi, hogy a debug.log fájl nem nyilvánosan elérhető.

3. Bővítmény kikapcsolása a vezérlőpult nélkül

Ha nem fér hozzá a vezérlőpulthoz, kapcsolja ki a gyanús bővítményt úgy, hogy átnevezi a mappáját, Fájlkezelőn vagy SFTP-n keresztül:

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

A WordPress ekkor nem találja többé a bővítményt, és kikapcsolja. Ha nem tudja, melyik bővítmény az oka, nevezze át az egész plugins mappát plugins-uit névre: ekkor az összes bővítmény kikapcsol. Ha ezután működik az oldal, hozzon létre egy új, üres plugins mappát, tegye vissza a bővítményeket egyenként, és minden egyes bővítmény után ellenőrizze, visszatér-e a hiba. Sablon esetén ugyanez vonatkozik: nevezze át az aktív sablon mappáját, és a WordPress visszaáll egy alapértelmezett sablonra, ha az még elérhető (2.4 lecke).

4. Konfliktusok végzetes hiba nélkül

Nem minden probléma kritikus hiba. Néha csak egy adott funkció nem működik: egy gomb nem csinál semmit, az űrlap nem küldi el az adatokat, a szerkesztő félig tölt be. Ilyenkor gyakran két bővítmény, vagy egy bővítmény és a sablon közötti konfliktusról van szó. Ehhez hasznos a hivatalos Health Check & Troubleshooting bővítmény: a hibaelhárító módban kizárólag az Ön saját munkamenetére vonatkozóan kikapcsolja az összes bővítményt, és átvált egy alapértelmezett sablonra, miközben a látogatók továbbra is a normál weboldalt látják. Ezután egyenként visszakapcsolhatja őket, amíg a probléma újra elő nem jön.

Nézze meg a böngészője konzolját is (F12): a JavaScript-hibák gyakran megnevezik a fájlt, ezáltal a bővítményt is.

Webhely Egészség

A Eszközök > Webhely Egészség menüpont alatt a WordPress saját maga ellenőrzi a weboldalát: elavult PHP-verzió, inaktív bővítmények és sablonok, hiányzó PHP-kiegészítők, nem működő REST API, lemaradásban lévő ütemezett feladatok. Az Info fülön megtalálja a telepítésének minden adatát (verziók, elérési utak, PHP-beállítások). Ezt a fület lemásolhatja, és elküldheti, ha segítséget kér. Minden nagyobb módosítás után érdemes ide is bepillantani.

Összefoglalás

• A kikapcsolás meghagyja a fájlokat; törölje azokat a bővítményeket és sablonokat, amelyeket nem használ.
• Negyedévente takarítson, egyszerre csak egy bővítményt, biztonsági mentéssel vagy tesztkörnyezetben.
• Kritikus hiba esetén a WordPress levelet küld egy, a helyreállítási módra mutató hivatkozással.
• A hibanapló vagy a debug.log megnevezi a bűnös elérési útját; keresés után kapcsolja ki újra a debugolást, mert a debug.log fájl különben nyilvánosan elérhető.
• Vezérlőpult nélkül úgy kapcsolhat ki egy bővítményt, hogy átnevezi a mappáját; a konfliktusokat a hibaelhárító móddal keresheti meg.

Kvíz

Feladat

A5.4 feladat: Nem nyilvános a debug naplója? Adja meg a weboldala címét, és a feladat által megadott kóddal bizonyítsa, hogy az valóban az Ön saját weboldala (egy TXT-rekorddal vagy egy kis fájllal). A program lekéri a /wp-content/debug.log elérési utat: az a jó, ha ez nem létezik, vagy el van utasítva (404 vagy 403). Ha a program visszakap egy fájlt, az piros jelzést kap. Emellett a program megszámolja, hány különböző bővítménymappa fordul elő a kezdőlapja HTML-kódjában (ez csak tájékoztató jellegű).

D5.4 feladat: Bővítménylistájának rendbetétele. Készítsen listát az összes bővítményéről (aktív és inaktív egyaránt): név, mire való, szükséges-e még (igen/nem), lehetséges megoldás bővítmény nélkül. Távolítsa el (biztonsági mentés után vagy tesztkörnyezetben) azokat a bővítményeket, amelyekre már nincs szükség, egyszerre csak egyet, és minden eltávolítás után ellenőrizze, hogy a weboldal még mindig működik-e. Írja le, hány bővítménye volt, és hány maradt, valamint jegyezze fel, maradtak-e olyan shortcode-ok, amelyeket el kellett takarítania.

További olvasnivaló

Ezek a cikkek a WebOké vezérlőpultjaiban leírt lépéseket mutatják be; más vezérlőpultokon hasonlóan működnek.

• DirectAdmin útmutató 18.1: A weboldalam fehér vagy 500-as hibát jelez
• 500-as hiba vagy „kritikus hiba” a weboldalán (akár WordPress-frissítés után is)
• DirectAdmin útmutató 14.6: Hibák PHP-frissítés után és a hibanapló megkeresése
• DirectAdmin útmutató 17.2: Oldal áttekintés és naplók: a hibanapló és a hozzáférési napló
• Hogyan hibakereshetek PHP-ban a php.ini módosítása nélkül?
• A WordPress hibakeresése (developer.wordpress.org, angol nyelven): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/