Leggere il log degli errori di cPanel e trovare gli errori del sito web

Quando un sito Web mostra un errore, il messaggio visibile nel browser è spesso solo un sintomo. Il problema reale può essere causato, ad esempio, da PHP, da un'applicazione, da percorsi di file errati, da autorizzazioni o da una configurazione errata del server.

In CURIAWEB-cPanel trovi sotto Valori misurati → Errore voci recenti dal registro degli errori del server web. Questi messaggi possono fornire indizi cruciali su, quando, dove e perché si è verificato un errore.

In questa guida ti mostriamo come accedere al registro degli errori di cPanel, leggere i messaggi di errore tipici e ricavare da essi i passaggi successivi più sensati per la risoluzione dei problemi.

Importante: Un messaggio di errore non dovrebbe essere esaminato solo alla ricerca di singoli termini. Timestamp, percorso del file, numero di riga e testo dell'errore vanno considerati insieme. Spesso solo il contesto completo mostra quale file o applicazione sia effettivamente interessato.

Cos'è il registro degli errori di cPanel? #

I server web e le applicazioni registrano determinati errori che si verificano durante l'elaborazione di un sito web.

Nel pannello di cPanel Errore puoi visualizzare le voci correnti dal registro degli errori del server web.

Tali voci possono contenere, ad esempio, indicazioni su:

• Errore PHP
• file non trovati
• percorsi file non validi
• Problemi di autorizzazione
• configurazioni errate
• Problemi con gli script PHP
• determinati messaggi di Apache/server web

Il registro degli errori è quindi uno degli strumenti più importanti per la diagnosi di un sito web che improvvisamente non funziona più correttamente.

Cosa non è il registro degli errori #

Il registro degli errori di cPanel non è una cronologia completa di tutte le operazioni all'interno del tuo account di hosting.

Non mostra nemmeno automaticamente:

• ogni errore di ogni applicazione
• tutti gli errori di WordPress
• tutti gli errori del database
• a tutti gli output dei cronjob
• tutti gli accessi al tuo sito web

A seconda del tipo di errore, possono essere rilevanti altri log o strumenti di diagnostica.

Breve spiegazione: Il registro degli errori è un punto di partenza importante, ma non ogni problema tecnico deve esservi registrato.

1. Aprire il registro degli errori di cPanel #

Accedi al tuo cPanel di CURIAWEB.

Apri quindi:

Valori misurati → Errore

cPanel ti mostra lì le voci recenti del registro degli errori.

2. Riprodurre prima l'errore #

Se un determinato errore è riproducibile, dovresti ricaricare la pagina interessata immediatamente prima di controllare il log.

Esempio:

13:42
→ aprire la pagina con errori

13:43
→ cPanel → Metriche → Apri errori

In questo modo puoi associare molto più facilmente i log correnti all'errore appena verificatosi.

Consiglio pratico: Prendi nota dell'ora esatta in cui hai provocato l'errore. Soprattutto sui siti web con molto traffico, in breve tempo possono generarsi numerosi messaggi diversi.

3. Non considerare automaticamente l'ultimo inserimento come la causa #

L'ultimo log in ordine temporale non appartiene necessariamente al tuo problema.

Un sito web può ad esempio essere utilizzato contemporaneamente da:

• Visitatori
• Motori di ricerca
• Bot
• Sistemi di monitoraggio
• altre applicazioni

essere chiamato.

Verifica quindi, oltre al timestamp, sempre il percorso interessato o il file specificato.

Come è strutturato un messaggio di errore? #

La struttura esatta dipende dal tipo di errore. Tuttavia, una voce di registro può contenere informazioni come queste:

Timestamp
Tipo di errore
Testo dell'errore
Percorso del file
Numero di riga
ulteriori informazioni tecniche

Un esempio di PHP schematico potrebbe essere il seguente:

Errore fatale PHP:
Errore non intercettato: ...
in /home/CPANELUSER/public_html/example.php
alla riga 125

Per la ricerca degli errori sono rilevanti diversi componenti.

Timestamp #

Il timestamp ti aiuta a determinare se il messaggio è stato effettivamente generato nel momento in cui hai riscontrato il problema.

