Valge ekraan. Viis numbrit: 500. Ei administraatoripaneeli, ei saiti, ei vihjet põhjusele. Tundub tuttav?

WordPressi sisemise serveri viga 500 on kõigist vigadest kõige vaiksem. See ei ütle sulle, mis täpselt katki läks, mis teeb paanika ainult hullemaks. Kuid tegelikkus on proosaline: 9 juhul 10st on süüdlaseks plugin, teema või üks vigane rida failis .htaccess. Server ei ole hulluks läinud; see lihtsalt puutus kokku koodiga, mida ei suudeta käivitada.

Vaatame läbi kolm peamist stsenaariumi ja parandame igaühe samm-sammult. Ei mingit paanikat, ei mingit helistamist oma hostiteenuse pakkujale kell kolm öösel. Oma kätega, 15 minutiga.

💡 Kiire ülevaade:

• Keela kõik pluginad korraga, nimetades FTP kaudu ümber kausta plugins; kui viga kaob, on süüdlane nende seas
• Lähtesta .htaccess standardsele WordPressi mallile: katkine vahemällu salvestamise või ümbersuunamise direktiiv võib su saidi hetkega rivist välja lüüa
• Luba WP_DEBUG failis wp-config.php, et näha täpset faili ja rida koos fataalse veaga
• Kui su sait just kolis uude hosti, kontrolli PHP versiooni: WordPress nõuab alates 2026. aastast PHP 8.3 või uuemat ning vanad pluginad on sageli mitteühilduvad

HTTP vastuskoodid: mida server sulle öelda üritab

Enne veaotsingusse sukeldumist on kasulik mõista HTTP vastuste põhitõdesid. Server vastab brauserile alati kolmekohalise koodiga ja esimene number ütleb sulle juba, kust viga otsida.

• 1xx, informatiivne: „ühendust luuakse, palun oota." Neil pole vigadega mingit pistmist.
• 2xx, edukas. Kuulus 200 OK tähendab, et server edastas lehe ilma probleemideta.
• 3xx, ümbersuunamised. Näiteks 301 (püsiv ümbersuunamine) või 307 (ajutine). Brauser liigub uuele aadressile vaikselt; see on käsk, mitte viga.
• 4xx, kliendipoolne viga. 404 Not Found tähendab, et leht on kustutatud või URL on valesti sisestatud. Server on elus; sisu lihtsalt ei eksisteeri.
• 5xx, serveripoolne viga. Siit algab meie territoorium.

5xx koodide seas on kolm peamist „patsienti": 503 Service Unavailable (server on üle koormatud; paranda vahemällu salvestamise või võimsama paketiga), 502 Bad Gateway (PHP-FPM jooksis kokku või kaotas ühenduse veebiserveriga; konfiguratsiooniprobleem) ja lõpuks **500 **Internal Server Error, kõige üldisem ja seetõttu kõige salakavalam. Sellest me räägimegi.

Kolm peamist vea 500 põhjust ja samm-sammulised lahendused

Viga 500 ei ole müstiline; see on lihtsalt üldine. Server ütleb: „Ma ei suutnud koodi käivitada, aga ma ei ütle sulle, millist." Diagnoosimine tähendab metoodilist läbi töötamist kolmest standardsest kahtlusalusest.

1. PHP versiooni mitteühilduvus saidi migreerimisel

Klassikaline stsenaarium: kolisid oma saidi vanalt hostilt, kus töötas PHP 7.4, uude, kus on PHP 8.3 või 8.4. Ja said kohe valge ekraani.

Põhjus on lihtne: vana plugin või teema kasutab funktsioone, mis on uuemates PHP versioonides aegunud või täielikult eemaldatud. Interpretaator keeldub neid käivitamast ja sait jookseb kokku.

Kuidas parandada. Tee täielik varukoopia kaustadest wp-content/plugins/ ja wp-content/themes/. Seejärel nimeta FTP või oma hostingu failihalduri kaudu kaust plugins ümber plugins_old; see keelab koheselt kõik pluginad korraga. Kas viga kadus? Süüdlane on pluginate seas. Taasta need ükshaaval, kontrollides iga kord saiti. See, mille järel viga 500 naaseb, ongi probleem.

