A kevesebb több: rendrakás és konfliktusok megoldása

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

Tanulási cél: A lecke után Ön képes lesz rendet rakni a bővítmények között, és saját maga felderíteni és megoldani egy konfliktust vagy egy fehér oldalt.

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

A kikapcsolás nem kidobás

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

• Kikapcsolás: a WordPress már nem tölti be a bővítményt. A fájlok azonban a wp-content/plugins/ mappában maradnak, és gyakran továbbra is közvetlenül lekérhetők a webszerveren keresztül. Ha a bővítmény valamelyik különálló PHP-fájljában biztonsági rés van, az a rés továbbra is ott van. A támadó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 lévő beállításaikat és tábláikat is eltávolítják, mások ott hagyják őket.

Ha egy bővítményt már nem használ, törölje. A kikapcsolás csak átmeneti megoldás (például egy hiba keresése közben). Ugyanez érvényes a sablonokra is (2.4. lecke).

Rendrakás: egy rendszeres kör

Negyedévente egyszer (9.4. lecke) nézze végig a bővítményeit. Minden bővítménynél:

1. Mire való? Ha már nem emlékszik, nézzen utána. Gyakran kiderül, hogy egy bővítményt valamikor egyetlen feladatra telepítettek, és soha nem távolították el.
2. Használja még valami? Például egy csúszka bővítmény, miközben sehol nincs csúszka, vagy egy űrlapbővítmény, miközben a kapcsolati oldal egy másik űrlapot használ.
3. Meg lehet lenni nélküle? Tudja ezt már a WordPress, a sablon vagy egy másik bővítmény (5.3. lecke)?
4. Karbantartják még? Mikor frissítették utoljára, megtalálható még a bővítménykönyvtárban?

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

Ha baj van: 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:

Kritikus hiba lépett fel a honlapon.

vagy egy teljesen fehér oldalt. Ez azt jelenti, hogy a PHP egy végzetes hibával (fatal error) leállt, mielőtt az oldal elkészült volna (1.2. lecke). Ezt általában egy olyan bővítmény vagy sablon okozza, amely 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 a WordPress ilyenkor két dolgot tesz:

• 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 mellékel;
• ezzel a hivatkozással a helyreállítási módba (recovery mode) léphet be: az admin felület ekkor működik, a hibát okozó bővítmény átmenetileg ki van kapcsolva, így frissítheti, lecserélheti vagy törölheti.

Ezért olyan fontos, hogy az adminisztrátori cím olyan legyen, amelyet Ön valóban olvas (2.2. lecke).

Saját keresés: a lépések

Nem érkezik e-mail, vagy nem működik a helyreállítási mód? Így találja meg saját maga a hibát.

1. Nézze meg a hibanaplót

A hiba szinte mindig szerepel a webszerver vagy a PHP hibanaplójában. A DirectAdminban ezt a domain naplói között találja. Egy PHP Fatal error kezdetű sort keressen, a próbálkozása időpontjával:

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

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

2. Kapcsolja be a debug naplót (ne a képernyős kijelzést)

