errore php wordpress
Leggere un errore PHP in WordPress: fare presto, senza sbagliare
Quando un sito WordPress va in crash, il vero risparmio di tempo consiste nel leggere correttamente il messaggio di errore e capire a cosa si riferisce: un file, una riga, un tipo di errore (fatal, warning, notice), talvolta una funzione o un plugin. Se correggete a caso (disattivare un plugin, ripristinare un tema, svuotare le cache) potreste azzeccarci… ma rischiate soprattutto di peggiorare la situazione o di nascondere temporaneamente il problema.
Un errore PHP utilizzabile contiene generalmente: (1) il tipo di errore, (2) il messaggio, (3) il percorso del file interessato, (4) il numero di riga, (5) e talvolta una traccia (stack trace). A partire da questi elementi, potete formulare una diagnosi affidabile: conflitto tra plugin, funzione deprecata, file mancante, permessi insufficienti, memoria esaurita, problema di autoload, ecc.
Attivare una visualizzazione pulita degli errori: debug di WordPress senza esporre il vostro sito
Il primo riflesso è attivare il debug lato WordPress per ottenere i log, senza mostrare gli errori ai vostri visitatori. In un ambiente di produzione, mostrare gli errori a schermo è una cattiva idea (rischio di divulgazione di informazioni sensibili, deterioramento dell’esperienza, perdita di fiducia).
In wp-config.php, si utilizzano classicamente costanti come WP_DEBUG, WP_DEBUG_LOG e WP_DEBUG_DISPLAY. L’obiettivo: registrare gli errori in un file di log (spesso wp-content/debug.log) e mantenere disattivata la visualizzazione pubblica. Questo solo passaggio trasforma un crash opaco in un incidente leggibile: avete un registro con marca temporale, spesso con la ripetizione degli errori, che aiuta a isolare la causa (una pagina precisa, un’azione amministrativa, un hook attivato, ecc.).
Comprendere i tipi di errori PHP: fatale, di analisi, avviso, notifica
Non tutti gli errori hanno lo stesso impatto e trattarli come equivalenti fa perdere tempo :
Errore fatale : lo script si interrompe bruscamente. Il sito può mostrare una schermata bianca (WSOD) o un messaggio di errore critico. Spesso è legato a una funzione inesistente, a una classe introvabile, alla mancanza di memoria, a un file mancante o a un’incompatibilità con PHP.
Errore di analisi \/ errore di sintassi : PHP non riesce a interpretare il file (spesso manca una parentesi graffa, è stato dimenticato un punto e virgola oppure c’è una virgola finale). Frequente dopo aver copiato e incollato del codice in functions.php o in un file del plugin.
Avviso : il codice continua, ma qualcosa non va (include impossibile, argomento non valido, divisione per zero, ecc.). Da monitorare: un avviso ripetuto può rallentare un sito o annunciare un futuro errore fatale.
Notifica : problema minore (variabile non definita, indice assente). Spesso senza conseguenze immediate, ma un sito ben mantenuto li riduce, perché segnalano una qualità del codice migliorabile e possono interrompere l’output HTML o JSON in determinati contesti.
Dove trovare gli errori: amministrazione, log del server, debug.log, schermata critica
A seconda della configurazione, può comparire un errore PHP:
Nell’interfaccia di WordPress, con il messaggio il sito ha riscontrato un errore critico, talvolta accompagnato da un’email automatica di WordPress che indica l’estensione responsabile.
Nel file wp-content/debug.log se il log è attivato.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Nei log del server (Apache\/Nginx\/PHP-FPM). Questi log sono spesso più completi e rivelano anche errori non gestiti da WordPress.
In strumenti di monitoraggio (se ne disponete), utili per correlare un errore a un picco di traffico, a un aggiornamento o a un’attività cron.
Interpretare il percorso e la riga: il GPS della risoluzione dei problemi
Quando il messaggio indica un file del tipo /wp-content/plugins/mon-plugin/..., è molto probabile che il plugin sia la causa (o che sia la vittima di un altro problema, ma è un punto di partenza). Se il percorso indica /wp-content/themes/mon-theme/..., controllate innanzitutto il tema o un tema child. Se vedete /wp-includes/ O /wp-admin/, l’errore spesso deriva da una chiamata effettuata da un plugin/tema, ma si manifesta nel core di WordPress.
Il numero di riga serve a localizzare con precisione l’istruzione. È molto utile per individuare una funzione deprecata, un tipo errato passato a una funzione o un accesso a un indice inesistente. Attenzione: la riga indicata non è sempre l’origine logica del bug, ma il punto in cui PHP non può più continuare.
Caso n. 1: schermo bianco (WSOD) o Si è verificato un errore critico su questo sito
In questo scenario, è molto probabile che si tratti di un errore fatale. Il metodo più efficace consiste nel:
1) Leggere l’e-mail relativa all’errore critico (WordPress spesso ne invia una all’amministratore).
2) Consultare il debug.log o i log del server.
3) Disattivare temporaneamente l’estensione indicata o tornare a un tema predefinito.
Se non avete più accesso all’amministrazione, utilizzate FTP\/SFTP e rinominate la cartella del plugin responsabile (es. mio-plugin a mio-plugin.off): WordPress lo disattiverà automaticamente. Stessa tecnica per un tema (forzando WordPress a tornare a un tema disponibile).
Per una procedura strutturata, potete seguire una checklist di risoluzione dei problemi passo passo come Risoluzione dei problemi di WordPress: procedura in 10 passaggiutile per non dimenticare nulla (cache, estensioni, tema, configurazione, ecc.).
Caso n. 2: errori dopo l’aggiornamento (core, plugin, tema)
Gran parte degli errori PHP si verifica subito dopo un aggiornamento: un’estensione diventa incompatibile con la versione di PHP, un tema si aspetta una funzione di un plugin oppure un plugin utilizza un’API di WordPress modificata. I sintomi tipici: fatal error relativo a una classe non trovata, nuovi avvisi o area di amministrazione inaccessibile.
Le buone pratiche: individuare cosa è cambiato, tornare temporaneamente indietro se necessario (rollback controllato), quindi aggiornare nuovamente tutto (core, plugin, tema) secondo una combinazione compatibile. Se gestisci regolarmente questo tipo di incidente, prepara una procedura dedicata: Problema di aggiornamento: cosa fare.
Caso n. 3: Allowed memory size exhausted (memoria PHP insufficiente)
Questo errore è frequente sui siti che crescono: page builder, plugin di grandi dimensioni (SEO, e-commerce, backup), importazioni o back office sovraccarico. Indica che PHP ha raggiunto il limite di memoria autorizzato. La soluzione può consistere nel:
Aumentare la memoria (se l’hosting lo consente) e allineare i parametri (limite di memoria PHP, limite di memoria di WordPress).
Ridurre il consumo: disattivare un plugin troppo dispendioso, sostituire un’estensione, ottimizzare le query, limitare le operazioni pesanti nell’amministrazione.
Verificare l’hosting: un hosting condiviso con risorse limitate può causare errori non appena un processo supera le quote.
Per evitare di trattare il sintomo senza risolvere la causa, è utile ottimizzare l’insieme (cache, autoload, plugin, media), soprattutto se siete su un hosting condiviso: Ottimizzare su un Hosting Condiviso.
Caso n°4: errori 500 e arresti anomali lato server
Un errore 500 (Internal Server Error) non è un errore PHP in senso stretto, ma può essere causato da un crash di PHP, da una configurazione del server, da un file .htaccess corrotto, da limiti raggiunti o da un plugin che entra in un ciclo infinito. Spesso WordPress non ha il tempo di visualizzare un messaggio dettagliato: è necessario leggere i log del server.
Le cause comuni sono: regole di riscrittura non valide, permessi dei file errati, memoria\/timeout, conflitto della cache o aggiornamento interrotto. In caso di dubbio, una risorsa dedicata può guidarvi sulle piste specifiche per questo tipo di problema: Errore 500 WordPress: assistenza, risoluzione dei problemi e ….
Caso n°5: Error establishing a database connection ed errori correlati a MySQL
Questo errore può manifestarsi senza un messaggio PHP esplicito, ma spesso provoca un’indisponibilità totale. Può dipendere da: credenziali DB errate in wp-config.php, da un server MySQL non funzionante, da un database corrotto, da un numero eccessivo di connessioni o da un hosting sovraccarico.
La diagnosi corretta consiste nel verificare innanzitutto la disponibilità del server del database e le credenziali, poi lo stato del database (tabelle, riparazione, spazio su disco) e infine il carico complessivo del server. Per una procedura dettagliata orientata alla risoluzione, è possibile consultare Come risolvere l’errore di connessione al database di ….
Caso n°6: Parse error: syntax error dopo la modifica del codice
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Lo scenario classico: aggiunta di uno snippet in functions.php (o in un plugin per snippet) e il sito diventa immediatamente inaccessibile. La correzione è generalmente semplice:
Tornare al file modificato tramite FTP\/SFTP, individuare la riga e correggere la sintassi (graffe, parentesi, virgolette, punto e virgola).
Evitare la modifica diretta in produzione: privilegiare un ambiente di staging o, come minimo, un plugin per snippet che possa disattivare il codice responsabile senza compromettere l’intero sito.
Utilizzare un editor con convalida della sintassi e formattazione automatica per limitare gli errori.
Caso n°7: funzioni deprecate e incompatibilità con la versione di PHP
Un aggiornamento di PHP (ad es. il passaggio alla versione 8.x) migliora spesso le prestazioni e la sicurezza, ma può compromettere un plugin obsoleto. I messaggi tipici sono: Deprecated, Uncaught TypeError, Call to undefined function o errori di tipizzazione rigorosa. In questo caso:
Aggiornare il plugin/il tema a una versione compatibile.
Sostituire l’estensione se non è più mantenuta.
Evitare i temi personalizzati non testati: se è necessario del codice personalizzato, documentarlo e testarlo su staging.
Isolare la causa: metodo di triage affidabile (senza passarci la giornata)
Quando non sapete da dove proviene l’errore, applicate un metodo di triage:
1) Riprodurre : quale URL, quale azione, quale ruolo utente, quale browser? Un errore casuale è spesso un errore non riprodotto.
2) Leggere il primo errore : in un log, la prima occorrenza è spesso la causa, le successive sono delle conseguenze a cascata.
3) Disattivare a gruppi : se il log punta a un plugin, iniziate da quello. Altrimenti, disattivate tutti i plugin e riattivateli uno alla volta. È lungo, ma è deterministico.
4) Tornare a un tema predefinito : per eliminare i problemi del tema.
5) Verificare le cache : cache del plugin, cache del server, CDN. Un file obsoleto può mantenere un errore anche se il codice è stato corretto.
6) Verificare i limiti del server : memoria, timeout, dimensione dell’upload, numero di processi.
Correggere correttamente: patch minima, poi messa in sicurezza
Una correzione efficace si fa in due fasi. Innanzitutto, una patch minima per rimettere in piedi il sito (disattivare l’estensione difettosa, eseguire un rollback, correggere la sintassi). Poi, una messa in sicurezza : aggiornamento, sostituzione dell’estensione, test, aggiunta di misure di sicurezza (staging, backup, monitoraggio).
Se intervenite nel codice, evitate i quick fix che nascondono l’errore (ad es. aggiungere dei @ davanti alle funzioni, disattivare i log o ignorare i warning). È meglio correggere la fonte: convalida degli argomenti, verifica dell’esistenza (funzione\/classe), compatibilità con PHP e rispetto degli hook di WordPress.
Il ruolo dell’hosting: prestazioni, stabilità ed errori PHP
Molti errori ricorrenti (timeout, memoria, errori 500) sono aggravati da un server sottodimensionato o configurato male. Un hosting troppo limitato può trasformare un semplice warning in un’interruzione ricorrente non appena si verifica un picco di traffico. Al contrario, un’infrastruttura adeguata (PHP-FPM configurato, risorse sufficienti, storage veloce, versione PHP supportata) riduce drasticamente gli incidenti.
Se vi state chiedendo se cambiare server o passare a un piano superiore, basatevi su criteri concreti (risorse, isolamento, supporto, backup, log, versioni PHP\/MySQL, politica di sicurezza): e Hosting Come scegliere un server performante.
Documentare per correggere più rapidamente la prossima volta
Gli errori PHP non sono mai un episodio isolato: si ripresentano sotto un’altra forma se il sito cresce, se il team cambia o se lo stack si evolve. Documentare il vostro WordPress (plugin critici, impostazioni del server, snippet, procedure di aggiornamento, accessi, schemi funzionali) riduce notevolmente i tempi di risoluzione.
Una documentazione utile non è un romanzo: deve aiutare a rispondere rapidamente a domande come: che cosa è stato modificato?, dove si trova il codice personalizzato?, quali sono i plugin indispensabili?, come si esegue un ripristino?. Per strutturare questo aspetto, potete fare riferimento a Come documentare il proprio sito per facilitarne la manutenzione.
Quando riparare diventa un progetto: ripristino, pulizia, riorganizzazione
A volte, correggere un errore PHP rivela una situazione più ampia: accumulo di plugin, temi obsoleti, eccesso di codice personalizzato, database troppo grande, permessi dei file incoerenti. In questo caso, riparare non si limita a correggere una riga: bisogna riportare il sito a uno stato che ne consenta la manutenzione (backup, audit, pulizia, aggiornamento, test, messa in sicurezza).
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Se cercate un approccio di riparazione più globale (oltre al solo messaggio di errore), un metodo passo dopo passo può essere utile: Come riparare un sito WordPress?.
Prevenire è meglio che subire: manutenzione, test, backup, monitoraggio
La correzione migliore resta quella che non dovete effettuare d’urgenza. Una manutenzione regolare limita notevolmente gli errori PHP: aggiornamenti controllati, test in staging, backup verificati, monitoraggio dei log, rotazione delle versioni PHP e revisione periodica delle estensioni. Per una PMI, l’obiettivo è semplice: evitare l’interruzione della produzione, proteggere il fatturato e mantenere un sito performante e sicuro.
Se il vostro sito supporta attività aziendali importanti (lead, e-commerce, prenotazione di appuntamenti), è opportuno definire ciò che è davvero indispensabile nel lungo periodo: Manutenzione per PMI Ciò Che È Indispensabile.
Quando affidare la correzione a un servizio di manutenzione WordPress?
Potete correggere autonomamente una parte degli errori se avete accesso ai log, a un FTP\/SFTP e a un minimo di metodo. Al contrario, è preferibile delegare se: l’errore è ricorrente, l’area di amministrazione è inaccessibile, avete esigenze di disponibilità, non disponete di backup affidabili o sospettate un problema del server (risorse, database, configurazione).
Un servizio di manutenzione offre generalmente: monitoraggio, backup, aggiornamenti testati, interventi rapidi e soprattutto una riduzione del rischio di un incidente critico nel momento sbagliato. Se volete strutturare una soluzione ricorrente invece di gestire le emergenze caso per caso, potete scoprire le nostre offerte di manutenzione.
Conclusione: un errore PHP si legge, si dimostra e poi si corregge
Per correggere in modo efficace, partite dai fatti: messaggio esatto, file, riga, contesto di riproduzione e log. Rimettete il sito online con una patch minima, poi stabilizzatelo: aggiornamenti coerenti, hosting adeguato, documentazione e manutenzione continua. Questa disciplina trasforma i guasti incomprensibili in incidenti sotto controllo, più rapidi da risolvere e molto meno costosi.