Sama loogika kehtib teemade kohta: lülitu standardsele WordPressi teemale (Twenty Twenty-Five või uuem). Kas sait ärkas ellu? Probleem on sinu teemas; uuenda või asenda see.

See stsenaarium ilmneb kõige sagedamini saidi migreerimisel erinevate PHP versioonidega hostide vahel. Enamik hoste ei paku enam oma juhtpaneelides PHP 7.x ja WordPressi miinimumnõuded alates 2026. aastast algavad PHP 8.3-st. Vana kood ilma uuendusteta on selles keskkonnas hukule määratud.

2. Rikutud.htaccess, nähtamatu tapja

Seadistasid vahemällu salvestamise pluginat, lubasid ümbersuunamisi või lisasid oma reeglid faili .htaccess ja sait läks maas. Koheselt ja ilma hoiatuseta.

Fail .htaccess (Apache) juhib veebiserverit lennult: direktiiv kirjutatakse, direktiiv täidetakse. Üks süntaksiviga, vale lipp või reeglite konflikt ja kogu sait vastab 500-ga.

Kuidas parandada. Ühendu oma saidiga FTP kaudu või hostingu failihalduri kaudu. Leia .htaccess juurkaustast (public_html, www või htdocs). Kopeeri selle sisu tekstifaili varukoopiaks. Seejärel asenda kõik standardse WordPressi malliga:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

See kood taastab standardsed URL-i ümberkirjutamise reeglid (ilusad püsilinkimised) ja eemaldab kõik üleliigse. Sait peaks koheselt ellu ärkama. Seejärel saad oma pluginat uuesti seadistada, kuid nüüd tead, kust otsida, kui midagi valesti läheb.

Ei aidanud? Taasta vana .htaccess oma varukoopiast ja liigu järgmise sammu juurde. Nginxi puhul .htaccess ei tööta; kontrolli logisid asukohas /var/log/nginx/error.log, probleem on serveriploki konfiguratsioonis.

3. Fataalne viga PHP koodis

Plugin või teema kutsub välja funktsiooni, mida ei eksisteeri, edastab vale argumenditüübi või viitab olematule klassile. PHP peatab täitmise ja sa seisad silmitsi selle sama 500-ga.

Ilma silumisinfota on see pime pakkumine. Õnneks oskab WordPress vigu kuvada; sa pead lihtsalt silumisrežiimi lubama.

WP_DEBUG lubamine

Ava fail wp-config.php oma saidi juurkataloogis. Leia rida:

1
define( 'WP_DEBUG', false );

Asenda false väärtusega true. Kui seda rida ei eksisteeri, lisa see enne /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Pärast salvestamist värskenda lehte. Valge ekraani asemel näed teadet nagu:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

Viga näitab: probleemi tüüp (undefined function), vigane fail (wp-cache.php) ja rida (342). See on otsene viide pluginile, mis kokkujooksmise põhjustas. Keela see, nimetades plugina kausta ümber, ja sait hakkab uuesti tööle. Seejärel uuenda pluginat, leia asendus või võta ühendust arendajaga.

Pärast diagnoosimist sea WP_DEBUG kindlasti tagasi väärtusele false. Töötaval saidil pole vaja külastajatele vigu kuvada ja see võib paljastada sisemisi serveriteid. Kui soovid logisid koguda ilma neid ekraanil kuvamata, lisa faili wp-config.php need read: define( 'WP_DEBUG_LOG', true ); ja define( 'WP_DEBUG_DISPLAY', false );. Vead kirjutatakse faili wp-content/debug.log.

⁉️🤔 Korduma kippuvad küsimused

Kas ma võin vea 500 kõrvaldamiseks lihtsalt serveri taaskäivitada?