Ha a hibanaplóban nincs használható információ, írja a következőt a wp-config.php fájlba (a „That's all, stop editing!” megjegyzés fölé):

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 a látogatóknak megjelenítené. Soha ne hagyja ezt bekapcsolva a szükségesnél tovább: a debug.log egy olyan mappában van, amelyet a webszerver kiszolgál, így aki ismeri a címét, el is tudja olvasni. Elérési utak, néha felhasználónevek és más, a támadóknak hasznos információk szerepelnek benne. A keresés után kapcsolja ki újra, és törölje a debug.log fájlt. Vagy írassa a WordPressszel a naplófájlt a webmappán kívülre úgy, hogy a WP_DEBUG_LOG értékeként egy elérési utat ad meg (például '/home/felhasznalo/logs/wp-debug.log', ha a tárhelyszolgáltatója ezt engedi). A 7.4. leckében ellenőrzi, hogy a debug.log nem nyilvános.

3. Bővítmény kikapcsolása admin felület nélkül

Ha nem tud belépni az admin felületre, kapcsolja ki a gyanús bővítményt úgy, hogy a mappáját átnevezi a Fájlkezelőben vagy SFTP-n keresztül:

wp-content/plugins/regi-slider   ebből lesz:   wp-content/plugins/regi-slider-ki

A WordPress ekkor már nem találja a bővítményt, és kikapcsolja. Ha nem tudja, melyik az, nevezze át a teljes plugins mappát plugins-ki névre: ekkor minden bővítmény kikapcsol. Ha a weboldal így működik, hozzon létre egy új, üres plugins mappát, tegye vissza egyenként a bővítményeket, és minden bővítmény után nézze meg, visszatér-e a hiba. Sablonnál ugyanígy járhat el: nevezze át az aktív sablon mappáját, és a WordPress visszaáll egy alapértelmezett sablonra, ha az még megvan (2.4. lecke).

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

Nem minden probléma kritikus hiba. Néha csak egy funkció nem működik: egy gomb nem csinál semmit, az űrlap nem küld, a szerkesztő csak félig töltődik be. Ilyenkor gyakran két bővítmény, vagy egy bővítmény és a sablon ütközik. Ehhez hasznos a hivatalos Health Check & Troubleshooting bővítmény: hibaelhárítási módban csak az Ön munkamenetére kapcsolja ki az összes bővítményt, és vált egy alapértelmezett sablonra, miközben a látogatók a megszokott weboldalt látják. Ezután egyenként kapcsolja vissza őket, amíg a probléma újra elő nem jön.

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

Webhely Egészség

Az Eszközök > Webhely Egészség menüpontban a WordPress maga ellenőrzi a weboldalt: elavult PHP-verzió, nem aktív bővítmények és sablonok, hiányzó PHP-bővítmények, nem működő REST API, lemaradó ütemezett feladatok. Az Információ lapon a telepítés összes adata megtalálható (verziók, elérési utak, PHP-beállítások). Ezt a lapot kimásolhatja, és elküldheti, amikor segítséget kér. Minden nagyobb változtatás után nézzen be ide.

Ö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 rakjon rendet, egyszerre egy bővítménnyel, biztonsági mentéssel vagy tesztkörnyezetben.
• Kritikus hiba esetén a WordPress e-mailt küld egy hivatkozással a helyreállítási módhoz.
• A hibanapló vagy a debug.log megadja a bűnös elérési útját; a keresés után kapcsolja ki újra a debugot, mert különben a debug.log nyilvános.
• Admin felület nélkül egy bővítményt a mappája átnevezésével kapcsolhat ki; a konfliktusokat hibaelhárítási módban 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 adott kóddal igazolja, hogy a weboldal az Öné (egy TXT rekorddal vagy egy kis fájllal). A program lekéri a /wp-content/debug.log fájlt: akkor jó az eredmény, ha ez nem létezik, vagy a kérést elutasítják (404 vagy 403). Ha a program egy fájlt kap vissza, az piros. Emellett a program megszámolja, hány különböző bővítménymappa szerepel a kezdőlap HTML-kódjában (csak tájékoztatásul).

D5.4. feladat: A 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): név, mire való, szükség van-e még rá (igen/nem), alternatíva bővítmény nélkül. Törölje (biztonsági mentés után vagy tesztkörnyezetben) azokat a bővítményeket, amelyekre már nincs szükség, egyszerre egyet, és minden törlés után ellenőrizze, hogy a weboldal még működik-e. Adja meg, hány bővítménye volt és hány maradt, és jegyezze fel, maradtak-e olyan shortcode-ok, amelyeket el kellett takarítania.

További olvasnivaló

Ezek a cikkek a WebOké paneljeiben mutatják be a lépéseket; más panelekben 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 (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?
• Hibakeresés a WordPressben (developer.wordpress.org, angol nyelven): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• WordPress-bővítmények kiválasztása, értékelése és rendszerezése