Una segnalazione di ieri non è normalmente la prova di un errore che hai appena causato.

Tipo di errore #

Il tipo di errore fornisce un primo indizio sulla gravità e sulla categoria del problema.

Esempi:

Errore fatale PHP
Avviso PHP
Avviso PHP
Permesso negato
File non trovato

Questi messaggi non significano la stessa cosa e dovrebbero quindi essere trattati in modo diverso.

Messaggio di errore #

Il testo dell'errore vero e proprio descrive cosa è andato storto durante l'elaborazione.

Gli esempi possono essere:

Chiamata a funzione non definita ...
Classe ... non trovata
Impossibile aprire il file richiesto ...
Permesso negato
Dimensione di memoria consentita ... esaurita

Il testo dell'errore è spesso la parte più importante per la classificazione tecnica.

Percorso file #

Il percorso del file specificato indica spesso quale file è stato coinvolto nell'errore.

Per esempio:

/home/CPANELUSER/public_html/wp-content/plugins/example/plugin.php

Da un tale percorso si può già dedurre che il file in questione si trova all'interno di un plugin di WordPress.

Importante: Un percorso di file indica dove è stato generato o rilevato l'errore. Ciò non significa necessariamente che proprio questo file sia l'unica causa effettiva.

Numero di riga #

I messaggi di errore PHP possono anche includere un numero di riga:

alla riga 125

Questo consente di individuare il punto corrispondente all'interno del file.

Il numero di riga è utile soprattutto per gli sviluppatori o per il proprio codice. In caso di un plugin o di un tema di terze parti, non dovresti semplicemente eliminare o modificare la riga di codice in questione.

Comprendere un errore fatale in PHP #

Uno:

Errore fatale PHP

significa che PHP non ha potuto continuare l'esecuzione in questione a causa di un errore grave.

Ciò può comportare, ad esempio, che:

• una pagina non viene caricata
• appare solo una pagina vuota
• WordPress segnala un errore critico
• si verifica un errore HTTP 500

Quello che conta è il testo che segue Errore fatale PHP segue.

„Comprendere “Uncaught Error" #

Un messaggio come:

Errore non intercettato: ...

indica che durante l'esecuzione di PHP si è verificato un errore che non è stato intercettato dall'applicazione.

Ad esempio, potrebbe mancare una funzione o una classe necessaria.

Il messaggio deve essere sempre considerato insieme al percorso del file e al numero di riga seguenti.

„Chiamata a funzione non definita“ #

Un messaggio come:

Chiamata a funzione non definita example()

significa che PHP non conosce una funzione chiamata oppure che non è disponibile al momento della chiamata.

Le possibili cause possono essere:

• estensione PHP mancante
• file di applicazione non caricato
• codice incompatibile
• plugin o tema difettoso
• Conflitto di versione

Se la funzione appartiene a un'estensione PHP, l'articolo Attivare e gestire le estensioni PHP in cPanel aiutare.

„Classe non trovata“ #

Un messaggio come:

Classe "Example" non trovata

significa che un'applicazione vuole utilizzare una classe PHP che in quel momento non è disponibile.

Ciò può avvenire, ad esempio, tramite:

• file mancanti
• aggiornamenti incompleti
• dipendenze difettose
• Plugin incompatibili
• codice personalizzato difettoso

essere causato.

In un sito WordPress, il percorso del file può spesso indicare quale plugin o tema è coinvolto.

„Impossibile aprire il file richiesto“ #

Un messaggio come:

Impossibile aprire il file richiesto '/pfad/datei.php'

indica che PHP non è riuscito a caricare correttamente un file richiesto.

Verifica in particolare:

• Il file esiste?
• Il percorso è corretto?
• il file è stato spostato o eliminato?
• è stato incompleto un aggiornamento?
• Le autorizzazioni sono corrette?

Con il Gestione file di cPanel puoi controllare il percorso specificato.

„Nessun file o directory“ #

Un messaggio come:

Nessun file o directory

significa fondamentalmente che un file o una directory attesi non sono stati trovati nel percorso specificato.

Ciò può verificarsi, ad esempio, dopo una migrazione, uno spostamento manuale di file o un aggiornamento difettoso.