Ei. Erinevalt veast 503, mis sageli kaob pärast taaskäivitust (kui tippkoormus on leevenenud), on viga 500 põhjustatud probleemist koodis. Serveri taaskäivitamine seda ei paranda: pärast käivitumist puutub sait kokku sama katkise koodiga ja jookseb uuesti kokku.

Kuidas teha kindlaks, kas süüdi on plugin või teema, kui administraatoripaneel pole ligipääsetav?

Ühendu FTP kaudu või hostingu failihalduri kaudu. Nimeta ümber kaust wp-content/plugins; see keelab koheselt kõik pluginad. Kas sait ärkas ellu? Probleem on pluginates. Kui mitte, nimeta ümber aktiivse teema kaust kohas wp-content/themes. WordPress lülitub automaatselt vaiketeemale. Kas ärkas ellu? Probleem on teemas.

Kas ma pean WP_DEBUG töötaval saidil lubama?

Ei, töötaval saidil peaks WP_DEBUG olema keelatud (false). Luba see ainult diagnoosimise ajal ja lülita kohe pärast seda välja. Pidevaks vigade kogumiseks ilma neid külastajatele näitamata kasuta kombinatsiooni WP_DEBUG_LOG (kirjutab faili wp-content/debug.log) ja WP_DEBUG_DISPLAY (keelab ekraaniväljundi).

Mis siis, kui ükski kolmest meetodist ei aidanud?

Kontrolli PHP mälulimiiti (memory_limit failis php.ini). Mõnikord pole skriptidel piisavalt eraldatud megabaite ja need jooksevad kokku veaga 500. Suurenda seda 256M või 512M peale. Kui see ei aita, võta ühendust oma hostingu toega: palu neil kontrollida serveri vealogisid (error_log Apache'i/Nginxi jaoks). Täpne põhjus on seal, mida sa WordPressi poolelt ei näe.

Minu sait on Nginxil; mida ma.htaccessiga teen?

Nginx ei kasuta .htaccess-i. Ümberkirjutamise reeglid on määratud serveriploki konfiguratsioonis (nginx.conf või sites-available/your-site). Kui oled Nginxil ja said vea 500, kontrolli logisid asukohas /var/log/nginx/error.log. Vigane .htaccess Nginxi serveris probleeme ei põhjusta; seda lihtsalt ignoreeritakse.

Kuidas vältida viga 500 tulevikus?

Kolm reeglit ennetamiseks. Esiteks: uuenda pluginaid, teemasid ja WordPressi tuuma regulaarselt (iga kuu, mitte kord aastas). Teiseks: ära hoia mahajäetud laiendustest kinni; kui pluginat pole üle aasta uuendatud, otsi elus asendus. Kolmandaks: enne mis tahes plugina paigaldamist kontrolli WordPressi kataloogis plugina lehel viimase uuenduse kuupäeva ja ühilduvust oma PHP versiooniga. Kümme minutit hooldust kuus säästab tunde hädaolukorra silumist.

Mida kohe teha, kui su sait on veaga 500 maas

Viga 500 on mõistatus, millel on ennustatav lahendus. Enamikul juhtudel parandad saidi viieteistkümne minutiga, läbides kolm sammu õiges järjekorras: keela pluginad, lähtesta .htaccess, luba WP_DEBUG. Järjekord loeb: kõige tõenäolisemast ja kiiremast kuni kõige üksikasjalikumani.

Kui migreerisid saidi uude hosti, alusta PHP kontrollimisest. Kui seadistasid vahemällu salvestamist või ümbersuunamisi, alusta failist .htaccess. Kui uuendasid pluginaid ja sait jooksis kokku, alusta WP_DEBUG-st. Ja kui sa ei teinud midagi, kuid viga 500 tekkis iseenesest, läbi kõik kolm sammu järjest; üks neist peaaegu kindlasti töötab.

Ära viivita diagnoosimisega: iga minut saidi seisakuaega tähendab kaotatud külastajaid ja otsingureitinguid. Ava FTP, tee varukoopia ja asu tööle.