La schermata bianca della morte di WordPress: una guida al recupero
Pubblicato: 2023-01-10WordPress, come MacOS e persino Windows ora, ha un famigerato "schermo bianco della morte" o "WSOD" in breve. Il WSOD appare quando qualcosa va storto. Ti trovi di fronte a uno schermo bianco vuoto o quasi vuoto per ragioni sconosciute. E adesso?
Che cos'è la schermata bianca della morte di WordPress (WSOD)?
È improbabile che incontri la "schermata bianca della morte" (WSOD) su un sito WordPress in condizioni normali. È semplicemente uno schermo bianco vuoto che appare al posto dell'interfaccia front-end o back-end pubblica di un sito WordPress. Significa che WordPress è andato in crash e non si carica correttamente.
Lo schermo bianco della morte è probabilmente il risultato di qualcosa TU hai fatto al tuo sito WordPress.
Come mai? Cosa è andato storto?
Da quando WordPress 5.2 è stato rilasciato a maggio 2019, WordPress dispone di una modalità di ripristino per proteggerti dal WSOD. Senza la modalità di ripristino, i problemi di compatibilità genererebbero molti WSOD e utenti WordPress frustrati. Se il tuo server utilizza una versione di PHP o MySQL che non è supportata da un plug-in, un tema o un'estensione che stai installando, invece di interrompere il tuo sito otterrai la modalità di ripristino. Oggi, un errore PHP Out-of-Memory (OOM) è probabilmente lo scenario rimanente più comune che aggirerà la protezione WSOD, lasciandoti con uno schermo completamente vuoto.
Ho verificato con il core contributor di WordPress Marius Jensen per scoprire cos'altro potrebbe causare un vero WSOD al giorno d'oggi. Marius è l'autore del plug-in Site Health (ora Health Check and Troubleshooting) il cui concetto e funzionalità alla fine sono entrati nel core di WordPress. (È così che abbiamo ottenuto la modalità di ripristino e altre protezioni.) Marius ha confermato che l'unico modo per far arrestare WordPress con uno schermo completamente vuoto è interrompere il flusso di esecuzione di PHP in modo che il gestore degli errori fatali non possa funzionare come dovrebbe. L'interruzione della connessione tra PHP e il tuo server HTTP lo raggiungerà. Non riceverai alcun feedback sulla risoluzione dei problemi sullo schermo. Sarebbe frustrante, ma se lavori semplicemente all'interno di WordPress, installando e configurando plugin, è improbabile che ciò accada.
La schermata bianca della morte significa che WordPress è stato violato?
No, un WSOD non significa che i cattivi ti abbiano preso. Tuttavia, in rari casi, potrebbe essere un effetto collaterale di una violazione della sicurezza. Se pensi che gli hacker abbiano compromesso il tuo sito, vai alla guida di Kathy Zant, Come pulire un sito WordPress compromesso.
Un errore di codifica PHP, un conflitto tra due o più plug-in o un problema nell'ambiente del server sono le cause più probabili di un WSOD. Fortunatamente, queste non sono catastrofi! Il tuo sito e il suo contenuto non sono andati perduti. Se lo desideri, puoi correggere tu stesso un WSOD.
In questo articolo, scenderemo nell'elenco delle possibili diagnosi e cure per il WSOD. Imparerai come riportare in vita il tuo sito WordPress. Imparerai anche come funziona WordPress a un livello più profondo.
Visualizza anteprima
La schermata bianca della morte di WordPress: l'ho fatto io?
Sì. Lo schermo bianco della morte è probabilmente il risultato di qualcosa TU hai fatto al tuo sito WordPress.
La causa di un WSOD si trova solitamente in un plugin di WordPress che hai appena installato e attivato. Oppure potrebbe essere il risultato di un recente aggiornamento. Un plug-in appena aggiunto o aggiornato potrebbe essere in conflitto con un altro plug-in. In questo scenario, un plug-in sta cercando di fare la stessa cosa di un altro o sta agendo per scopi contraddittori.
Se un plug-in, un tema o frammenti di codice PHP malfunzionanti stanno causando un errore irreversibile, potresti ricevere un WSOD. Potrebbero contenere un errore di sintassi, un bug o un codice non compatibile con la versione PHP che stai utilizzando. Se tu o il tuo host avete appena aggiornato la vostra versione di PHP, il che è positivo! — i plug-in incompatibili inizieranno a generare errori e potrebbero far crollare il tuo sito con un WSOD. Se stai utilizzando WordPress 5.2 o versioni successive come dovresti, i problemi di incompatibilità attiveranno la modalità di ripristino, che è molto più utile di un vero WSOD.
In genere il colpevole è tutto ciò che è stato appena modificato con un plug-in, un tema o un codice personalizzato.
Dal momento che il WSOD è spesso una risposta a qualsiasi cosa sia stata modificata l'ultima volta (o molto recentemente) che influisce sulla funzionalità del tuo sito. Esamina tutte le modifiche recenti. Concentrati sui cambiamenti che sembrano più probabili causare un problema. Se hai appena installato un nuovo plug-in o modificato il codice del tema, questi sono i primi posti in cui guardare per vedere cosa potrebbe essere andato storto.
Quando WordPress è solo per lo più morto
Tutti i WSOD non sono uguali e alcuni non sono nemmeno veri WSOD.
Potresti ricevere qualche tipo di messaggio di errore invece di uno schermo completamente bianco. Potrebbe trattarsi di un messaggio di errore del server relativo a un errore HTTP 500 o a una connessione al database persa. Potrebbe trattarsi di un messaggio di errore critico di WordPress. Oppure, il tuo sito potrebbe caricarsi normalmente per i visitatori, ma quando provi ad accedere, ottieni lo schermo bianco della morte. In altri casi potrebbe essere vero il contrario: puoi accedere alla dashboard di WordPress, ma il front-end del tuo sito rivolto al pubblico sta dando a tutti uno schermo vuoto.
Se la tua esperienza WSOD rientra in una di queste descrizioni, buone notizie! Il tuo sito è solo per lo più morto. Non sarà difficile rianimarlo.
Se ti ritrovi di fronte a uno schermo bianco completamente vuoto quando visiti il tuo sito WordPress o provi ad accedere, questo è il vero WSOD. Dovrai scavare un po' più a fondo per determinare cosa lo sta causando.
La modalità di ripristino di WordPress e la schermata bianca della morte
Fortunatamente per chiunque si trovi di fronte a un WSOD, la modalità di recupero è stata introdotta in WordPress 5.2 per farla finita. La modalità di ripristino rileva molti errori fatali e ti aiuta a risolverli. Se non stai utilizzando la versione principale più recente del core di WordPress, inizia da lì. Tieniti aggiornato!
Grazie alla modalità di ripristino di WordPress, è raro vedere uno schermo bianco completamente vuoto quando qualcosa va storto. Vedrai più spesso una finestra bianca su uno schermo grigio con il seguente messaggio a partire da WordPress 6.1:
Le versioni precedenti di WordPress mostreranno messaggi con parole simili come "Il sito sta riscontrando difficoltà tecniche".
Se accedi a un URL di backend /wp-admin , verrà visualizzato anche un avviso che ti dice di controllare il tuo account e-mail di amministratore per ulteriori informazioni:
In altri casi, potresti vedere una schermata bianca con testo in grassetto che descrive un "Errore interno del server" con qualche tipo di spiegazione e guida per riparare il tuo sito.
Benvenuti in Recupero
Questa è la modalità di recupero. WordPress sta cercando di aiutarti a rimetterlo in piedi.
La prima cosa da fare è controllare l'indirizzo email associato al tuo account amministratore di WordPress. WordPress cerca di identificare errori PHP fatali in tutto il codice che sta eseguendo.
Se possibile, WordPress "metterà in pausa" un plug-in o altro codice che non funziona correttamente. WordPress impedirà l'esecuzione del codice errato. Quindi riporterà i dettagli agli amministratori tramite e-mail.
Nell'e-mail della modalità di ripristino troverai le istruzioni e un collegamento temporaneo per accedere a WordPress in modalità di ripristino. (Questo collegamento è valido per 24 ore. Dopodiché, ne verrà inviato uno nuovo se il sito continua a riscontrare un errore critico.)
SUGGERIMENTO PRO: Se non ricevi l'e-mail della modalità di ripristino, puoi comunque accedere a WordPress in modalità di ripristino aggiungendo il seguente indirizzo all'URL del tuo sito di base quando accedi come amministratore: /wp-login.php?action=entered_recovery_mode .
Ecco la tua opportunità per indagare ulteriormente. Se la modalità di ripristino ha identificato un plug-in specifico come causa del tuo WSOD, disattivalo. Questo ripristinerà il tuo sito per tutti. Quindi puoi esaminare eventuali problemi noti per questo plug-in. Controlla se c'è un aggiornamento per questo. Contatta le persone responsabili della sua manutenzione.
Non tutte le schermate bianche della morte sono uguali su WordPress
In alcuni casi eccezionali, qualcosa è andato storto altrove in WordPress o nel tuo ambiente server. Un processo di aggiornamento o installazione potrebbe essersi bloccato, lasciando il tuo sito bloccato in modalità di manutenzione. Tu, il tuo provider di hosting o un plug-in che hai installato potresti aver modificato i file php.ini o .htaccess con risultati imprevisti. L'ambiente esistente potrebbe non supportare i requisiti di un plug-in appena installato.
La modalità di ripristino di WordPress non è in grado di far fronte a queste situazioni, ma produrrà messaggi di errore visibili su uno schermo altrimenti bianco. Il front-end del tuo sito potrebbe essere inaccessibile, ma la schermata di accesso dell'amministratore e l'interfaccia di back-end potrebbero funzionare normalmente.
Queste non sono vere situazioni WSOD, ma sono altrettanto fastidiose. Di solito, una delle seguenti condizioni li causa:
1. Sei bloccato in modalità manutenzione
Durante l'aggiornamento del core, dei plugin o dei temi di WordPress, WordPress entra in "Modalità di manutenzione". La navigazione in qualsiasi parte del sito mostrerà una schermata grigia con una finestra di messaggio bianca che dice:
A volte questo non si risolve in un minuto, ma l'hosting WordPress gestito dalla qualità lo noterà e lo risolverà con un processo automatizzato. Se hai aspettato qualche minuto senza apportare modifiche, puoi uscire dalla modalità di manutenzione eliminando il file .maintenance nella cartella principale web/applicazione in cui è installato WordPress. (Per vederlo, potrebbe essere necessario abilitare la visualizzazione di file "invisibili" con un punto nel nome del file.)
Quando non è presente alcun file .maintenance , il tuo sito verrà caricato come previsto.
2. Hai raggiunto un limite di caricamento file o dimensione post
Il tuo sito potrebbe andare in timeout su una schermata bianca in un processo di caricamento, post-pubblicazione o invio di moduli perché stai inviando troppi dati.
Soluzione: aumentare il limite del contenuto del post in wp-config.php :
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000); Soluzione: aumentare il caricamento del file e il limite di dimensione del post in php.ini :
upload_max_filesize = 256M post_max_size = 256M
Anche l'estensione del tempo (in secondi) prima della scadenza di un post o di qualsiasi modulo di invio può essere d'aiuto. È anche possibile aumentare il tempo che PHP ha per eseguire gli script e analizzare l'input. Inoltre, possiamo aumentare il numero di variabili consentite nell'invio di un modulo. Infine, possiamo specificare il limite di tempo dopo il quale PHP tratterà i dati inviati come spazzatura:
max_execution_time = 300 max_input_time = 300 max_input_vars = 1000 session.gc_maxlifetime = 1000
O in .htaccess , httpd.conf o virtualhost :
php_value upload_max_filesize 256 MB php_value post_max_size 256M php_value max_execution_time 300 php_value max_input_time 300 php_value max_input_vars 1000 php_value session.gc_maxlifetime 1000
Oppure in uno snippet di codice personalizzato per WordPress o in un file functions.php del tema:
@ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'tempo_max_esecuzione', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );I valori di memoria e tempo in questi parametri sono solo consigli. Per assicurarti che funzionino e per controllare i loro valori correnti, utilizza lo strumento Site Health nell'interfaccia di amministrazione di WordPress.
Insieme alla modalità di ripristino, WordPress 5.2 ha introdotto lo strumento Site Health. È molto utile per diagnosticare problemi e ottenere informazioni tecniche sulle impostazioni del sito e sull'ambiente del server. Puoi trovarlo nel menu di amministrazione in Strumenti > Stato del sito. Puoi anche beneficiare delle funzionalità estese del plug-in Health Check and Troubleshooting per WordPress.
3. PHP ha esaurito la memoria
PHP è il linguaggio di scripting lato server su cui si basa il core di WordPress. Viene visualizzato un WSOD se non c'è memoria sufficiente per PHP per eseguire WordPress e i plugin attivi. Potresti vederlo indicato in un messaggio di errore o in un registro.
A seconda del tuo piano di hosting, potresti essere in grado di aumentare il limite di memoria PHP per tutte le applicazioni sul tuo server o una specifica istanza di WordPress. Chiedi aiuto al team di supporto tecnico del tuo host se non sei sicuro di cosa fare.
wp-config.php
Normalmente, l'aggiunta della seguente impostazione al file wp-config.php nella cartella di WordPress imposterà il limite di memoria front-end per WordPress a 256 MB in questo esempio:
define('WP_MEMORY_LIMIT', '256M'); Da 128 a 256 MB dovrebbero essere più che adeguati. Potresti anche essere in grado di definire la memoria massima o di back-end allocata a PHP (256 MB anche nel prossimo esempio) aggiungendo anche la seguente riga a wp-config.php :
define('WP_MAX_MEMORY_LIMIT', '256M');Il secondo numero è il limite massimo di memoria che definisce la memoria totale che PHP ha a sua disposizione. Il primo numero è la memoria per WordPress in esecuzione entro quel limite PHP più ampio. Il limite massimo di memoria PHP deve essere uguale o superiore al limite di memoria dell'applicazione WordPress.
php.ini
Un altro modo per definire il limite massimo di memoria PHP è con un'impostazione in un file php.ini che si trova nella cartella di WordPress:
memory_limit = 256M
Assicurati che non ci sia il punto e virgola all'inizio della riga! E prendi nota, php.ini avrà un impatto solo sull'istanza di WordPress (o qualsiasi altra applicazione PHP) in esecuzione nella o sotto la cartella in cui si trova il file php.ini . Se hai accesso al tuo server o root web, un file php.ini php.ini situato lì regolerà le impostazioni ambientali per tutte le applicazioni PHP a meno che non abbiano il proprio file php.ini che specifica condizioni diverse.
.htaccess
Un terzo modo per definire il limite di memoria PHP è tramite il file .htaccess nella cartella di WordPress se si utilizza Apache o Litespeed come server HTTP. Come gli esempi precedenti, .htaccess deve avere una riga non commentata come questa per impostare un limite PHP massimo di 256 MB:
php_value memory_limit 256M
Anche gli errori nella sintassi delle impostazioni dell'applicazione e del server in wp-config.php , php.ini e .htaccess possono causare un WSOD. Potrebbe essere necessario correggerli manualmente o sostituirli con i loro valori predefiniti originali se stanno danneggiando il tuo sito. Se utilizzi un server web Apache o Litespeed, il file .htaccess che regola il loro funzionamento può essere modificato da molti plugin di WordPress. Gli errori introdotti in uno qualsiasi di questi file possono far apparire un WSOD e far crollare il tuo sito.
4. Il tuo server HTTP va in crash
HTTP (o la sua forma crittografata e sicura HTTPS) è il protocollo di trasferimento ipertestuale che trasforma un server web in un server web. È il modo in cui i server servono le pagine Web (documenti HTTP) ai client (come i browser) su richiesta.
I server HTTP comunemente usati per i siti WordPress sono Apache, Litespeed e NGINX. Le loro schermate di errore hanno un aspetto leggermente diverso e possono variare nel modo in cui i browser le visualizzano, ma riportano tutti gli stessi codici di errore HTTP.
Un errore HTTP 500, noto anche come errore interno del server, indica che c'è un problema imprevisto con il tuo server HTTP che gli impedisce di soddisfare le richieste HTTP. Altri codici di errore del server 5xx, in particolare 502 (Bad Gateway), 503 (Service Unavailable) e 504 (Gateway Timeout), indicano che il tuo server è sovraccarico o inaccessibile. L'errore interno 500 è un catch-all per i guasti sul server che gli impediscono di restituire la pagina/il documento richiesto.
Il tuo browser potrebbe fornire la propria interpretazione unica delle schermate di errore HTTP e potrebbe visualizzare codici di errore speciali propri. Google Chrome (e altri browser basati su Chromium) elenca e spiega internamente tutti i propri codici di errore se navighi su chrome://network-errors/ nella barra degli indirizzi mentre utilizzi Chrome.
Problemi lato server
Il software server HTTP comunemente utilizzato per i siti WordPress include Apache, Litespeed e NGINX. Molti host WordPress li usano con la memorizzazione nella cache per massimizzare le prestazioni.
Se un aggiornamento forzato del browser o la cancellazione dei cookie e della cache del browser non elimina la schermata di errore 500, potresti rilevare alcuni file di cache lato server non validi. La memorizzazione nella cache lato server può causare molta confusione quando non funziona bene, quindi dovresti anche provare a cancellarla. Il tuo pannello di controllo di hosting o l'interfaccia di amministrazione di WordPress potrebbero avere controlli di cancellazione della cache.
Le cause comuni di un errore HTTP 500 possono includere le seguenti condizioni lato server:
- Il limite di memoria PHP è stato superato.
- Altri errori PHP quando PHP non è impostato per visualizzare gli errori.
- Autorizzazione insufficiente per accedere a file e cartelle del server.
- Errori di sintassi nel file di configurazione .htaccess.
Abbiamo già affrontato i limiti di memoria PHP e come aumentarli. Approfondiremo il debugging di PHP nella prossima sezione di seguito.
Le autorizzazioni errate non dovrebbero verificarsi sul moderno, gestire l'hosting WordPress, ma sono comuni sull'hosting condiviso tradizionale. I file dovrebbero essere impostati su 664 o 644, le cartelle dovrebbero essere impostate su 775 o 755 e wp-config.php dovrebbe essere impostato su 660, 600 o 644. Ulteriori informazioni sulla modifica dei permessi dei file su WordPress.org.
Se hai apportato modifiche al tuo file .htaccess o stai utilizzando un plug-in (spesso o caching) che lo modifica, potrebbe essere necessario verificarne la presenza di errori, ripristinarlo o ricreare un nuovo file .htaccess funzionante. Scopri di più su .htaccess su WordPress.org.
Problemi lato client
Gli errori HTTP 500 possono anche essere causati sul lato client (nel tuo browser) da altre condizioni:
- Impostazioni del browser errate.
- Una cache corrotta.
- File JavaScript corrotti che vengono eseguiti nel tuo browser.
- Problemi di connettività Internet.
Prova a caricare il tuo sito in un browser diverso per eliminare il browser corrente come problema. Se riscontri un problema con il browser, prova a ripristinarlo alle impostazioni predefinite. Disabilita eventuali estensioni o plug-in del browser che hai installato per vedere se interagiscono male con il tuo sito.
Se il tuo problema è correlato a file di cache non validi, l'area di amministrazione di WordPress non memorizzata nella cache potrebbe essere ancora accessibile. Se riesci ancora ad accedere all'interfaccia di amministrazione di WordPress, potresti essere in grado di utilizzare le opzioni di cancellazione della cache lì o provare i passaggi aggiuntivi per la risoluzione dei problemi discussi di seguito.
È anche possibile che un errore HTTP 500 possa essere causato da un problema con il database, un problema con un plugin o un tema in un sito WordPress o un problema con WordPress stesso.
Per risolvere un errore HTTP 500, devi attivare la registrazione degli errori per il tuo server HTTP e PHP. Quindi controlla quali errori compaiono in entrambi. Potresti anche controllare e potenzialmente aumentare il limite di memoria PHP, disattivare i plug-in e passare a un tema predefinito per vedere se una di queste azioni ripristina il tuo sito.
Entreremo in questi passaggi in modo più dettagliato di seguito. Se seguirli non elimina l'errore 500, contatta il team di supporto del tuo host web per ulteriore assistenza.
Quando WordPress è veramente morto
Se ottieni uno schermo completamente bianco su ogni pagina frontale e posteriore del tuo sito WordPress senza alcun feedback di errore visibile, questa è l'esperienza WSOD completa. Puoi ricevere alcuni messaggi di errore e informazioni diagnostiche se sai come accedere ai log degli errori PHP e ai log del server HTTP. Attivare il debug PHP per WordPress è un'altra opzione. Il tuo host potrebbe disporre di alcuni strumenti per rendere il debugging più accessibile per te. Ma se non è così, puoi semplicemente scorrere questo elenco di cure per il WSOD comune finché non trovi la tua soluzione.
Una lista di controllo principale per la risoluzione dei problemi e la correzione della schermata bianca della morte di WordPress
Per correggere la schermata bianca della morte di WordPress, seguire i seguenti passaggi ti porterà a una soluzione. Sono organizzati in ordine delle cause WSOD più comuni così come le ho sperimentate, ma puoi provarle in qualsiasi ordine.
Ha più senso dare la priorità alle soluzioni che sembrano essere più rilevanti per la tua situazione particolare.
La fase di registrazione e debug degli errori (n. 2) è la più tecnica, ma è completa e ti dirà sempre cosa sta causando la chiusura di WordPress.
Ho fornito collegamenti ad alcuni plug-in gratuiti che possono essere utili strumenti di diagnostica e riparazione. Potresti anche trovare iThemes Security particolarmente utile per la sua funzione di scansione e riparazione del database, nonché per il rilevamento delle modifiche ai file. Ha anche strumenti server per uno sguardo più approfondito alle impostazioni e alle capacità del tuo server.
In ultima istanza, un buon backup recente riporterà il tuo sito online nel suo ultimo buono stato noto. Backup Buddy è il miglior plugin per questo ruolo.
Svuota la cache e i cookie del browser
Le pagine memorizzate nella cache del tuo sito nel tuo browser e sul tuo server possono mostrarti qualcosa di diverso da ciò che sta realmente accadendo. Assicuriamoci che tu stia vedendo ciò che WordPress sta mostrando ai nuovi visitatori del tuo sito.
Per prima cosa, svuota la cache e i cookie del tuo browser. Questo terminerà la tua sessione utente se hai effettuato l'accesso a WordPress o a qualsiasi altro sito, quindi lo guardi come qualsiasi altro visitatore.
Successivamente, utilizza il tuo pannello di hosting e l'amministratore di WordPress (se disponibile) per cancellare qualsiasi cache lato server che il tuo host e i plug-in della cache di WordPress stanno creando. Prova a disattivare la cache del tuo sito e del tuo server. Esegui un hard refresh nel tuo browser. Se questo risolve il problema, il problema potrebbe essere che hai attivato le impostazioni della cache che non funzionano sul tuo sistema. Attraverso un processo di eliminazione, puoi identificare quali funzionano e quali no.
2. Cerca errori PHP
Il codice PHP nel core, nei temi o nei plug-in di WordPress può generare un errore fatale che farà sì che WordPress rinunci al fantasma con una schermata bianca della morte.
Per ottenere maggiori informazioni sugli errori irreversibili di PHP e su cosa li sta causando, puoi attivare la segnalazione degli errori PHP e inviarla allo schermo, a un file di registro o a entrambi. Gli errori fatali indicheranno probabilmente la fonte del WSOD.
In quanto applicazione web basata su PHP, WordPress ha il proprio sistema di report diagnostici per il debug che ti aiuta a sfruttare le funzioni di registrazione degli errori di PHP. Per accenderlo e controllarlo, assicurati che ci sia una riga in wp-config.php che dice:
define('WP_DEBUG', vero);Potrebbe essere necessario aggiungerlo o modificare il valore da falso a vero. Questo dice a WordPress di attivare il debugging PHP.
Puoi anche prendere una scorciatoia installando e attivando il plugin WP Debugging. Attiverà il debug PHP per WordPress senza che tu debba modificare direttamente wp-config.php .
I parametri aggiuntivi wp-config.php mostrati di seguito stamperanno l'output di debug sullo schermo come HTML e un file denominato "error_log" per impostazione predefinita:
define('WP_DEBUG_DISPLAY', vero);
define('WP_DEBUG_LOG', vero);Potrebbe anche essere utile forzare WordPress a utilizzare le versioni non ottimizzate delle sue dipendenze CSS e JavaScript nella remota possibilità che stiano causando un problema:
define('SCRIPT_DEBUG', vero);Il plugin Debug Bar è un utile strumento aggiuntivo e complementare. Ti mostrerà i dati di debug in una bella interfaccia.
Perché ciò accada, in php.ini deve esserci una riga che dia alla costante error_reporting un valore diverso da NONE , come error_reporting = E_ALL . Non dovrebbe esserci un punto e virgola a capo di questa riga; che lo rende un commento piuttosto che un'impostazione attiva. Nota che riceverai ogni errore PHP, avviso e avviso se usi E_ALL . Usa un valore diverso come E_ERROR per registrare solo gli errori fatali di runtime che causano il crash di WordPress.
3. Verificare la presenza di conflitti tra temi e plug-in
Il debug degli errori PHP come descritto nel passaggio precedente dovrebbe indirizzarti a un tema chiaro o a un file di plug-in come origine del tuo WSOD. Puoi anche chiuderlo con un approccio meno tecnico al processo di eliminazione.
Temi di risoluzione dei problemi
La schermata bianca della morte è spesso causata da conflitti tra temi e/o plugin di WordPress. Per identificare la o le fonti di conflitto, puoi provare a disattivare tutti i tuoi plug-in e passare ai pacchetti di temi predefiniti correnti e non modificati con il core di WordPress, come Twenty Twenty-Three.
Inizia con il tema: è il più semplice da testare. Se il passaggio dal tema attivo a un tema predefinito noto e non modificato riporta il tuo sito online, sai che il tuo problema è nel tema che hai utilizzato.
Dai un'occhiata al file functions.php del tuo tema se ne ha uno. Se l'hai cambiato di recente, questa è una probabile fonte dei tuoi guai. Il file functions.php è dove viene aggiunto il codice funzionale personalizzato per l'uso con un tema quando è attivato. Il codice errato e gli errori di sintassi qui ti daranno un WSOD.
Risoluzione dei problemi dei plug-in
Puoi disattivare i plugin senza accedere all'amministratore di WordPress tramite la riga di comando/SSH o SFTP semplicemente spostando temporaneamente le cartelle dei plugin fuori dalla cartella /wp-content/plugins/ . La mia pratica consiste nel creare una sottocartella del plugin chiamata "A" in modo che appaia per prima nella directory /plugins in ordine alfabetico. Quindi sposto tutte le altre cartelle dei plug-in in "A".
Una volta fatto questo, ricarica il tuo sito. WordPress si comporterà come se tutti i plugin fossero spariti. Sono ancora installati ma disattivati. Se la schermata bianca della morte scompare, puoi provare a riattivare i tuoi plugin e il tema uno per uno, aggiornando ogni volta la tua home page per vedere quale causa il crash del tuo sito.
Meks Quick Plugin Disabler è uno strumento utile che disabilita rapidamente tutti i plug-in attivi e quindi li riattiva dall'interno dell'amministratore di WordPress al tuo comando.
4. Ripara i file core danneggiati
Il tuo WSOD potrebbe essere la conseguenza di file WordPress core danneggiati. Sebbene ciò sia improbabile, è semplice reinstallare rapidamente l'ultima versione di WordPress con un clic nell'area Aggiornamenti della dashboard di WordPress. Ciò non danneggerà nessuno dei tuoi plug-in, temi o contenuti esistenti, quindi è un modo semplice e valido per confermare che i tuoi file principali vanno bene.
Se nessuno dei passaggi precedenti aiuta, il WSOD potrebbe essere causato da un problema con il tuo ambiente server che è fuori dalla tua portata. In questo caso, potrebbe essere necessario contattare il provider di hosting per assistenza. Come ultima risorsa, puoi anche riportare il tuo sito a uno stato di "ultimo buono noto" ripristinando un backup.
Come prevenire un WSOD — Consigli per i proprietari e i costruttori di siti WordPress
WordPress funzionava perfettamente e poi all'improvviso hai avuto lo schermo bianco della morte!
Ciò è probabilmente dovuto al fatto che TU hai cambiato qualcosa di fondamentale per il funzionamento di WordPress.
Se stai utilizzando un solido account di hosting WordPress gestito con Liquid Web o Nexcess configurato correttamente con risorse sufficienti per le cose che stai facendo con esso, il 99% dei modi in cui puoi rompere WordPress con un WSOD può essere evitato.
Il problema è che i proprietari dei siti non evitano queste pratiche!
Cosa non fare
- Codifica da cowboy. Aggiunta o modifica di codice funzionale su un sito live tramite SFTP, riga di comando o editor di codice e inseritori di script all'interno dell'amministratore di WordPress. Un piccolo errore farà crollare il sito. Anche la modifica di file di configurazione come
.htaccessewp-config.phppuò far crollare un sito. Lavora invece su un test locale o su un sito di staging dal vivo (ma non pubblico). - Installazione di temi, plug-in ed estensioni dubbi. L'installazione di software di bassa qualità o addirittura annullato su un sito live è un invito ai guai. La semplice aggiunta di troppe cose contemporaneamente può rendere difficile determinare cosa sia alla fine un cambiamento decisivo. Simile alla codifica da cowboy, l'installazione di nuovi prodotti di codice in un sito live è rischiosa. Prova prima bene su un locale privato o su un sito di staging.
- Caching complicato. Esistono diversi tipi di cache lato server che il tuo host potrebbe offrire che potrebbero non funzionare bene con tutti i plug-in di memorizzazione nella cache e di ottimizzazione delle prestazioni. Quando si implementano nuovi metodi o impostazioni di memorizzazione nella cache, testare attentamente gli ambienti locali e di staging prima di implementare le modifiche a un sito live.
- Aggiornare tutto in una volta. Puoi aggiornare in batch molti temi e plug-in contemporaneamente. Normalmente funziona, ma se il tuo server va in timeout, potresti rimanere bloccato in modalità manutenzione. Inoltre, il codice appena aggiornato può introdurre nuovi bug, conflitti o problemi di compatibilità. Se ciò accade e il tuo sito non funziona, sarà più difficile identificare l'origine del problema. Potrebbe trattarsi di un numero qualsiasi di elementi se hai aggiornato più temi, plug-in ed estensioni contemporaneamente. Il codice aggiornato può essere testato localmente e su siti di staging live prima di implementarlo sul tuo sito pubblico principale.
Suggerimenti per una vita senza WSOD
Il WSOD può accadere a qualsiasi sito WordPress, ma non dovrebbe essere motivo di allarme. Seguire i suggerimenti di questa guida può aiutarti a identificare il problema e risolverlo rapidamente prima che i visitatori del tuo sito se ne accorgano.
I problemi con un sito WordPress sottolineano l'importanza di una corretta manutenzione e cura. Meglio che reagire ai WSOD, puoi imparare a lavorare su WordPress in un modo che non esporrà mai i tuoi visitatori a messaggi di errore e schermate vuote.
Apporta le tue modifiche con attenzione e deliberatamente. Gestisci i tuoi potenziali WSOD in un ambiente di test o di staging locale. Questi sono strumenti e funzionalità standard per la maggior parte degli host WordPress gestiti oggi. Se segui queste best practice di base, non dovrai preoccuparti della schermata bianca della morte di WordPress.
Il miglior plugin di sicurezza per WordPress per proteggere e proteggere WordPress
WordPress attualmente alimenta oltre il 40% di tutti i siti Web, quindi è diventato un facile bersaglio per gli hacker con intenti dannosi. Il plug-in iThemes Security Pro elimina le congetture dalla sicurezza di WordPress per semplificare la sicurezza e la protezione del tuo sito Web WordPress. È come avere un esperto di sicurezza a tempo pieno nello staff che monitora e protegge costantemente il tuo sito WordPress per te.
Dan Knauss è il Technical Content Generalist di StellarWP. È scrittore, insegnante e libero professionista che lavora nell'open source dalla fine degli anni '90 e con WordPress dal 2004.