Valge ekraan. Viis tähemärki: 500 Internal Server Error. Sait on maas, klient saadab sulle sõnumeid ja sul pole õrna aimugi, kust alustada.

500 viga on kõige frustreerivam HTTP staatuskood. Erinevalt 404-st („lehte ei leitud") või 403-st („juurdepääs keelatud") ei nimeta see süüdlast. See lihtsalt ütleb, et „serveris läks midagi valesti". Seejärel oled omapäi: plugin, teema, vigane PHP, majutus, rikutud .htaccess. Võimalusi on kümneid ja igaüks nõuab erinevat parandust.

Hea uudis: 500 viga on alati parandatav. Ilma paanikata, ilma WordPressi nullist uuesti installimata ja enamikul juhtudel ilma arendajata. Seitsme sammuga (alates 30-sekundilisest diagnostikast kuni süsteemifailide kirurgilise asendamiseni) leiad põhjuse ja tood oma saidi taas töökorda. Iga meetod sisaldab konkreetseid faile, koodiridu ja ekraanipilte.

💡 Kiirülevaade:

• 1. samm: luba WP_DEBUG ja loe logisid, et kohe näha, milline fail on süüdi
• 2. samm: välista majutusega seotud probleemid, samal ajal kui koodi uurid
• 3. samm: paranda .htaccess, mis on tugistatistika järgi peamine põhjus
• 4. samm: tõsta PHP mälulimiiti, mis on sage süüdlane meedia üleslaadimisel või administraatorisse sisselogimisel
• 5. samm: laadi WordPressi tuum uuesti üles, kui failid on automaatse uuenduse tõrke tõttu rikutud
• 6. samm: keela pluginad FTP kaudu, meetod, mis lahendab üle poole kõigist juhtumitest
• 7. samm: lähtesta vaiketeemale, samm, mis sageli tähelepanuta jäetakse

Mis on 500 viga ja kust see tuleb

HTTP 500 on serveri vastus, mis tähendab „sisemist viga". Brauseri päring saabus, Apache või Nginx võttis selle vastu, PHP hakkas tööle ja siis komistas. Erinevalt 404-st või 403-st (kus server vastab teadlikult „ei") tähendab number viis koodi alguses, et skripti sees läks midagi katki ja server ei tea, mis.

WordPressis esineb 500 viga neljas tüüpilises olukorras:

• Paigaldasid või uuendasid pluginat ja see läheb vastuollu süsteemi muu koodiga.
• Muutsid .htaccess faili ja süntaksiviga jooksis Apache kokku.
• PHP skript ammendas oma eraldatud mälu (valge ekraan ja logis Allowed memory size of X bytes exhausted).
• Tuumafailid on rikutud: automaatse uuenduse tõrge, katkenud FTP ülekanne, tõrkuv plugin, mis rikkus süsteemikaustu.

Harvemini: teema, mille functions.php failis on fataalne viga, majutuse poole probleemid (ülekoormus, keelatud PHP moodul) või katkine lühikood eemaldatud pluginast lehe sisus.

Enne alustamist: tee oma saidist täielik varukoopia. Ilma varukoopiata on iga toiming serverifailidega riskantne. Enamik majutusteenuseid pakub juhtpaneelil (cPanel, ISPmanager, aaPanel) varundusnuppu, mis nõuab vaid paari klõpsu.

1. Luba WP_DEBUG ja loe logisid