„Permesso negato“ #

Un messaggio come:

Permesso negato

indica che l'accesso richiesto non è stato possibile a causa delle autorizzazioni esistenti.

Verifica prima in questo caso:

• quale file o quale directory è interessato
• quale accesso è stato tentato
• se le autorizzazioni dei file esistenti siano plausibili

Le basi si trovano su Impostare correttamente i permessi dei file 644 e 755 in cPanel.

Attenzione: Non impostare i permessi dei file in modo indiscriminato su 777, solo per far sparire un messaggio di errore. Questo non risolve la causa in modo pulito e può peggiorare la sicurezza del sito web.

„Memoria consentita esaurita“ #

Un comune messaggio di errore di PHP è, all'incirca:

Dimensione di memoria consentita di ... byte esaurita

In questo caso PHP ha raggiunto il limite di memoria disponibile per il processo.

Il messaggio contiene spesso anche:

• il limite di memoria disponibile
• la quantità di memoria richiesta in aggiunta
• il file interessato
• un numero di riga

Ti spieghiamo come valutare i limiti di memoria PHP e altri limiti su Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.

Non aumentare semplicemente il limite di memoria in modo illimitato #

Se un'applicazione richiede una quantità insolitamente elevata di memoria, potrebbe essere necessario un limite più elevato, ma potrebbe anche semplicemente mascherare un sintomo.

Esempi di un consumo di memoria insolitamente elevato possono essere:

• plugin difettoso
• enorme quantità di dati
• ciclo infinito
• importazione problematica
• configurazione dell'applicazione non idonea

Verifica quindi anche il contesto dell'errore.

„Tempo massimo di esecuzione superato“ #

Un messaggio come:

Tempo massimo di esecuzione di ... secondi superato

significa che un processo PHP è rimasto in esecuzione più a lungo di quanto consentito per questo ambiente PHP.

Ciò può verificarsi, ad esempio, in:

• grandi importazioni
• esportazioni complesse
• lenti collegamenti esterni
• operazioni di database estese
• codice applicativo problematico

verificarsi.

Anche qui il limite non dovrebbe essere aumentato ciecamente. Verifica prima quale processo è interessato.

Capire i PHP Warning #

Uno

Avviso PHP

non è fondamentalmente la stessa cosa di un errore fatale.

PHP può continuare l'elaborazione in presenza di molti avvisi.

Tuttavia, gli avvisi possono indicare errori o programmazione obsoleta o problematica.

Se la stessa avvertenza si verifica molto frequentemente, può anche ingrandire inutilmente i file di log.

Avvisi e messaggi deprecati di PHP #

Messaggi come:

Avviso PHP

o:

PHP Deprecato

sono anch'essi da distinguere da un errore fatale.

Un avviso di deprecazione indica tipicamente che il codice utilizza una funzione o una procedura considerata obsoleta e che potrebbe non essere più supportata in futuro.

Messaggi di questo tipo si verificano più frequentemente, ad esempio dopo il passaggio a una versione più recente di PHP, con applicazioni, plugin o temi meno recenti.

Numerosi messaggi di deprecazione dopo il cambio di versione di PHP #

Se subito dopo un cambio di versione di PHP compaiono numerosi avvisi di deprecazione, dovresti verificare se l'applicazione in questione è completamente compatibile con la nuova versione di PHP.

La versione PHP del tuo dominio viene gestita su CURIAWEB fondamentalmente tramite il MultiPHP-Manager.

Non impostare a caso diverse versioni di PHP una dopo l'altra. Verifica prima i requisiti di sistema del software utilizzato.

Il messaggio di errore indica un plugin di WordPress #

Un percorso di WordPress può ad esempio apparire così:

/home/CPANELUSER/public_html/wp-content/plugins/example-plugin/file.php

L'area:

/wp-content/plugins/example-plugin/

mostra che il file appartiene a un plugin.

Se lì si verifica un errore irreversibile, questo plugin è una delle prime componenti che dovresti esaminare.

Tuttavia, ciò non significa automaticamente che la colpa sia solo del plugin. Anche un conflitto con un altro plugin, un tema, PHP o WordPress stesso potrebbe essere coinvolto.

