WordPress Internal Server Error
Utolsó frissítés Oct 5, 2018
WordPress Internal Server Error

A WordPress Internal Server Error hibaüzenet meglehetősen dühítő. Különösen ha az ember „csak” felhasználóként kezeli a honlapját, és nemhogy hozzáférése, de hozzáértése sincs a szerverhez.

Itt most nem egy átfogó megoldás listát szeretnék adni, inkább bemutatok egy bámulatosan egyszerű, mégis kemény fejtörést és nagyjából három óra izzadságot okozó történetet.

WordPress 3.5.2 frissítés és Internal Server Error

A WordPress 3.5.2 frissítését csináltam a saját és általunk kezelt ügyfeleink honlapjának. Tényleg, ez egy pár perces rutinművelet még akkor is, ha az ember szabályosan lementi előtte az adatbázist és a fájlokat, ha esetleg valami hiba történne.

Talán a tizedik honlapnál tartottam, amikor beütött a krach. Egyik kedves ügyfelünk honlapja volt, amit ráadásul eredetileg nem is mi csináltunk. Egy szedett-vedett, több tucat – többek között lopott – bővítményből összetákolt és szinte kezelhetetlen honlapot kaptunk eredetileg, amit rendbe kellett szednünk. A hosting sem nem a mi szerverünkön, sem nem általunk támogatott szerveren volt, ezt is úgy örököltük.

WordPress Internal Server Error

A megérzés

Nem tudom, ki hogy van vele, de néha már menet közben érzi az ember, hogy valami nem lesz jó. Amikor megnyomtam a „Frissítés telepítése” gombot, már éreztem, hogy valami gond lesz. Már a letöltés is annyira borzasztóan lassú volt, mintha egy tizenöt éve még hasító, 56 Kb/sec telefonos kapcsolaton próbálta volna a szerver elérni az új WordPress verziót. Nem normális ez egy szerverteremben álló géptől, gondoltam, de csak néztem tovább, ahogy szépen lassan kicsomagolja és telepíti a fájlokat.

Amikor aztán csigalassú munkája végén a szerver befejezte a frissítést, először megnyugodva fújtam ki a levegőt, de a nyugalom nem tartott sokáig. Pár másodperc, és szíven ütött a látvány:

Forpsi Internal Server Error hibaüzenet

Forpsi Internal Server Error hibaüzenet

Megjegyzés: ez a kép nem akkor készült, ezt egy fórumon találtam, ahol hasonló problémával küzdöttek.

WordPress Internal Server Error és a .htaccess fájl

Ami megnyugtató volt első körben – és aztán majd később még több fejfájást okozott -, hogy ez a hiba a honlapon magán nem jelentkezett, csak az adminisztrációs felület vált elérhetetlenné. Csak, mondom persze nem is kicsit ironikusan.

Egy WordPress Internal Server Errornak sok oka lehet, és ezeket nem is lehet mindig megoldani a szerver rendszergazdája nélkül. Mégis, az egyik leggyakoribb az ún. .htaccess fájllal kapcsolatos. Ez a fájl a linux szervereken többek között azt a célt szolgálja, hogy a csúnya kirxkraxos oldalcímek helyett olyan szép url-jeid legyenek, amiket a kereső is szeret.

Elkezdtem hát „játszani” ezzel a fájllal, hátha ott kavarodott össze valami. Hát ez volt a hiba.

Amikor már a honlap sem működik

A .htaccess fájl megpiszkálásával egyetlen dolgot értem el: most már nem csak az adminisztrációs felület, de maga a honlap sem működött. Ciki.

És innentől kezdve semmi. Akármit csináltam, akármit állítottam át vagy vissza, a honlapon egyetlen kedves üzenet fogadott: „500 Interal Server Error. Error message: Premature end of script headers: index.php”.

A megoldás

Nem részletezem, hogy mennyi dolgot próbáltam ki, többek között szépen visszafrissítve a WordPresst egészen 3.4.2-ig. A megoldást végül egy olasz blogon találtam meg.

A dolog pedig iszonyúan egyszerű volt, csak hát az az effektus állt fönn, hogy minél közelebbről nézel valamit, minél inkább benne vagy a dologban, annál kevésbé vagy képes az igazi okokat és a megoldást meglátni. Ahogy egyik kedvenc vállalati trénerem, Piroska Gyula szokta mondani: „Nem tudsz eltolni egy szekrényt, ha benne vagy.”

Fájlok és jogosultságok

Száz szónak is egy a vége: a linux/unix alatt a fájloknak és mappáknak okos jogosultság beállításaik vannak. Három számmal meg lehet adni, hogy egy fájlt vagy egy mappát ki nyithat meg olvasásra, ki írásra.

Php és html fájlok esetében – amit pl. a WordPress is használ – általános a 644, míg könyvtárak esetében a 755 jogosultság. A WordPress az automatikus frissítés során ezeket a jogosultságokat állította be, és végül ez okozta a hibát.