Kiireim viis põhjuse leidmiseks on lasta WordPressil see avaldada. Vaikimisi peidab tuum PHP vead valge ekraani taha (see on režiim „ära hirmuta külastajaid"). Kuid WordPressil on sisseehitatud silumismehhanism: WP_DEBUG konstandid.

Silumisrežiimi lubamine

Ava wp-config.php oma saidi juurkaustas FTP või majutusteenuse failihalduri kaudu. Leia see rida:

1
/* That's all, stop editing! Happy blogging. */

Enne seda lisa see plokk:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Mis siin toimub:

• WP_DEBUG on peamine lüliti; ilma true väärtuseta teised konstandid ei tööta.
• WP_DEBUG_LOG suunab kõik vead faili wp-content/debug.log, mitte ekraanile. Külastajad ei näe hirmutavaid teateid.
• WP_DEBUG_DISPLAY + @ini_set peidab vead jõuga lehe väljundist.

Salvesta fail, värskenda oma saidil probleemset lehte ja laadi FTP kaudu alla wp-content/debug.log. Logis näed konkreetset faili ja rida: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Keela silumine pärast diagnostikat. Kommenteeri välja või kustuta lisatud read. WP_DEBUG töötaval saidil aeglustab jõudlust ja debug.log võib aja jooksul gigabaitideks paisuda.

2. Võta ühendust oma majutusteenuse pakkujaga

Kui logid on tühjad või neid ei loodud, võib viga olla serveri poolel, mitte WordPressi koodis. See on eriti levinud odavate jagatud majutusplaanide puhul, kus on ranged protsessipiirangud.

Ava tugipilet ja lisa kolm asja:

• Täpne aeg, millal viga ilmnes, koos serveri ajavööndiga.
• Selle lehe URL, kus viga esineb.
• Vea ekraanipilt, kui see on saadaval.

Tugi kontrollib Apache või Nginxi serveri logisid, protsessori ja mälu koormust ning saadaolevaid PHP mooduleid. Probleemid lahenevad sageli selles etapis: hosti administraator taaskäivitab PHP-FPM-i või kohandab protsessipiirangut.

Kuidas aru saada, kummal poolel probleem on

Loo fail nimega info.php üheainsa reaga:

1
<?php phpinfo(); ?>

Laadi see FTP kaudu oma saidi juurkausta ja ava your-site.com/info.php. Kui näed tabelit PHP parameetritega, siis server töötab ja viga on WordPressi koodis. Kui näed 500 viga, on viga serveri tasemel; anna see URL tugiteenindusele.

Pärast testi **kustuta **info.php. phpinfo() paljastab serveri versioonid, teed ja moodulid, tekitades turvaaugu.

3. Paranda.htaccess fail

.htaccess on Apache konfiguratsioonifail sinu saidi juurkaustas. WordPress kasutab seda inimloetavate URL-ide, ümbersuunamiste ja põhiliste turvareeglite jaoks. Üks lisasulg, reeglite konflikt kahe plugina vahel ja kogu sait on 500 veaga maas. Tugipiletite statistika kohaselt osutub .htaccess peamiseks põhjuseks.

Kiirkontroll: nimeta .htaccess FTP kaudu ümber .htaccess_old failiks ja värskenda saiti. Kui see töötab, on probleem kindlasti selles failis.

Nüüd taasta .htaccess: mine WordPressi administraatorisse, Seaded → Püsilingid ja klõpsa „Salvesta muudatused" ilma struktuuri muutmata. WordPress genereerib uue puhta .htaccess faili standardsete reeglitega:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Kui sul olid .htaccess failis kohandatud reeglid (ümbersuunamised, vahemälu, turvalisus), lisa need ükshaaval tagasi ja kontrolli pärast iga lisamist saiti. Nii tuvastad saatusliku rea.

4. Suurenda PHP mälulimiiti

WordPressi PHP skriptid vajavad RAM-i. Kui plugin või teema küsib rohkem kui eraldatud, jookseb skript kokku. Tulemus: 500 viga või valge leht teatega Allowed memory size of X bytes exhausted.

Paljude hostide standardlimiit on endiselt 64 MB. Kaasaegse WordPressi saidi jaoks, kus on kümmekond pluginat, on see katastroofiliselt vähe. Soovitatav miinimum on 256 MB.

Meetod 1: wp-config.php kaudu (eelistatud)

Lisa see wp-config.php faili enne rida /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

See konstant tühistab PHP limiidi saidi esiosas. Administraatori ala jaoks tõstab WordPress automaatselt ülempiiri väärtuseni WP_MAX_MEMORY_LIMIT (vaikimisi 256 MB).

Meetod 2: php.ini kaudu (kui su host ei võimalda wp-config faili muuta)

Loo php.ini fail järgmise sisuga:

1
memory_limit = 256M

Laadi see üles saidi juurkausta ja wp-admin/ kausta. Kui see ei aita, loo või muuda .user.ini faili saidi juurkaustas sama reaga.

Kui kumbki meetod ei tööta, piirab su hostingu pakett füüsiliselt mälu. On aeg uuendada paketti või vahetada hosti.

5. Laadi WordPressi tuumikfailid uuesti üles

Rikutud tuumikfail on harv, kuid salakaval põhjus. Automaatse uuenduse tõrge, katkenud FTP-ülekanne, süsteemifaile muutnud plugin ning wp-admin või wp-includes sisaldab prügi.

Toiming:

• Laadi wordpress.org lehelt alla värske WordPressi ZIP-arhiiv.
• Paki arhiiv oma arvutis lahti.
• Mine FTP kaudu oma saidi juurkataloogi ja kustuta kaustad wp-admin ja wp-includes (ainult need kaks; ära puuduta wp-content!).
• Laadi värskest arhiivist üles kaustad wp-admin ja wp-includes.
• Ära kirjuta üle wp-content; seal asuvad sinu teemad, pluginad ja üleslaaditud failid.

Juurkataloogi faile (wp-settings.php, index.php ja teised) saab samuti asendada arhiivist pärit värskete failidega. **Välja arvatud **wp-config.php; ära seda puuduta, sest see sisaldab sinu andmebaasi ühendusandmeid. Pärast asendamist värskenda saiti; viga kaob, kui põhjuseks olid rikutud süsteemifailid.

6. Keela pluginad

Tõrget põhjustav plugin on 500 vea kõige tõenäolisem põhjus. Uuendasid mitut pluginat korraga ja üks läks teisega vastuollu: tere, valge ekraan.

Kui administraatori ala töötab

Mine Pluginad → vali kõik → ühismeede „Deaktiveeri" → „Rakenda". Kui viga kaob, luba pluginad ükshaaval, värskendades saiti pärast igaüht. Kui leiad süüdlase, kustuta see või teata probleemist arendajale.

Kui administraatori ala pole ligipääsetav

Ühendu FTP kaudu serveriga ja nimeta kaust wp-content/plugins ümber plugins_off. WordPress lõpetab kõigi pluginate laadimise ja sait ärkab uuesti ellu. Taasta kausta algne nimi ja nimeta pluginate alamkaustad ükshaaval ümber; nii leiad probleemse plugina administraatorisse sisenemata.

Mida jälgida: vahemällu salvestamise pluginad (W3 Total Cache, WP Rocket) kirjutavad mõnikord oma reeglid failidesse .htaccess ja wp-config.php. Pärast sellise plugina deaktiveerimist võib viga püsida; kontrolli neid faile ja eemalda read markerite nagu # BEGIN W3TC ja # END W3TC või sarnaste vahelt.

7. Lülitu vaiketeemale

Aktiivne teema on alahinnatud, kuid reaalne 500 vigade allikas. Eriti kui lisasid faili functions.php koodijupi saatusliku veaga.

Kontroll on lihtne: nimeta FTP kaudu aktiivse teema kaust wp-content/themes/ sees ümber (näiteks mytheme → _mytheme). WordPress tuvastab, et aktiivne teema puudub, ja lülitub automaatselt standardsele: Twenty Twenty-Five või mõni muu süsteemi installitud vaiketeema.

Kui sait töötab vaiketeemaga, on probleem sinu teemas. Taasta teema algne nimi, ava functions.php ja otsi kohandatud koodist vigu. Kui sa ei lisanud koodi ise, võta ühendust teema arendajaga.

⁉️🤔 Korduma kippuvad küsimused

Mida teha, kui 500 viga ilmneb ainult administraatorisse sisselogimisel?

Tõenäoliselt ei piisa PHP mälulimiidist just administraatori paneeli jaoks, mis laadib kõik pluginad korraga ja on esiosast raskem. Lisa faili wp-config.php rida define( 'WP_MAX_MEMORY_LIMIT', '512M' );; see on eraldi limiit administraatorile, kõrgem kui esiosa WP_MEMORY_LIMIT. Kontrolli ka oma pluginate kausta: meie kogemuse kohaselt on kõige sagedasemad süüdlased turvapluginad nagu Wordfence või varunduspluginad, mis tarbivad administraatori riba laadimisel mälu. Keela need FTP kaudu (kaust plugins_off sammust 6) ja kontrolli.

Kas ma saan 500 vea parandada ilma FTP-juurdepääsuta?

Jah. Enamik hostinguid pakub juhtpaneelis failihaldurit: cPanel → File Manager, ISPmanager → Failid. Selle kaudu saad ümber nimetada .htaccess, pluginate ja teemade kaustad ning muuta wp-config.php; kõik sammud on samad. Ilma igasuguse failidele juurdepääsuta on ainus võimalus hostingu tugimeeskond. Pro-nipp: kui sul on installitud koodijuppide plugin (Code Snippets, WPCode) ja sinu viimane tegevus oli koodijupi lisamine, proovi avada your-site.com/?code_snippets_safe_mode=1 või sarnane oma plugina turvarežiimi URL. See keelab kõik koodijupid ilma FTP-ta.

500 viga ilmneb ainult ühel lehel. Mis on põhjus?

Katkine funktsioon või otsetee selle konkreetse lehe sisus. Ava leht WordPressi redaktoris (kui administraator töötab) ja eemalda ajutiselt kõik otseteed, Gutenbergi plokid ja koodimanused. Kui administraator pole ligipääsetav, leia postitus andmebaasist phpMyAdmini kaudu (tabel wp_posts), kopeeri sisu tekstiredaktorisse ja eemalda kahtlased otseteed. Kõige sagedasemad süüdlased: kustutatud pluginatest pärit otseteed ([dead_plugin] on alles, kuid plugin on läinud), katkine PHP sisuplokkides või valesti pesastatud Gutenbergi plokid.

Pärast taastamist naaseb 500 viga mõne tunni pärast. Kuidas põhjust leida?

Tsükliline viga intervalliga on peaaegu alati üks kolmest stsenaariumist: WordPressi cron-ülesanne käivitab ajakava järgi katkise protsessi, vahemällu salvestamise plugin genereerib rikutud vahemälu või hostingu protsessilimiidid saavad perioodiliselt pihta (eriti odavate jagatud pakettide puhul). Installi WP Crontrol ja kontrolli cron-ülesannete nimekirja; leia see, mis langeb kokku kokkujooksmise ajaga. Tühjenda oma vahemällu salvestamise plugina vahemälu. Küsi oma hostingu pakkujalt Entry Processes või PHP Workers limiidi kohta; jagatud pakettidel on need sageli kärbitud 5-10 peale ja liikluse hüpe viib saidi rivist välja.

Kas ma pean läbima kõik 7 sammu või võin mõne vahele jätta?

Esimesed kaks sammu (WP_DEBUG ja hosting) on diagnostilised: need ei lõhu midagi ja annavad teavet. Meie WordPressi saitide toe kogemuse põhjal lahendavad samm 3 (.htaccess) ja samm 6 (pluginad) valdava enamuse juhtumeid. Ülejäänud taanduvad PHP mälule, rikutud tuumikule ja teemale. Tüüpilises olukorras lahendad probleemi sammude 3 või 6 juures, ilma et peaksid kogu ahelat läbima.

Kust kohe alustada

Ära korda tüüpilist stsenaariumi: paanika → kustuta kõike suvaliselt → tee olukord hullemaks. Järgi järjekorda diagnoosist paranduseni:

WordPressi remondi peamine reegel: üks tegevus, üks kontroll. Ära kunagi tee kahte parandust korraga; sa ei tea, kumb toimis. Ja kirjuta täpselt üles, milline plugin või muudatus vea põhjustas. Järgmisel korral parandad kõik 30 sekundiga.