Il messaggio di errore indica un tema WordPress #

Un percorso come:

/wp-content/themes/example-theme/...

sottolinea che il file in questione si trova all'interno di un tema.

Verifica quindi in particolare:

• Il tema è stato appena aggiornato?
• PHP è stato modificato?
• È stato aggiornato WordPress?
• si è verificato l'errore subito dopo una modifica al tema?
• si tratta di codice personalizzato?

Il messaggio di errore indica wp-content, ma la causa potrebbe trovarsi altrove #

In WordPress, Core, plugin e temi si integrano costantemente tra loro.

Un errore può quindi apparire, ad esempio, nel plugin A, anche se una modifica causata dal plugin B ha scatenato lo stato problematico.

Considera quindi il percorso del file come un indizio importante, non come una prova automatica di colpevolezza.

Capire lo Stack Trace #

In determinati errori PHP viene inoltre visualizzato un cosiddetto Traccia dello stack registrato.

Questo mostra in modo semplificato quali funzioni o file sono stati chiamati prima che si verificasse l'errore.

Schematicamente:

#0 File A → Funzione X
#1 File B → Funzione Y
#2 File C → Funzione Z
#3 Chiamata principale

Una traccia dello stack può essere molto preziosa perché mostra il percorso fino all'errore effettivo.

In un stack trace non leggere solo l'ultima riga #

Un stack trace contiene diverse chiamate coinvolte.

La prima file visibile o l'ultima riga non sono quindi automaticamente la causa.

Su WordPress, ad esempio, un plugin può richiamare una funzione del core di WordPress in cui l'errore diventa infine visibile.

Per la diagnosi è rilevante l'intera catena di chiamate.

„inserito in … alla riga …“ #

Nei fatal error di PHP, alla fine di un messaggio, ad esempio, potrebbe esserci:

lanciato in /home/CPANELUSER/public_html/example.php alla linea 125

Questa indicazione mostra in quale punto l'eccezione o l'errore è stato infine generato.

Documenta questa riga insieme al testo di errore precedente.

File mancante dopo un aggiornamento di plugin o tema #

Se immediatamente dopo un aggiornamento si verificano messaggi relativi a file mancanti, l'aggiornamento potrebbe essere incompleto o un'installazione danneggiata.

In questo caso non cancellare singoli file a caso.

Verifica prima:

• quale componente è interessato
• se l'aggiornamento sia stato completato completamente
• se sia presente un backup recente
• se il componente possa essere reinstallato pulitamente o ripristinato

HTTP 500 e registro errori #

In caso di problema lato server, un browser potrebbe mostrare solo:

Errore interno del server

Questo messaggio da solo non dice ancora da cosa sia stato causato l'errore.

Il registro degli errori può contenere, ad esempio, un errore PHP fatale specifico, una configurazione errata o un errore di autorizzazione.

Trattiamo la diagnosi completa sotto Risolvere l'errore 500 Internal Server Error.

HTTP 403 e registro errori #

In un:

403 Proibito

anche il log degli errori può fornire indicazioni, ad esempio in relazione a permessi o restrizioni di accesso.

Tuttavia, un errore 403 può essere causato anche da altri livelli di sicurezza.

Trattiamo la ricerca sistematica degli errori sotto Risolvere l'errore 403 Forbidden.

HTTP 503 e registro errori #

Uno:

503 Servizio non disponibile

può avere cause diverse.

Oltre ai problemi applicativi, possono essere rilevanti anche le risorse o i servizi temporaneamente non disponibili.

Ulteriori passaggi sono disponibili su Risolvere l'errore 503 Service Unavailable.

.Rilevare errori .htaccess #

Un difettoso .htaccess-configurazione può causare il mancato corretto trattamento di un sito web.

A seconda dell'errore, il registro può contenere indicazioni su una direttiva non valida o su una configurazione non consentita.

Se il problema si verifica subito dopo una modifica a .htaccess è iniziato, dovresti prima verificare questa modifica.

Puoi trovare ulteriori informazioni su .htaccess spiegato e modificato in sicurezza.

„Invalid command“ dopo la modifica di .htaccess #