Ne kérdezd hogy miért, mert nem is érdekel, ez a szolgáltató a fájlok esetében is a 755 – egyébként megengedőbb – jogosultságot várja el. Hogy ennek van-e bármilyen biztonsági kockázata, azt én innen nem tudom megmondani. Talán egy linux guru lent a hozzászólásoknál elmondhatja erről a véleményét, előre is megköszönöm.

Egy biztos: a megoldás rém egyszerű volt. Ftp-vel bejelentkezve és szépen kijelölve az összes fájlt és mappát a www (vagy más esetben public_html, html) könyvtáron belül, az összes jogosultságát átállítottam 755-re.

Ennyi. A honlap azonnal működött, az adminisztrációs felületre is be tudtam jelentkezni, mintha mi sem történt volna.

Megjegyzés: az olasz blogon jelzett define(‘FS_CHMOD_FILE’,0755); és define(‘FS_CHMOD_DIR’,0755); wp-config.php beállítás elvileg ugyanezt a célt szolgálja, de valamiért ebben az esetben nem működött. Ezért fordultam ehhez a meglehetősen brutális, de mégis eredményt hozó megoldáshoz.

Köszönöm a kedves hosting szolgáltatónak a három órás szórakozást! Adrenalintermelés tekintetében egy intenzív bungee-jumping ugrással is felvette a versenyt. 🙂

A következtetéseim

Tanulság 1

Nem vagyok és nem is akarok linux guru vagy szerver rendszergazda lenni. Az egy külön szakma. Programoztam már linux környezetben, írtam scripteket, valamit értek hozzá, de távol álljon tőlem hogy akár egy otthoni teszt szervert is saját magam fel akarjak állítani. Még egyszer mondom: az egy külön szakma, kenyeret is tudok sütni, mégis bejárok a pékhez minden nap.

Egy átlag felhasználó manapság szerintem nem kell, nem szabad hogy értsen ilyen dolgokhoz. Igenis elvárás kell hogy legyen, hogy ha leül a gépe elé, akkor néhány kattintással feltelepítsen egy WordPresst (vagy más tartalomkezelőt) arra a szerverre, amiért fizet, és onnantól különösebb szakértelem nélkül képes legyen a gondolatait, az üzenetét megosztani a világgal.

Sok szerver szolgáltató egyszerűen kijelenti, hogy nem támogatja a WordPresst, hogy ő egy tárhelyet és php futtatási lehetőséget biztosít, az már a felhasználó baja, ha éppen WordPresst akar és az nem fut rajta egyszerűen.

Könyörgöm, több mint 60 millió WordPress honlap fut a világban! Tényleg lehet ennyire belesz_rom hozzáállással lenni ezekhez a felhasználókhoz? Olyan ez nekem, mintha azok a rohadt ügyfelek légkondit, ABS-t meg ki tudja mit nem szeretnének az autóba, de az autógyárak egyszerűen csak ráznák a fejüket: itt a négy kerék, gurul és még kormányozni is tudod – mi nem kéne még?

Tanulság 2

  • WordPress frissítést ne csinálj anélkül, hogy lenne teljes ftp és adatbázis hozzáférésed. Lehet, hogy ezerszer nem lesz erre szükséged, de talán ezeregyedszer igen. Most ftp nélkül a honlap két napig biztosan elérhetetlen lett volna.
  • Ha lehet, csak munkaidőben frissíts. Magyarországon a szerver szolgáltatók többsége semmilyen kontakt lehetőséget nem biztosít ilyen esetre – így volt ez most is -, ismét csak egy két napos leállás valószínűségét erősítve.
  • Nézz szét, mielőtt szerver szolgáltatót választasz. Nem biztos, hogy a legolcsóbb kerül hosszú távon is a legkevesebbe.

Szétvert billentyűzet fénykép: jronaldlee, Flickr.

Ingyenes anyagok

Rólunk mondták

SEO könyv

Stabil bevétel keresőoptimalizálással 2020 borító 3D látványterv

SEO hírek

Keresőoptimalizálás

Kapcsolódó bejegyzések

WordPress kapcsolódó bejegyzések

WordPress kapcsolódó bejegyzések

WordPress kapcsolódó bejegyzések bővítmény: Haogyan jelenítsd meg a honlapodon a kapcsolódó vagy hasonló cikkeket, tartalmat, bejegyzéseket. Megmutatom az ingyenes bővítményt, és hogy milyen két előnye van ennek a lehetőségnek? + passzív jövedelem tipp!

WordPress gyorsítás

WordPress gyorsítás

Hogyan gyorsítsd a WordPress honlapodat? WordPress gyorsítás 7 egyszerű lépésben, amit szakértelem nélkül is el tudsz végezni!

Hozzászólások

8 Comments

