Hibakeresés a weboldalakban.
Ez a leírás elsősorban wordpress oldalakhoz készül, de mivel minden CMS rendszer hasonló felépítésű, ezért más weboldalak esetében is használhatóak.
Egy weboldal esetében nincs általános hibaelhárítási útmutató, hiszen minden weboldal egyedi, más más bővítmények vannak telepítve mindegyikre, ezért senki ne várja azt, hogy a leírásban megtalálja a választ a hibára.
Viszont ha elolvasod és alkalmazod a leírtakat akkor jó eséllyel meg fogod találni a hibát.
Sajnos rendszeresen tapasztaljuk azt, hogy még olyan emberek sem tudják, hogy kellene egy hiba okát felderíteni, akik WordPress weboldalak kezelésével foglalkoznak.
A gond ott kezdődik, hogy a WordPress ha hibát érzékel, akkor vagy egy semmitmondó hibaüzenetet jelenít meg, vagy egy üres oldal jelenik meg.
1: Hibajelzés bekapcsolása.
Ebben az esetben a legelső dolgunk legyen a hiba kijelzés bekapcsolása.
Ezt két helyen kell megtenni.
1: A cPanel felületen a Multi PHP.INI editorban válasszuk ki, a domain nevet ahol a hiba van.
És itt a Display Error -nál a kapcsolót rakjuk át ON állásba. Sok esetben már ez is elég egy normális hibaüzenet eléréséhez.
2: A Weboldal könyvtárába, keressük meg a wp-config.php fájlt, ezt a gyökér mappában kell keresni, így nem lesz nehéz megtalálni.
A Fájlba keressük meg a következő sort: define(‘WP_DEBUG’, false); Itt a false (hamis) szót írjuk át treu (igaz) ra. Ezután mentsük el a fájlt.
A fájl szerkesztéséhez javasolt a cPanel fájlkezelő használata. Ez amellett hogy gyorsabban elérhető, biztos, hogy jó formátumba menti el a fájlt. (erre rögtön ki is térünk bővebben)
Fontos, hogy az 1-es pontot is be kell kapcsolni, máskülönben valószínű nem fog működni.
Ha ezeket bekapcsoltuk, és a weboldalt frissítjük, akkor jó eséllyel már más hibaüzenetet fogunk látni.
Aki ért hozzá, az sok esetben rögtön rájön, hogy mi is lehet a hiba oka, de aki nem ért hozzá, annak érdemes a hibát kimásolnia és rákeresnie a Googleba.
Fontos, hogy a hibaüzenetnek csak arra a részére keressünk rá, amiben nincs benne a domain nevünk, vagy a felhasználónevünk.
Egy példa:
Hiba részletei
===============
A(z) /home/felhasznalonev/public_html/domain-nev.
Mint látható, az üzenetben szerepel a felhasználónév és a domain név is. Ha valaki erre akarna rákeresni a Google ban, akkor aligha lenne rá találat, hiszen ezek egyedi azonosítók.
Ebben az esetben csak az alábbi részre kell rákeresni: “Allowed memory size of ” Az utána következő számok megint csak nem érdekesek, mivel ezek egyediek.
Az Allowed memory size of az egyik leggyakoribb hiba. Általában bővítmények telepítése, vagy a WP oldal frissítése után szokott előjönni.
A hiba szerint a program futtatásához nincs elég memória kiosztva, ezért nem tudja a programot futtatni a szerver.
A megoldás: lépjünk be a tárhelyre és a Multi PHP.INI editorban válasszuk ki, a domain nevet ahol a hiba van, és itt a memory_limit értéket növeljük meg. Érdemes ezt legalább 500-1000M ra beállítani, így valószínűleg később sem lesz vele gondunk.
2: Nem megfelelő webszerkesztő használata
Másik gyakori hiba a nem megfelelő szerkesztő használata.
Sokan akik kicsit jobban értenek a weboldalakhoz, itt-ott belenyúlnak kézzel, és közvetlenül a fájlokat szerkesztik. Például a fenti memória növelést is meg lehet oldani, a php.ini fájl szerkesztésével is.
Viszont sok esetben a fájlok szerkesztésére a Windows jegyzettömböt használják, mivel ez az alapértelmezett szerkesztő.
Ezzel csak az a baj, hogy a Windows jegyzettömb a fájl mentése után elhelyez egy láthatatlan karaktert a fájl elejére, ez az úgynevezett BOM karakter.
Ez olyan fájloknál amit nem a szerver dolgoz fel, hanem a böngésző, ott nem jelent gondot, Pl: css fájlok, vagy HTML fájlok, szerkeszthetőek jegyzettömbbel is.
Viszont minden olyan fájlt amit a szerver dolgoz fel, tilos ezzel szerkeszteni, ugyanis a szerver nem tudja értelmezni ezt a karaktert, és rögtön megakad a program futása.
Az eredmény 500 Internal Server error lesz.
Elhárítása:
1: A cPanel fájlkezelő szerkesztőjével nyissuk meg a fájlt, és itt látni fogunk a sor elején egy piros pöttyöt, (BUM karakter), ezt töröljük és mentsük el a fájlt.
2: Használjunk programozóknak szánt szerkesztőt pl: Notepad++ ebbe nyissuk meg a fájlt, majd mentés másként, itt válasszuk ki a sima UTF8 formátumot. (Van olyan is hogy UTF8+BOM)
3: Hibakeresés a bővítményekben.
Lassú weboldal, vagy nem megfelelő megjelenés okai sok esetben a hibás bővítmények.
Ezek jellemzően valamilyen programozási hiba eredménye, miatt alakulnak ki.
Nem feltétlen jelentkezik minden webhelyen, mivel előfordul, hogy bizonyos bővítmények ütközése miatt alakul ki a hiba.
Néha a hiba elég egyértelműen jelentkezik, mivel a weboldal egésze vagy csak bizonyos részei nem töltődnek be.
Illetve van olyan is amikor egy bővítmény hiba miatt az oldal 30-60 másodpercig áll, és vár, majd az idő letelte után a program futása tovább folytatódik.
Ilyen hibákat olyan bővítmények okozhatnak elsősorban, amik nem kapcsolódnak közvetlenűl az oldal megjelenéséhez. Például, statisztikai, SEO, kiegészítők, amik minden lapletöltéskor lefutnak, de az oldal megjelenését nem befolyásolják.
A legrosszabb hiba az, amelyik, csak lassulást okoz.
Gyakori, hogy egy frissítés után az ügyfél azt tapasztalja, hogy a weboldal lassan töltődik be. Persze ilyenkor az rögtön a szolgáltató lesz a hibás, biztos, ő állított el valamit a szerveren. Nos néha tényleg előfordul, hogy a szerveren egy folyamat beragad, és ez lassítja a szervert, viszont ez elég ritka. Évente csak pár ilyen eset szokott lenni.
Az ilyen hibákra, viszonylag könnyen rájövünk, mivel, rendszerint sok ügyfél is jelzi a lassulást, és ilyenkor rendszerint a szerverben kell keresni a hibát.
Az ügyfél folyamatok lassítására pedig csak a Cloudlinux CPU vagy I/O limitek módosításával lenne lehetőségünk, de ezt a cPanel felületen le lehet ellenőrizni, hogy milyen limitek vannak beállítva.
Továbbá a szolgáltatónak nem érdeke az, hogy egy weboldal lassabban működjön, épp ellenkezőleg, arra törekszünk, hogy a weboldalak minél gyorsabbak legyenek. (ezért is emeltünk az elmúlt évben 2x is limiteket, valamit ezért ruháztunk be nem kevés pénzt a litespeed alkalmazásba)
De ha nem a a szolgáltató lassítja, akkor mi lehet a gond?
Sajnos a legjobb fejlesztőkkel (programozók) is megesik, hogy hibáznak.
Egy komplex programban pedig nem nehéz hibázni. Elég egy apró hiba, amit nem is feltétlen lehet hibának nevezni, mivel a program adott esetben működik, csak lassabban mint eddig.
Aki nézi a Formula-1 et, az is láthatja, hogy egy apró módosítás mennyit tud változtatni az autó viselkedésén, sebességén.
Néha egy programban is épp elég egy ilyen apró változtatás, és van, hogy lassabb lesz a program futása.
Hogy keressünk meg egy lassú/hibás bővítményt?
A módszer egyszerű, a bővítményeket szépen sorban ki kell kapcsolni.
Kikapcsolás után ellenőrizni kell az oldal sebességét.
Ha nem tapasztalunk érezhető gyorsulást, akkor a folytatni kell a következő bővítménnyel.
Néha a lassulást, vagy a hibás működést olyan bővítmény okozza amit nem is használunk. A saját weboldalunknál egy időben, folyamatos szétesést, és animáció hibákat tapasztaltam. Akár hogy is kerestem a hibát nem tudtam rájönni mi okozza.
A bővítmények nagy részét a fenti módszerrel leteszteltem. kivéve egyet, mivel tudtam, hogy az csak fel lett telepítve, viszont sehol nem használtam az oldalban, igy gondoltam, hogy hibát sem okozhat. Több órányi szenvedés után, végül úgy döntöttem azt is kikapcsolom. És láss csodát, az oldal egyből megjavult.
Ráadásul ez a bővítmény egy nagyon népszerű Ellementor kiegészítő volt.
(Megjegyzés: a szerverhibát egyébként nagyon könnyű kizárni, elég csak egy aldomain névre az automata telepítővel feltelepíteni egy új wordpresst, és az minden bizonnyal hiba nélkül, villámgyorsan fog működni, ha ez is akadozva működik, akkor viszont tényleg a szerverrel lehet gond, bár ilyenkor már a cPanel használata közben is jelentkezni fog a lassulás.)
Megoldás: A Debug mód bekapcsolása sok esetben itt is segíthet.
De amennyiben nincs semmi értékelhető hibaüzenet, nem marad más hátra mint a telepített bővítményeket kikapcsolni, majd megnézni az oldalt, és ha ugyanúgy lassan töltődik be vagy szétesik az oldal, akkor, vissza lehet kapcsolni, és a következővel lehet folytatni.
A wp-content/plugins mappa átnevezésével az összes bővítményt “kikapcsolhatjuk”. Ez egy gyors megoldás, annak az ellenőrzésére, hogy egyáltalán a bővítményekkel van-e baj. Ezt azonban csak saját felelősségre próbáld ki!!
4: Hibakeresés bővítménnyel.
Léteznek olyan bövítmények amelyek segíthetnek a hiba feltárásban.
Ezeket érdemes fenntartással kezelni, mivel sok esetben félrevezető lehet az eredmény.
Ilyen például a Health Check & Troubleshooting
Telepítés után a Vezérlőpult >> Health Check menü pontban fogod megtalálni a bővítményt. Ez különféle vizsgálatokat végez el, és egy piros x-el fogja jelölni a problémákat ha vannak.
Egyéb előforduló hibák:
Gyakori, hogy a hibákat maguk a felhasználók helyezik bele az oldalba:
Az oldal szétesését akár az is okozhatja, hogy bizonyos tartalmat más weboldalról, illetve World szövegszerkesztőből akarunk átemelni.
A grafikus szerkesztő felületen minden jónak néz ki, viszont ha megnézzük a forráskódot, kiderül, hogy a másolás nem csak a szöveget hozta át, hanem egyéb szöveg és oldal formázásokat is.
Ezek a weboldalunk szétesését, és furcsa kinézetét okozhatják.
Amennyiben, frissítették a weboldalt és frissítés után nem akar működni, érdemes a memória limiteket megnézni, és emelni rajta. (cPanel –> Multi PHP INI editor)
Továbbá érdemes a használt PHP verziót is megnézni, lehet, hogy a frissített motornak, már újabb PHP verzióra van szüksége a hibamentes működéséhez. (cPanel –> Multi PHP manager)
Fontos a biztonságra is figyelni.
Noha cégünk a lehető legjobb biztonsági szoftvereket alkalmazza, ezek sem tudnak minden támadási kísérletet megakadályozni, ha tárt ajtókkal várjuk a támadókat.
Egy nem frissített weboldal az idő múlásával egyre több ismert biztonsági hibát fog tartalmazni.
Az ilyen hibákat automata programokkal keresik a hackerek, épp ezért mindegy hány látogatója van az oldalnak, vagy mivel foglalkozik, minden weboldal veszélyben van.
A hackerek behatolását, sok esetben nem is lehet észrevenni, viszont a háttérben az oldalt lassítják, az erőforrásokat elfogyasztják, miközben a háttérben olyan feladatokat végeznek, ami a támadónak bevételt hoz.
Pl: Spamet küldenek, vírusokat terjesztenek, más weboldalakat próbálnak feltörni.
Megoldás: A weboldalt és a bővítményeket is rendszeresen frissítsd!
Ezt érdemes korán reggel megtenni, hogy ha bármilyen hiba történik akkor a hajnali mentésből vissza lehet állítani az oldalt.
Természetesen később is vissza lehet állítani a weboldalt, viszont sokkal rosszabb, ha 1 napos munkánk kárba veszik a visszaállítás után.
De érdemes saját mentést is készíteni a saját gépre.
A felhasználó nevünk ne ADMIN legyen !
A jelszó feltörési kísérleteknél ez a leggyakoribb felhasználónév amivel próbálkoznak.
Érdemes valamilyen biztonsági bővítményt is használni.
pl: wordfence.
1db elég, de az jó legyen.
Ui: Érdemes már a sablon választánál is figyelni a gyorsaságra, sok esetben a sablon szépen néz ki, de nem jól van programozva, ezért a weboldal lassú lesz.
Ugyanígy érdemes csak a szükséges bővítményeket telepíteni!
Minden olyan bővítmény amit nem használunk, inaktíválni és törölni kell.
Az aktív bővítmények még akkor is okozhatnak hibát, ha azt nem használjuk, továbbá minden bővítmény biztonsági kockázatot növel.
Érdemes olyan bővítményt választani amit sokan használnak, és rendszeresen frissítenek. Azokat a bővítményeket pedig messzire kerülni kell amit 8-10 hónapja frissítettek utoljára.
Ezeket az adatokat a bővítmények mellett láthatjuk.
+1 megjegyzés!
Ha megjelenik egy program frissítés, akkor érdemes várni 1-2 napot a telepítéssel (frissítéssel).
Ugyanis, “nagyon gyakori”, hogy egy programfrissítés hibásan megy ki.
Ez sajnos még a legnagyobb cégekkel is megesik Apple, Samsung, stb..
Mindegyik adott már ki olyan frissítést a telefonjaikhoz, amit utána már csak a szervízben lehetet megjavítani. Pedig a kiadás előtt szigorúan tesztelnek mindent.
A webes programoknál még gyakrabban előfordulnak ilyen hibák.
Viszont ezek a hibák, nagyon gyorsan kiderülnek, és a kiadó vagy leállítja a frissítés terjesztését, vagy a lehető leghamarabb kiad egy sürgősségi javítást.
Épp ezért érdemes várni 24-48 órát, hogy az ilyen hibák inkább másnál derüljenek ki.
Természetesen túl sokat sem szabad várni, hiszen a frissítések, a legtöbb esetben hibajavításokat tartalmaznak, és nagyon gyakran, biztonsági hibákat is javítanak.
Ha ezek a hibák nem kerülnek javításra, akkor ezen keresztül a weboldalt könnyen fel tudják törni a későbbiekben.