Un messaggio può indicare, ad esempio, che una direttiva non è stata riconosciuta o non è consentita in questo contesto.

Se poco prima del codice da una guida di terze parti in .htaccess che hai inserito, ripristina lo stato precedente e controlla la direttiva utilizzata.

Attenzione: Non inserire istruzioni Apache o PHP casuali in .htaccess uno. Non tutte le direttive sono consentite in ogni configurazione di hosting e PHP.

Non impostare i valori PHP ciecamente tramite .htaccess #

Nelle moderne configurazioni di PHP, le vecchie guide con direttive come:

php_value ...
php_flag ...

non essere idoneo e, con determinati gestori PHP, causare persino un errore HTTP 500.

Puoi gestire le impostazioni PHP su CURIAWEB tramite gli appositi strumenti di cPanel.

Spieghiamo la procedura su Modificare le impostazioni PHP in cPanel.

Distinguere tra File non trovato e 404 #

Non ogni messaggio su un file non trovato significa che l'intero sito web sia difettoso.

I siti web ricevono regolarmente richieste di risorse inesistenti.

Questi possono essere, ad esempio:

• vecchi URL
• immagini eliminate
• link non funzionanti
• Richieste del bot
• scansioni automatizzate

Di conseguenza, una singola voce relativa a un file inesistente non è automaticamente critica.

Classificare correttamente le richieste dei bot #

I siti web accessibili al pubblico vengono regolarmente visitati in modo automatizzato.

In questo modo i bot possono richiedere URL che non sono mai esistiti sul tuo sito web.

Esempi possono essere percorsi insoliti verso interfacce di amministrazione, script o note vulnerabilità di altri sistemi.

Tali voci non costituiscono automaticamente un'indicazione del fatto che il file in questione fosse presente sul tuo hosting.

Importante: Un registro può semplicemente mostrare che qualcuno ha richiesto un determinato URL. Da ciò non consegue automaticamente che il file richiesto esista o che il tuo sito web sia stato compromesso.

Gli errori ricorrenti sono più importanti delle singole segnalazioni casuali #

Nella definizione delle priorità, dovresti prestare attenzione a se una segnalazione:

• ad ogni caricamento di pagina appare
• si è verificato solo una volta
• riguarda sempre lo stesso file
• coincide con un problema visibile del sito web
• si verifica solo dopo una determinata modifica

Un messaggio di errore riproducibile, che si genera esattamente quando si apre la pagina difettosa, è di solito molto più rilevante di un vecchio log casuale.

Distinguere tra causa e errore consequenziale #

Un singolo problema può attivare ulteriori messaggi di errore.

Per esempio:

file mancante
        ↓
la classe non può essere caricata
        ↓
la funzione non può essere eseguita
        ↓
la pagina si interrompe con un errore irreversibile

Se tratti solo l'ultimo messaggio, la causa originale potrebbe persistere.

Verifica quindi, in presenza di più segnalazioni simultanee, quale sia sorta per prima e come le segnalazioni siano collegate.

Cosa è stato modificato immediatamente prima dell'errore? #

Una delle domande più preziose nella diagnosi è:

Cosa è cambiato immediatamente prima della prima comparsa dell'errore?

Esempi:

• Aggiornamento di WordPress
• Plugin aggiornato
• Tema aggiornato
• Versione PHP modificata
• Impostazione PHP modificata
• .htaccess modificato
• File spostati
• Sito web migrato
• nuovo plugin installato

La correlazione temporale non è una prova definitiva, ma è un punto di partenza molto prezioso.

Annullare sempre e solo una modifica #

Se l'errore è iniziato dopo una modifica specifica, dovresti idealmente controllare prima di tutto proprio quella modifica o annullarla in modo controllato.

Non modificare contemporaneamente:

Versione PHP
.htaccess
Permessi dei file
Plugin
Tema
Limiti PHP

Altrimenti in seguito sarà difficilmente possibile stabilire quale misura sia stata rilevante.

Errore dopo il cambio di PHP #

Se un sito Web non funziona più immediatamente dopo un cambio di PHP, controlla il log degli errori per messaggi come:

• Errori irreversibili
• funzioni mancanti
• classi mancanti
• Messaggi di deprecazione
• Problemi con le estensioni

