Uno Errore interno del server è uno degli errori di WordPress più fastidiosi, perché all'inizio il messaggio rivela ben poco sulla causa effettiva. Il server web ha ricevuto la richiesta, ma non è riuscito a elaborarla correttamente a causa di un problema interno.
Su un sito WordPress, tra le altre cose, possono verificarsi errori PHP, plugin, temi, regole errate in .htaccess, un limite di memoria esaurito o problemi successivi a una modifica o a un aggiornamento.
È quindi importante non confondere lo stato HTTP 500 con la causa effettiva dell'errore.
Breve spiegazione: Un errore 500 non significa automaticamente che WordPress sia corrotto. Verifica prima quando e dove si verifica l'errore. Controlla poi i log degli errori e le modifiche apportate immediatamente prima. Solo sulla base di queste informazioni dovresti [esaminare] plugin, tema, PHP,
.htaccesso esaminare specificamente altri componenti.
Cosa significa l'errore HTTP 500 Internal Server Error? #
I codici di stato HTTP descrivono il risultato di una richiesta tra client e server.
Un codice di stato della serie 500 indica un errore lato server. In caso di Errore interno del server il server non è riuscito a completare la richiesta come previsto a causa di un errore interno.
Il messaggio descrive quindi inizialmente solo il risultato, e non la sua causa specifica.
In WordPress possono essere coinvolti, ad esempio, i seguenti ambiti:
- PHP
- WordPress-Core
- Plugin
- Temi o child-theme
.htaccessregole di riscrittura- Limite di memoria PHP
- File e autorizzazioni dei file
- Configurazione del server
Che aspetto ha un errore 500? #
A seconda del browser, del server web e dell'ambiente di hosting, il messaggio visibile potrebbe apparire diverso.
Le denominazioni tipiche sono ad esempio:
Errore interno del server
o semplicemente:
ERRORE HTTP 500
A volte, anziché una pagina 500 esplicita, compare una pagina in gran parte vuota o un altro messaggio di errore generico.
Ecco perché è utile considerare lo stato HTTP effettivo e i log del server esistenti.
1. Verificare se si tratta effettivamente di un errore HTTP 500 #
Prima di modificare WordPress, dovresti determinare il tipo di errore nel modo più preciso possibile.
Un errore HTTP 500 è diverso da:
- 404 Non Trovato
- 403 Proibito
- 502 Bad Gateway
- 503 Servizio non disponibile
- Gateway Timeout 504
- Errore DNS
- Errore del certificato SSL
- Errore durante la connessione al database
Se il sito web in generale non è affatto raggiungibile, dovresti prima effettuare la diagnosi più generale sotto Sito WordPress non raggiungibile: verificare le cause in modo sistematico usare.
2. Quali aree del sito web sono interessate? #
Non testare solo la homepage.
Apri ad esempio le seguenti sezioni:
Ciò consente di circoscrivere ulteriormente l'errore.
Le situazioni possibili sono:
- l'intero sito web mostra l'errore 500
- solo l'area di amministrazione mostra l'errore 500
- è interessato solo il frontend
- è interessata solo una singola pagina
- L'errore si verifica solo con una determinata azione
- L'errore si verifica solo sporadicamente
Un errore che si verifica esclusivamente durante l'invio di un determinato modulo, ad esempio, ha un punto di partenza diverso rispetto a un sito Web che risponde con HTTP 500 a ogni richiesta.
3. Cosa è stato modificato immediatamente prima dell'errore? #
La correlazione temporale è uno degli indizi più importanti nella ricerca degli errori.
Valuta se immediatamente prima del verificarsi dell'errore, ad esempio:
- WordPress è stato aggiornato
- è stato installato un plugin
- è stato attivato un plugin
- un plugin è stato aggiornato
- un tema è stato aggiornato
- il tema è stato cambiato
- PHP è stato modificato
.htaccessè stato modificatowp-config.phpè stato modificato- è stato inserito il codice PHP
- un frammento di codice è stato attivato
Se l'errore è iniziato immediatamente dopo una modifica specifica, dovresti iniziare la diagnosi da lì.
Consiglio pratico: Durante la ricerca degli errori, modifica sempre e se possibile solo un componente alla volta. Altrimenti il sito web potrebbe sì riprendere a funzionare improvvisamente, ma la causa reale rimarrebbe sconosciuta.
4. Controllo dei log degli errori #
In caso di errore HTTP 500, i registri degli errori del server o di PHP sono spesso molto più utili del messaggio visibile nel browser.
Un registro degli errori può contenere, ad esempio, indicazioni su:
- Errore fatale di PHP
- Errore di sintassi
- funzioni o classi inesistenti
- Superamento della memoria
- File di plugin
- File di tema
- Problemi con le estensioni PHP
- Problemi di file o percorso
Sono fondamentali soprattutto le voci il cui timestamp corrisponde al verificarsi dell'errore.
Se l'errore è stato generato, ad esempio, alle 14:32, i vecchi avvisi di diversi giorni prima non sono solitamente il primo punto di partenza.
5. Valutare il percorso del file nel registro degli errori #
Il percorso del file menzionato in un messaggio di errore PHP può fornire un indizio importante.
Un percorso come:
wp-content/plugins/beispiel-plugin/...
indica che il codice di un plugin è coinvolto nell'errore.
Un percorso come:
wp-content/themes/beispiel-theme/...
conduce invece verso il tema o il tema figlio.
Tuttavia, un percorso di file non è sempre la prova completa della causa effettiva. Un componente può generare un errore che diventa visibile solo quando viene richiamato il codice di un altro componente.
Utilizzare il debug di WordPress #
Se i log del server esistenti non sono sufficienti, le funzioni di debug di WordPress possono fornire ulteriori informazioni.
Le costanti importanti sono:
WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY
Con la relativa configurazione, WordPress può mostrare i messaggi di errore, ad esempio, in:
wp-content/debug.log
registrare.
Tratteremo in modo approfondito come utilizzare il debug in modo controllato su un sito web in produzione e come leggere correttamente i log su Attivare il debug di WordPress e utilizzare i log degli errori.
Attenzione: I messaggi di errore PHP dettagliati non dovrebbero essere visualizzati pubblicamente in modo permanente su un sito web di produzione. I registri degli errori possono contenere percorsi interni e altre informazioni tecniche.
7. Verificare i plugin come causa di un errore 500 #
I plugin sono tra le possibili cause di un errore HTTP 500 in WordPress.
Un plugin è particolarmente sospetto se l'errore si verifica immediatamente dopo:
- Installazione
- Attivazione
- Aggiorna
- Modifica della sua configurazione
è iniziato.
Se l'area di amministrazione di WordPress è ancora accessibile, disattiva prima il relativo plugin e testa nuovamente la richiesta difettosa.
Se l'errore scompare, si dovrebbe chiarire successivamente perché il plugin ha causato il problema.
8. Disattivare il plugin se l'area di amministrazione non è accessibile #
Se un plugin causa l'errore e anche la bacheca di WordPress non è più accessibile, il plugin in questione può essere disattivato tramite l'accesso ai file, avendo la necessaria esperienza.
I plugin si trovano solitamente in:
wp-content/plugins/
Un elenco di plugin potrebbe ad esempio essere:
wp-content/plugins/beispiel-plugin/
Se questa directory viene rinominata temporaneamente, WordPress non potrà più caricare il plugin dal suo percorso precedente.
Questo metodo dovrebbe essere utilizzato in modo mirato quando il plugin interessato è noto o quantomeno fortemente sospetto.
9. Se non è noto un plugin specifico #
Se non è noto alcun plugin specifico come causa, potrebbe essere necessaria una verifica sistematica dei conflitti.
In questo modo i plugin vengono disattivati in modo controllato e poi riattivati gradualmente finché non è possibile riprodurre l'errore.
L'obiettivo non è semplicemente far funzionare in qualche modo il sito web senza plugin. Ciò che è decisivo è identificare il componente o la combinazione effettivamente coinvolta.
Puoi trovare la procedura dettagliata su Rilevare e risolvere i conflitti di plugin o temi in WordPress.
10. Verifica dei temi come causa #
Anche il tema attivo può contenere codice PHP che attiva un errore HTTP 500.
Ciò è particolarmente rilevante se l'errore si verifica dopo:
- un aggiornamento del tema
- un cambio di tema
- di una modifica del child theme
- di una modifica a
functions.php
si è verificato.
Se l'area di amministrazione è accessibile, è possibile passare temporaneamente a un tema standard di WordPress recente e idoneo a scopo diagnostico.
Se il sito web dovesse tornare a funzionare grazie a ciò, sarà necessario esaminare più attentamente il tema attualmente attivo.
11. Esamina il tema manualmente #
Se l'area di amministrazione non è raggiungibile, i file del tema si trovano solitamente in:
wp-content/themes/
La directory del tema attivo può essere temporaneamente rinominata per una diagnosi mirata.
Affinché WordPress possa successivamente passare a un altro tema, è tuttavia necessario che sia installato un altro tema idoneo.
Importante: Un cambio di tema può alterare notevolmente l'aspetto e determinate funzionalità del sito web. In questo caso serve a scopo diagnostico e non deve essere confuso con una decisione di design definitiva.
12. .htaccess come possibile causa #
Sulle configurazioni di server web basati su Apache o compatibili, WordPress può il file:
.htaccess
da utilizzare per le regole di rewrite e ulteriori configurazioni.
Direttive o regole errate possono causare un errore HTTP 500 in determinate condizioni.
Ciò può avvenire, ad esempio, dopo:
- elaborazione manuale
- Modifiche apportate da un plugin
- Inserimento di regole del server non appropriate
- Migrazione tra diversi ambienti server
verificarsi.
13. Non cancellare semplicemente il file .htaccess #
Se .htaccess se si sospetta che sia la causa, dovresti prima effettuare un backup del file esistente.
Una possibile diagnosi consiste nel rinominarla temporaneamente, ad esempio in:
.htaccess-backup
e successivamente testare nuovamente il sito web.
Se il sito web funziona di nuovo dopo, questo è un forte indizio che una regola nel file precedente era coinvolta.
Attenzione: Un'
.htaccessIl file può contenere anche regole di sicurezza, reindirizzamenti o altre configurazioni personalizzate oltre ai permalink di WordPress. Pertanto, non sovrascriverlo senza aver prima effettuato una verifica.
14. Rigenerare le regole deipermalink di WordPress #
Quando l'area di amministrazione sarà di nuovo accessibile e verrà utilizzata una normale configurazione dei permalink di WordPress, le regole di rewrite potranno essere modificate tramite:
Impostazioni → Permalink
essere riscritto salvando le impostazioni.
Ciò è particolarmente rilevante in caso di problemi con i permalink e il rewrite.
Se il tuo effettivo problema riguarda l'errore HTTP 404, troverai la procedura dettagliata in Risolvere l'errore 404 in WordPress e riparare i permalink.
15. Errore dopo una modifica della versione di PHP #
Se l'errore HTTP 500 si è verificato immediatamente dopo un cambio di versione di PHP, è necessario verificare la compatibilità dei componenti di WordPress.
Ad esempio, un vecchio plugin o tema potrebbe contenere codice PHP che non funziona più con una versione più recente di PHP.
Al contrario, i plugin moderni possono richiedere funzionalità che non sono disponibili con una versione di PHP molto vecchia.
Pertanto, non passare casualmente da una versione di PHP all'altra.
Tratteremo la procedura di sicurezza in Modificare la versione di PHP per WordPress e verificare la compatibilità.
16. Il limite di memoria di PHP come causa #
Se un processo PHP richiede più memoria di quella consentita, l'esecuzione può interrompersi con un errore fatale.
Nel log degli errori compare quindi spesso un messaggio con una componente come:
Dimensione di memoria consentita ... esaurita
Un tale errore può manifestarsi anche come HTTP 500, a seconda dell'ambiente.
Ciò non significa tuttavia automaticamente che il limite di memoria debba semplicemente essere impostato il più alto possibile.
Un elevato consumo di memoria può indicare, ad esempio, un plugin, un'operazione complessa o un errore di programmazione.
Trattiamo la diagnosi esatta sotto Limite di memoria PHP in WordPress: individuare e risolvere gli errori.
17. Differenza tra WP_MEMORY_LIMIT e PHP memory_limit #
In caso di problemi di memoria, è importante non confondere i diversi limiti.
PHP possiede tra le altre l'impostazione:
limite di memoria
WordPress conosce inoltre costanti come:
WP_MEMORY_LIMIT
e per determinati processi amministrativi:
WP_MAX_MEMORY_LIMIT
Tuttavia, un valore inserito in WordPress non può annullare arbitrariamente un limite lato server superiore.
Pertanto, si dovrebbe innanzitutto stabilire quale valore limite sia stato effettivamente raggiunto.
18. Errore di sintassi nel codice PHP #
Un solo errore di sintassi può fare in modo che PHP non riesca più a eseguire correttamente un file.
Ciò può accadere, ad esempio, se immediatamente prima del codice in:
functions.php
wp-config.php
o sia stato inserito o modificato un altro file PHP.
Anche un frammento di codice difettoso può causare un errore fatale.
Se l'errore si verifica subito dopo una modifica manuale del codice, questa modifica dovrebbe essere verificata per prima e, se necessario, ripristinata allo stato precedente funzionante.
19. Errori PHP tipici nel log #
Durante la diagnosi possono verificarsi diversi tipi di errori PHP.
Ad esempio, sono particolarmente rilevanti segnalazioni come:
Errore fatale PHP
Errore non gestito
Chiamata a funzione non definita
Classe ... non trovata
Dimensione di memoria consentita ... esaurita
Il messaggio esatto insieme al percorso del file e al numero di riga fornisce molte più informazioni rispetto al generico stato HTTP 500.
20. Errore dopo l'aggiornamento di WordPress #
Se l'errore si verifica immediatamente dopo un aggiornamento del core di WordPress, non dovresti dare per scontato automaticamente che WordPress stesso sia difettoso.
Un aggiornamento può, ad esempio, risolvere un'incompatibilità esistente con:
- un plugin più vecchio
- un tema precedente
- proprio codice
- di una versione PHP non idonea
rendere visibile.
Controlla quindi prima i log degli errori e i componenti coinvolti.
21. Aggiornamento di WordPress incompleto #
Se un aggiornamento viene interrotto, in alcuni casi i file potrebbero non essere aggiornati completamente.
Ciò può causare un'installazione non consistente.
Prima di sostituire i file del core di WordPress, tuttavia, bisogna chiarire se ci siano effettivamente indizi di file del core mancanti o danneggiati.
Particolarmente importante è la distinzione tra WordPress Core e:
wp-content/
Lì si trovano tra le ancore plugin, temi e caricamenti. Questa area non deve essere sovrascritta avventatamente durante una riparazione del Core.
22. File danneggiati o mancanti #
Un errore HTTP 500 può verificarsi anche se i file PHP necessari sono mancanti, danneggiati o non leggibili.
Le possibili cause possono essere, ad esempio:
- caricamento interrotto
- aggiornamento non riuscito
- cancellazione manuale
- migrazione incompleta
- ripristino difettoso
In tali casi, il log degli errori contiene spesso indizi sul file interessato.
23. Controllare i permessi dei file, ma senza modificarli ciecamente #
Permessi di file o directory non idonei possono impedire al server web di leggere o eseguire correttamente i file necessari.
Tuttavia, la configurazione specifica dipende dall'ambiente di hosting.
Attenzione: Non impostare in modo indiscriminato tutti i file o le directory su autorizzazioni ampiamente aperte come
777, solo per correggere un errore. Questo può creare un problema di sicurezza significativo e non costituisce una riparazione a regola d'arte.
Il proprietario e i permessi non sono la stessa cosa #
Oltre ai classici permessi dei file, a livello di server può anche essere rilevante a quale utente o gruppo appartengono i file.
In una normale gestione di WordPress nell'hosting, questo non dovrebbe essere modificato manualmente in modo casuale.
I problemi possono verificarsi, ad esempio, dopo migrazioni manuali del server o trasferimenti di file con diritti utente non idonei.
25. Estensioni PHP e ambiente server #
I plugin o i temi possono richiedere determinate estensioni PHP.
Se manca un'estensione necessaria, il software può reagire a seconda della programmazione con un messaggio comprensibile o interrompersi con un errore PHP.
Il registro degli errori può quindi, ad esempio, indicare una funzione o una classe inesistente.
Non installare o attivare le estensioni PHP a casaccio. Verifica prima i requisiti del software interessato.
26. Errore solo per una determinata azione #
Un errore HTTP 500 non deve necessariamente verificarsi a ogni caricamento di pagina.
L'errore potrebbe comparire solo su:
- Salvataggio di un post
- Apertura di una pagina specifica
- Importazione di grandi quantità di dati
- Esporta
- Creazione di un backup
- Esecuzione di un determinato plugin
- Invio di un modulo
- Azione WooCommerce
In questo caso l'azione concreta è una parte importante della diagnosi.
Riproduci l'errore in modo controllato, se possibile, e verifica immediatamente dopo le relative voci di registro.
27. Errore solo nell'area di amministrazione di WordPress #
Se il frontend funziona, ma determinate aree sotto:
/wp-admin/
generare un errore HTTP 500, si dovrebbe esaminare quali componenti siano in esecuzione specificamente lì.
Un plugin, ad esempio, può caricare codice aggiuntivo esclusivamente durante le azioni amministrative.
Anche un maggiore fabbisogno di memoria di determinati processi di backend può giocare un ruolo.
28. Errore solo nel frontend #
Se l'area di amministrazione funziona ma il frontend mostra un errore HTTP 500, potrebbero essere coinvolti, tra le altre cose, il tema, i template, i plugin del frontend o determinati contenuti.
Testa diverse pagine e verifica se l'errore si presenta ovunque o solo su determinati tipi di pagina.
29. Errore solo su una singola pagina #
Se quasi l'intero sito web funziona e solo un determinato URL genera un errore HTTP 500, un guasto globale del server è piuttosto improbabile.
Esamina quindi in particolare:
- Contenuto della pagina
- blocchi utilizzati
- Codici brevi
- Modello
- Costruttore di pagine
- Formulare
- Plugin che si attivano solo su questa pagina
Un'occhiata al log degli errori subito dopo aver richiamato questo URL è particolarmente utile.
30. Processi molto lunghi e timeout #
Una richiesta PHP complessa può raggiungere i limiti di tempo tecnici.
Ciò può verificarsi, ad esempio, in:
- grandi importazioni
- Backup
- Elaborazione delle immagini
- operazioni di dati estese
- richieste API esterne
verificarsi.
Prima di aumentare semplicemente i tempi di esecuzione, bisognerebbe verificare perché il processo richiede così tanto tempo.
31. Interpretare correttamente i limiti delle risorse #
A seconda dell'ambiente di hosting, a un sito Web sono disponibili risorse definite.
Il raggiungimento di un limite può influenzare le richieste. Tuttavia, un limite di risorsa non è automaticamente la causa effettiva.
Ad esempio, un singolo plugin difettoso può consumare una quantità insolita di CPU o memoria.
La domanda giusta non è quindi solo:
Quale limite è stato raggiunto?
ma anche:
Perché è stato raggiunto questo limite?
La cache di solito non causa un errore fatale PHP #
I sistemi di cache possono memorizzare temporaneamente una pagina di errore generata in precedenza o mostrare uno stato obsoleto dopo una riparazione.
La cancellazione della cache può quindi essere utile dopo la risoluzione di un errore.
Ma non sostituisce la diagnosi di un errore lato server.
Consiglio pratico: Se il log degli errori indica un errore fatale PHP specifico, concentrati prima su quell'errore. „Cancellare la cache“ non è una riparazione per codice PHP difettoso.
33. Plugin di sicurezza e regole del server #
Le soluzioni di sicurezza possono modificare le regole del server o di riscrittura oppure influenzare gli accessi.
Se si verifica un errore HTTP 500 immediatamente dopo una modifica a una soluzione di sicurezza, è opportuno verificare anche tale configurazione.
Tuttavia, non disattivare i meccanismi di sicurezza in modo indiscriminato e permanente senza conoscerne le conseguenze.
34. Controllare le regole di inoltro #
Regole difettose in .htaccess o altri livelli di configurazione possono parimenti causare problemi.
Soprattutto dopo le migrazioni, dovresti verificare se le vecchie regole per:
- Domini
- Elenchi
- HTTPS
- www o non-www
- Funzioni di sicurezza
ancora adempiere alla nuova ambientazione.
35. Errore dopo una migrazione del sito web #
Se l'errore HTTP 500 si verifica immediatamente dopo un trasferimento, potrebbero esserci ulteriori cause:
- altra versione PHP
- altra configurazione PHP
- incompatibile
.htaccess-Regole - file mancanti
- trasmissione incompleta
- diversi moduli server
- permessi di file non corretti
Confronta quindi il vecchio e il nuovo ambiente prima di reinstallare WordPress.
36. Non reinstallare WordPress troppo avventatamente #
Una reinstallazione di WordPress non è solitamente il primo passo sensato in caso di errore HTTP 500.
Se, ad esempio, un plugin causa un errore di sintassi, una reinstallazione del CMS WordPress non cambierà nulla per quel plugin.
Allo stesso modo, una nuova installazione non corregge una versione di PHP non idonea o una regola del server personalizzata errata.
La diagnosi dovrebbe quindi precedere una nuova installazione.
Non ripristinare il backup automaticamente #
Anche un ripristino completo non è la prima misura migliore per ogni errore 500.
Se, ad esempio, il registro degli errori menziona chiaramente un singolo plugin, la sua disattivazione può essere molto più mirata.
Nei siti web dinamici, un ripristino può inoltre sovrascrivere dati più recenti.
Un backup è particolarmente prezioso quando:
- I file sono stati danneggiati
- una modifica non possa essere annullata correttamente
- deve essere ripristinato uno stato noto e funzionante
- sono state apportate modifiche importanti a file o database
38. Errore 500 dopo il ripristino del backup #
Se l'errore si verifica solo dopo un ripristino, bisogna verificare se:
- tutti i file sono stati completamente ripristinati
- Il database e i file devono appartenere allo stesso stato
- la versione di PHP va bene
.htaccesssi adatta all'attuale ambiente server- i permessi dei file sono corretti
Un ripristino è affidabile solo se lo stato ripristinato è tecnicamente consistente.
39. Controllare nuovamente il registro degli errori dopo ogni modifica #
Quando hai risolto una causa presunta, ricarica l'URL interessato e controlla quindi il log.
In questo modo puoi determinare:
- se lo stesso errore si verifica di nuovo
- se un nuovo errore diventa visibile
- se la richiesta viene ora elaborata con successo
In catene di errori complesse, dopo la risoluzione del primo errore, potrebbeerne rendersene visibile un secondo.
40. HTTP 500 e errore critico di WordPress #
Un errore irreversibile di PHP può manifestarsi sia come un errore HTTP 500 generico sia tramite il sistema di gestione degli errori nativo di WordPress.
Se WordPress segnala espressamente che si è verificato un errore critico sul sito web, dovresti considerare anche la modalità di recupero e l'e-mail dell'amministratore.
Per questo abbiamo le istruzioni separate WordPress mostra una pagina bianca o un errore critico: cosa fare?.
41. Ordine sistematico in caso di errore 500 di WordPress #
- Annotare il messaggio di errore esatto e l'URL interessato.
- Verificare quali aree del sito web sono interessate.
- Determinare cosa è stato modificato immediatamente prima dell'errore.
- Controllare i registri degli errori al momento opportuno.
- Valutare il percorso file specificato e il tipo di errore.
- Utilizzare il debug di WordPress in modo controllato, se necessario.
- Controlla miratamente un plugin o un tema sospetto.
.htaccessindagare se vi sono indicazioni.- Controlla la versione PHP.
- Controllare il limite di memoria se il log mostra un superamento della memoria.
- Controllare le modifiche al codice manuali.
- Esaminare file e permessi solo in caso di fondato sospetto.
- Risolvere la causa in modo mirato.
- Ritesta la richiesta interessata.
- Controllare nuovamente il registro degli errori.
- Verificare definitivamente il frontend e l'area di amministrazione.
Cosa è meglio non fare in caso di errore 500 #
- Non reinstallare subito WordPress
- non eliminare tutti i plugin a caso
- non modificare contemporaneamente PHP, tema e plugin
.htaccessnon sovrascrivere senza backup- Non applicare ciecamente i permessi dei file a
777mettere - Non aumentare arbitrariamente il limite di memoria senza una diagnosi
- non attivare estensioni PHP casuali
- non importare un vecchio stato del database senza verifica
- non mostrare messaggi di errore dettagliati pubblicamente in modo permanente
- Non copiare ciecamente le regole del server o della sicurezza da guide esterne
43. Quali informazioni aiutano il supporto di CURIAWEB? #
Se il tuo sito WordPress su CURIAWEB mostra un errore HTTP 500, informazioni il più possibile specifiche aiutano nella diagnosi.
Comunica in particolare:
- dominio interessato
- URL interessata
- messaggio di errore preciso
- momento approssimativo dell'errore
- se l'errore si verifica in modo permanente o sporadico
- se il frontend e l'area di amministrazione sono interessati
- quale modifica sia stata fatta immediatamente prima
- se plugin, temi o PHP sono stati recentemente aggiornati o modificati
- voce di log rilevante, se presente
Un breve e pertinente frammento di log con timestamp è solitamente più utile di un registro errori completo con migliaia di voci meno recenti.
Non inviare password non richieste.
Riepilogo #
Uno Errore interno del server significa che il server non è riuscito a elaborare una richiesta a causa di un errore interno. Il codice di stato in sé non dice ancora quale componente di WordPress ne sia responsabile.
Su WordPress, errori PHP, plugin, temi, .htaccess, versioni PHP incompatibili, problemi di memoria e file corrotti tra le possibili cause.
Il passaggio diagnostico più importante è quindi l'analisi del log degli errori appropriato. Il tipo di errore, il percorso del file, il numero di riga e l'ora forniscono spesso indizi molto più concreti rispetto alla pagina di errore 500 visibile.
Sostituisci quindi solo il componente per cui esiste un sospetto concreto ed esegui nuovamente il test dopo ogni modifica. Una diagnosi sistematica è più affidabile e sicura rispetto a reinstallare WordPress, disattivare tutti i plugin o modificare le impostazioni del server sulla base di mere supposizioni.
