WordPress tukša lapa vai kritiska kļūda: vispirms izlasiet kļūdas ziņojumu

«Kritiska kļūda» vai tukša lapa: viena un tā pati kļūme

Tukša lapa visbiežāk ir PHP fatāla kļūda: kāds vietnes fails pieprasīja kaut ko neiespējamu, un izpilde apstājās, pirms kaut kas tika parādīts. Kopš WordPress 5.2 WordPress šīs kļūdas pārtver: tukšas lapas vietā tas parāda «Jūsu vietnē ir radusies kritiska kļūda.» un nosūta e-pastu uz vietnes administrācijas e-pasta adresi.

Lapa paliek pilnīgi balta dažos gadījumos: vecāka WordPress versija, kļūda, kas rodas pirms šī mehānisma ielādes, konstante WP_DISABLE_FATAL_ERROR_HANDLER ar vērtību true vai kešatmiņas spraudnis, kas rāda kļūmes laikā saglabātu tukšu lapu. Tālāk aprakstītā metode der visiem šiem gadījumiem.

Trīs darbības var pagaidīt, līdz kļūda ir izlasīta: WordPress pārinstalēšana, spraudņu dzēšana, vecas rezerves kopijas atjaunošana. Katra no tām var izdzēst iestatījumus vai nesenus datus, turpretī kļūdas ziņojums parasti pasaka, kuru komponentu deaktivizēt, neko nezaudējot.

Īsākais ceļš: atkopšanas režīms

Kad WordPress kļūdu pārtver, tas uz vietnes administrācijas e-pasta adresi nosūta ziņojumu ar tematu «[Vietnes nosaukums] Jūsu vietnē radusies tehniska problēma». Tas nosauc vainīgo spraudni vai tēmu un satur saiti, kas atver administrācijas paneli atkopšanas režīmā.

• Šajā režīmā vainīgais komponents ir apturēts tikai jums: jūsu apmeklētāji joprojām redz kļūdu.
• Sadaļā Spraudņi vai Izskats > Tēmas deaktivizējiet norādīto komponentu un pēc tam administrēšanas joslā noklikšķiniet uz «Iziet no atkopšanas režīma».
• Saite ir derīga 24 stundas, un WordPress sūta ne vairāk kā vienu šādu e-pastu dienā. Ja e-pasts nepienāk, ieskatieties mēstuļu mapē un pēc tam pārejiet pie nākamās metodes.

Izlasīt kļūdu: atkļūdošanas žurnāls

Pieslēdzieties vietnei ar SFTP vai caur hostinga pakalpojumu sniedzēja failu pārvaldnieku, atveriet wp-config.php saknes mapē un aizstājiet rindu define( 'WP_DEBUG', false ); ar šīm četrām rindām:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Tās novieto virs komentāra, kas noslēdz faila rediģējamo daļu (/* That's all, stop editing! Happy publishing. */, angliski arī latviešu valodas WordPress instalācijā). Pārlādējiet lapu ar kļūdu un pēc tam atveriet wp-content/debug.log. WP_DEBUG_DISPLAY ar vērtību false patur ziņojumus failā, ārpus lapas, ko redz jūsu apmeklētāji.

Ja debug.log paliek tukšs vai neparādās, kļūdu ir reģistrējis pats PHP: meklējiet failu error_log vietnes saknes mapē vai mapē wp-admin, vai kļūdu žurnālu sadaļu hostinga vadības panelī.

Ko saka ziņojums un kāda darbība tam atbilst

Fatāla kļūda ietilpst vienā rindā: kļūdas veids, tās apraksts, pēc tam in un pilns faila ceļš ar rindas numuru. Ceļš ir visnoderīgākā informācija: wp-content/plugins/nosaukums/ norāda uz spraudni, wp-content/themes/nosaukums/ uz tēmu.

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

Deaktivizēt vainīgo komponentu bez administrācijas paneļa

Ar SFTP vai failu pārvaldnieku

Pārdēvējiet ziņojumā minētā spraudņa mapi, piemēram, wp-content/plugins/spraudna-nosaukums par spraudna-nosaukums.off. WordPress spraudni vairs neatrod un pārstāj to ielādēt; tā iestatījumi paliek saglabāti datubāzē, un WordPress to deaktivizē, nākamreiz atverot spraudņu ekrānu.

Tēmas gadījumā tās mapes pārdēvēšana mapē wp-content/themes atkal padara pieejamu administrācijas paneli, taču apmeklētāji redz tukšu lapu, kamēr neviena tēma nav aktīva. Tūlīt atveriet Izskats > Tēmas: WordPress konstatē, ka aktīvā tēma ir bojāta, un atgriežas pie instalētas noklusējuma tēmas.

Ar WP-CLI

wp plugin list --status=active
wp plugin deactivate spraudna-nosaukums
wp theme list
wp theme activate twentytwentyfive

Pirmā komanda saglabā aktīvo spraudņu sarakstu, kas noder pirms jebkādas grupveida deaktivizēšanas. Ja WP-CLI pats apstājas pie kļūdas, pievienojiet komandai --skip-plugins --skip-themes: tad tas startē, neielādējot spraudņus un tēmu. Mapes wp-content/mu-plugins spraudņi ielādējas jebkurā gadījumā; ja kļūda nāk no kāda no tiem, pārdēvējiet tā failu.

Ja ziņojums nenorāda uz konkrētu komponentu, wp plugin deactivate --all deaktivizē visus spraudņus. Ja vietne atgriežas, aktivizējiet tos pa vienam, starp katru pārlādējot vietni: pēdējais aktivizētais pirms kļūdas atgriešanās ir vainīgais.

Kad vietne atkal darbojas

1. Atjaunojiet define( 'WP_DEBUG', false ); un noņemiet WP_DEBUG_LOG no wp-config.php.
2. Dzēsiet wp-content/debug.log: tas atrodas no tīmekļa pieejamā mapē, to var izlasīt jebkurš, un tajā ir servera ceļi.
3. Atjauniniet vai aizstājiet vainīgo komponentu, iepriekš izlasot tā izmaiņu žurnālu.
4. Iztīriet kešatmiņas spraudņa kešatmiņu un hostinga pakalpojumu sniedzēja kešatmiņu, ja tāda ir.
5. Nākamajai reizei: pārbaudiet atjauninājumus vietnes kopijā, pirms tos piemērojat tiešsaistē.