Se l'applicazione non è compatibile con la nuova versione di PHP, un passaggio controllato alla versione precedentemente funzionante può essere un utile passo diagnostico.

Errore dopo la modifica delle impostazioni PHP #

Se il problema si è verificato immediatamente dopo una modifica nel MultiPHP INI Editor, dovresti controllare l'ultima direttiva modificata.

Trattiamo la configurazione di PHP in dettaglio su Modificare le impostazioni PHP in cPanel.

Errore dopo la modifica dei permessi dei file #

Se file o directory hanno ricevuto permessi diversi immediatamente prima dell'errore, dovresti considerare anche questo contesto.

Non impostare i permessi a valori sempre più alti in modo casuale, ma stabilisci una configurazione adatta al rispettivo tipo di file.

Errore dopo la migrazione #

Dopo un trasferimento del sito web, i messaggi di errore possono indicare, ad esempio, i seguenti problemi:

• vecchi percorsi di file assoluti
• file mancanti
• versione PHP incompatibile
• estensioni PHP mancanti
• trasmissione incompleta
• configurazione deviante

Proprio i percorsi assoluti possono differire tra due sistemi di hosting.

Errore dopo il ripristino di un backup #

Se dopo un ripristino si verificano errori, dovresti verificare se i file e il database appartengono allo stesso stato.

Un'applicazione può causare problemi se, ad esempio, file più recenti vengono combinati con un database notevolmente più vecchio.

Differenza tra il registro degli errori di cPanel e il registro di debug di WordPress #

WordPress dispone inoltre di proprie opzioni di debugging.

Con il debug di WordPress attivato, ad esempio, un file come:

wp-content/debug.log

essere utilizzato.

Il registro di debug di WordPress e il registro degli errori di cPanel non sono la stessa cosa.

Si possono integrare perché possono registrare errori a livelli diversi o con contesti differenti.

Trattiamo la diagnostica di WordPress alla voce Utilizzare il debug di WordPress e i log degli errori.

Non lasciare il debug di WordPress permanentemente e inutilmente attivo #

Le funzioni di debug dovrebbero essere utilizzate in modo mirato su un sito web di produzione per la diagnostica.

In particolare, i messaggi di errore non dovrebbero essere pubblicati inutilmente nel frontend.

I log possono contenere informazioni tecniche e non dovrebbero essere resi accessibili al pubblico.

Distinguere il registro degli errori di cPanel dall'output dei cron job #

Uno script PHP, eseguito tramite un cron job o la riga di comando, non deve necessariamente lasciare i suoi errori nello stesso log del server web.

In caso di problemi con i cron job, dovresti quindi controllare anche l'effettivo output del cron e i log specifici dell'applicazione.

Spieghiamo la procedura su Cronjob non funziona: cause e soluzioni.

Distinguere tra registro degli errori e registro degli accessi #

Un registro degli errori (error log) registra gli errori e le relative situazioni di errore.

Un registro accessi, invece, registra gli accessi al server web.

In sintesi:

Registro degli accessi
→ Chi o cosa ha richiesto quale risorsa?

Registro degli errori
→ Quale errore si è verificato durante l'elaborazione?

Entrambi i tipi di log possono completarsi a vicenda in una diagnosi dettagliata.

Dati grezzi degli accessi in cPanel #

Nel campo Valori misurati cPanel fornisce inoltre funzionalità aggiuntive per i dati di accesso e le statistiche.

Se, ad esempio, desideri verificare se sia stata visitata una determinata URL, i dati di accesso potrebbero rivelarsi più utili del solo log degli errori.

Distinguere tra registro degli errori e risorse di CloudLinux #

Un caricamento di pagina lento o non riuscito non deve necessariamente generare un classico errore PHP.

Quando le risorse di hosting vengono esaurite, dovresti controllare anche l'utilizzo delle risorse di CloudLinux.

Spieghiamo come funziona alla pagina Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.

Quando risorse ed error log sono interessanti insieme #

Supponendo che un sito web si interrompa sporadicamente e che il registro degli errori non contenga una causa PHP chiara e ricorrente.

Allora un confronto può avere senso:

Momento del problema del sito web
        ↓
