Moodle errore 500: estrarre il fatal o l’exception reale dietro la risposta generica del server.
Correliamo orario dell’errore con log web server e PHP, poi isoliamo plugin, tema, DB e deploy recenti.
Risposta HTTP 500 su URL o webservice: il client vede solo Internal Server Error.
Qui il web server ammette il fallimento con status 500. La diagnosi correla access/error log e stack PHP sullo stesso timestamp.
Checklist per trasformare un 500 in un errore nominato.
Orario esatto
Annota UTC/local, URL, metodo HTTP e se e globale o su una sola route.
Log PHP
Apri php-fpm/php_errors nello stesso minuto: fatal, uncaught, allowed memory.
Cambio recente
Deploy plugin, upgrade Moodle, cambio PHP, certificati, reverse proxy.
Dove guardare: access/error del virtual host.
Codice 500 in access.log + riga in error.log (upstream, script, request_id) nello stesso secondo.


Dove guardare: pool slowlog e error log PHP.
Fatal class not found, type error, memory: qui sta il file colpevole.
Dove guardare: debug solo in staging.
In prod preferiamo log file; in staging si alza developer per riprodurre.


Possibile causa: plugin incompatibile dopo upgrade.
Stack su local/ o mod_/: confronta versione plugin vs Moodle.
Possibile causa: override tema rotto.
500 su alcune pagine layout: tema custom off in staging.


Possibile causa: query o connessione DB.
Too many connections, deadlock, schema mismatch post-upgrade.
Possibile causa: moodledata non scrivibile.
Fallisce cache/session: path e user del pool PHP.


Possibile causa: memory_limit su report pesanti.
500 su export con memory exhausted.
Possibile causa: timeout proxy minore di PHP.
Intermittente sotto carico: allinea proxy_read_timeout.


Correzione: isolamento del componente che alza HTTP 500.
Disabilita plugin via CLI/cartella, non drop DB.
Correzione: config.php e PHP allineati.
dataroot, permission, opcache dopo deploy.


Correzione: upgrade XMLDB incompleti.
Completa upgrade o rollback versionato del plugin.
Verifica smoke sulle URL del 500.
Login, corso, attivita critica, API cliente.


Rotazione log e alert sui 500.
Senza telemetria il prossimo incidente e di nuovo cieco.
Root cause documentata, non solo reboot.
Atlas Learning chiude con test di non regressione.


Sul 500 correlaziono status code, upstream e stack: senza quella triade resto cieco.
Web server, PHP e ultimo deploy mi dicono dove entrare; solo dopo propongo un intervento.
Atlas Learning opera come partner tecnico: leggiamo log, riproduciamo il caso e interveniamo sul livello responsabile, senza sostituirci alla vostra governance di piattaforma.
Cosa dicono i clienti che lavorano con Atlas Learning.
Le recensioni vengono mostrate dinamicamente tramite Trustindex.
Domande frequenti su Moodle errore 500.
Debug in produzione?
Meglio log file. Debug a schermo espone dati.
E sempre un plugin?
Spesso no: anche DB, permessi, proxy, limiti PHP.
Serve SSH?
Utile per i log. Altrimenti export da chi gestisce hosting.
Rollback subito?
Solo con cambiamento identificato.
Il sito o un’API Moodle risponde 500?
Manda status HAR o access log, stack PHP e change-list del deploy.