8 hozzászólás

  1. Péter

    Én is jártam már így. Nagyon bosszantó tud lenni.
    Költöztetés megoldotta a problémát.
    Tudom ajánlani az interwox.com webtárhely szolgáltatót. Azóta szépen fut a honlapom. 🙂
    Sokakkal ellentétben hétvégén is készségesen segítenek, ha sürgős.

    https://interwox.com/

    Válasz
  2. Járomi Zoltán

    Köszi, még mindig működik ez a tipp. Ezer köszönet.

    Válasz
  3. kerdez

    Az is jó, hogy bizonyos szolgáltatók pénzt kérnek adatbázis futtatásáért. Ebből nem derül ki ez: Teljes mértékben támogatjuk a tartalom kezelő CMS rendszerket. Szervereink úgy vannak konfigurálva, hogy megkönnyítsék a CMS telepítését, használatát. SUPHP használatakor nem kell jogosultságokkal bajlódnia ez automatikus.Előretelepített alkalmazások is elérhetők a cpanelből, amit egy klikkel telepíthet. A szervereken 128Mb megosztott memóriát engedélyezünk, így az összes alkalmazást,kiegészítést futtathatja.
    Megrendeléshez töltse ki, írja alá a domain és tárhely igénylő dokumentumot és küldje vissza emailben szkennelve vagy faxon. Rendelhet, fizethet online is de a domain és tárhely igénylőt akkor is ki kell tölteni és visszaküldeni.

    Válasz
  4. Andrea

    Az az érdekes, hogy a külföldi szolgáltatóknál nincsenek ilyen gondok. A magyar szolgáltatóknál viszont alaposan meg kell nézni, melyiket válasszuk. Tudnak ám paranoid beállításokat kreálni. Én is futottam már bele bosszantó, időrabló érdekességekbe…

    Bár linux gurunak nem tartom magam, annak ellenére, hogy több, mint egy tucat éve ezt használom, azért válaszolok a cikkben feltett kérdésedre: igen, biztonsági kockázatot jelent a fájlok 755 jogosultsága.

    Linuxban a jogosultság így néz ki:
    Egy fájl (linuxban a könyvtár is fájlnak számít) rwx, azaz r(ead) – olvasható, w(rite) – írható, (e)x(ec) – futtatható (könyvtárnál beléphetsz). Az r értéke 4, a w 2, az x pedig 1. így a számok átfordítva annyit jelentenek:
    7: olvasható, írható, futtatható
    6: olvasható, írható
    5: olvasható, futtatható
    4: olvasható
    stb. a hozzá tartozó tulajdonos számára.

    Ehhez jönnek a tulajdonosi jogkörök. Sorrendben: tulajdonos, csoport, mindenki.
    Így a 3 szám sorrendben azt jelzi, hogy mit csinálhat a tulajdonos, a csoport, és mindenki más.
    Tehát:
    755 esetén: a fájl tulajdonosa olvas, ír, futtat, a csoport olvas és futtat és mindenki más is olvas és futtat.
    644 esetén a fájl tulajdonosa olvas és ír, a csoport és a többiek csak olvasnak.

    Nem hiszem, hogy érteni kellene bárkinek is a php fájlokhoz, a weboldal működéséhez, hogy rájöjjön, mit jelenthet, hogy egy tárhelyen egy-egy php fájlt bárki futtathat. Szerintem ahhoz sem kell nagy képzelő erő, hogy elképzeljük, mi lesz, ha egyszer esetleg feltörik a bejegyzésben említett tárhelyen ezt vagy más ott tárolt honlapot.

    Az, hogy egy tárhelyszolgáltató nem tud beállítani normálisan egy szervert, hogy a legnépszerűbb CMS-ek futtatási követelményeinek is megfeleljen a biztonság mellett – lehet bármit belemagyarázni -, de az az ő szegénységi bizonyítványa, hozzá nem értési tanúsítványa.

    Válasz
    • Szilágyi Balázs

      Köszönöm Andrea 🙂

      Külföldi szolgáltatónál én sem találkoztam ilyennel.

      Válasz
  5. Érczi László

    Hasznos cikk, köszi!!!
    Én a múltkor az admin felületemhez nem tudtam hozzáférni. Újjá kellet varázsolnom a config fájlt. Pedig nem nyúlt hozzá senki sem. X-akta. 🙂

    Válasz
  6. Attila

    Hálásan köszönöm ezt a cikket! Ugyanígy jártam én is tegnap, szintén nem saját weboldalamon! Természetesen ugyanennél a tárhely szolgáltatónál…..

    Köszi még 1x! 😀

    Válasz

Egy hozzászólás elküldése

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

Szilágyi Balázs webinar behúzó háttér

Hogyan keress te is pénzt otthonról ingyenes tréning

Íratkozz fel hírlevelünkre, és azonnal megnézheted a Hogyan keress te is pénzt otthonról online tréninget!

Adatkezelés

Sikeres jelentkezés. Hamarosan küldjük az információkat a tréninghez.