Controllare il registro degli errori
        ↓
Controllare le risorse CloudLinux nello stesso periodo

Ciò consente, ad esempio, di verificare se l'errore coincide con un picco di carico.

Non confondere i vecchi errori con i problemi attuali #

Un registro errori può contenere messaggi la cui causa è stata risolta da tempo.

Se, ad esempio, ieri un plugin ha generato un errore irreversibile e oggi funziona di nuovo correttamente, il vecchio messaggio rimane inizialmente un avviso storico.

È quindi sempre determinante il nesso temporale con il problema attuale.

Attivare nuovamente l'errore in modo mirato #

In caso di un problema riproducibile, la seguente procedura è particolarmente efficace:

1. Controllare brevemente il registro degli errori di cPanel.
2. Annotare l'ora attuale.
3. Accedere alla pagina o funzione interessata esattamente una volta.
4. Riaprire o aggiornare il registro degli errori.
5. Cercare nuovi inserimenti al momento opportuno.
6. Controllare il percorso del file e il testo dell'errore.

In questo modo riduci la probabilità di analizzare un log completamente diverso.

L'errore si verifica solo con un determinato URL #

Se è interessata solo una singola pagina, verifica:

• quale codice specifico viene eseguito su questa pagina
• quale plugin o tema è coinvolto
• se il sito utilizza funzioni particolari
• se un nuovo record di log viene creato immediatamente al momento della chiamata

Una homepage funzionante non dimostra che tutte le funzioni PHP del sito web siano prive di errori.

L'errore si verifica solo nell'area di amministrazione di WordPress #

Se il frontend funziona, ma ad esempio una determinata pagina di amministrazione genera un errore fatale, dovresti aprire proprio quell'area di amministrazione e successivamente controllare le nuove voci di log.

I plugin possono, ad esempio, eseguire codice solo all'interno dell'area di amministrazione.

L'errore si verifica solo con i moduli #

Un modulo può funzionare durante la normale visualizzazione della pagina e generare un errore solo al momento dell'invio.

Riproduci quindi esattamente l'azione in cui si verifica il problema.

Durante la ricerca degli errori non conta solo l'URL, ma la procedura concreta.

L'errore si verifica solo sporadicamente #

Gli errori sporadici sono più difficili da diagnosticare.

Documenta il più possibile:

• Data e ora
• URL interessata
• azione eseguita
• messaggio del browser visibile
• registri di log simultanei
• possibili valori delle risorse

Più il momento è noto con precisione, più è facile confrontare diverse fonti di diagnosi tra loro.

Non divulgare il messaggio di errore #

I log degli errori possono contenere percorsi di file interni, nomi utente, configurazioni tecniche o altre informazioni sull'ambiente di hosting.

Non pubblicare quindi imprudentemente log completi in forum pubblici o sui social network.

Avviso di sicurezza: Controlla i log per verificare la presenza di password, token, chiavi API, dati personali e altre informazioni riservate prima di divulgarli.

Non inviare log enormi incompleti #

Per una richiesta di supporto, un estratto rilevante relativo all'errore specifico è spesso più utile di migliaia di righe di log sconnesse.

L'importante è:

• Momento
• messaggio di errore completo
• file interessato
• se necessario, stack trace
• Descrizione dell'azione che attiva l'errore

Copia il messaggio di errore per intero #

In una segnalazione tecnica, non estrapolare solo un singolo termine.

Ad esempio, invece di:

Errore fatale

per essere trasmessa, la relativa segnalazione dovrebbe essere documentata con il testo dell'errore, il percorso del file e il numero di riga.

Proprio questi dettagli differenziano due cause completamente diverse.

Messaggi tipici e primi controlli #

Segnalazione	Primo passaggio di verifica
Errore fatale PHP	controllare il testo completo dell'errore, il file e la riga
Errore non gestito	Valutare il testo dell'errore e lo stack trace
Chiamata a funzione non definita	Controllare l'estensione PHP, l'applicazione e la versione di PHP
Classe ... non trovata	verificare l'applicazione interessata e la dipendenza mancante
Impossibile aprire il file richiesto	Controllare il percorso del file e i file esistenti
Nessun file o directory	Controlla percorso, nome file e migrazione
Permesso negato	Controlla i permessi dei file e delle directory
Dimensione di memoria consentita ... esaurita	Verificare lo spazio di archiviazione e il limite di memoria PHP
Tempo massimo di esecuzione ... superato	verificare il processo interessato e la durata
PHP Deprecato	Verificare la compatibilità del software con la versione di PHP
Comando non valido	Controlla la configurazione o il file .htaccess

Risoluzione sistematica dei problemi con il registro degli errori di cPanel #

1. Prendi nota del problema visibile e dell'URL interessato.
2. Annota l'ora attuale.
3. Apri Valori misurati → Errore.
4. Apri di nuovo la pagina o la funzione problematica.
5. Controlla immediatamente dopo i nuovi file di log.
6. Confronta il timestamp con il tuo test.
7. Verifica il tipo di errore e il testo completo dell'errore.
8. Controlla il percorso del file e, se necessario, il numero di riga.
9. Assegna il file a un'applicazione, un plugin o un tema.
10. Controlla cosa è stato modificato immediatamente prima della prima comparsa dell'errore.
11. Non effettuare più modifiche di configurazione contemporaneamente.
12. Testa nuovamente lo stesso flusso dopo una modifica mirata.

Se non compare nulla nel registro degli errori #

Se nel caso dell'errore riproducibile non compare alcun nuovo elemento nel log degli errori di cPanel, ciò non significa automaticamente che non esista alcun problema tecnico.

A seconda della situazione, dovresti controllare altre fonti di diagnosi.

Ciò può includere:

• log interni dell'applicazione
• Registro di debug di WordPress
• Output del cronjob
• Log di accesso
• Risorse di CloudLinux
• Strumenti per sviluppatori del browser per problemi di frontend

La fonte di diagnosi corretta dipende dal livello in cui si verifica l'errore.

Quando dovresti contattare il supporto di CURIAWEB? #

Se hai un errore del sito web riproducibile, il log degli errori contiene un messaggio tecnico e non riesci a risolverne chiaramente la causa, documenta il caso nel modo più preciso possibile.

Per un'analisi sono particolarmente utili le seguenti indicazioni:

• dominio interessato
• URL o funzione interessata
• Data e ora esatta dell'errore
• messaggio di errore visibile nel browser
• voce di log degli errori pertinente e completa
• file e numero di riga interessati, se disponibili
• ciò che è stato modificato immediatamente prima del problema
• se l'errore è riproducibile
• versione PHP utilizzata, se rilevante

Non trasmettere password, token, chiavi API o altri dati di accesso confidenziali.

Riepilogo #

Il registro degli errori di cPanel sotto Valori misurati → Errore è uno dei più importanti strumenti di diagnostica per i problemi dei siti web lato server. Può mostrarti quando si è verificato un errore, quale file è stato coinvolto e quale messaggio tecnico è stato generato.

Analizza sempre una voce nel contesto del timestamp, del testo dell'errore, del percorso del file e, se applicabile, del numero di riga. Una singola parola come Errore fatale non è sufficiente per una diagnosi affidabile.

Messaggi tipici come Permesso negato, Dimensione della memoria consentita esaurita, Impossibile aprire il file richiesto o Chiamata a funzione non definita indicano diverse classi di errori e richiedono di conseguenza misure diverse.

Su WordPress, il percorso del file può spesso indicare se un plugin o un tema è coinvolto nell'errore. Tuttavia, questo è un indizio e non automaticamente la prova che tale componente sia l'unica causa.

Riproduci un errore nel modo più controllato possibile e controlla immediatamente dopo il registro degli errori. In questo modo puoi associare i messaggi attuali al problema specifico in modo molto più affidabile.

Se lì non compare alcun messaggio adatto, dovresti cambiare la fonte di diagnostica. I log di debug di WordPress, gli output dei cronjob, i log degli accessi e le risorse CloudLinux forniscono informazioni su altri livelli tecnici.

La regola più importante è: Non riparare la prima schermata di errore rossa sospetta. Riproduci l'errore, associa cronologicamente la voce di log corrispondente e procedi quindi in base alla segnalazione concreta.