Els registres permeten relacionar una petició fallida amb el codi PHP, però els errors visibles poden revelar rutes del servidor, fragments de base de dades, secrets i dades personals. A producció s’han d’escriure en una ubicació protegida mentre la visualització al navegador es manté desactivada.
Activa el registre durant una finestra d’incidència definida, reprodueix la fallada una vegada i retira després els fitxers que ja no calguin.
Revisa primer els registres de l’allotjament
cPanel, Plesk i molts allotjaments gestionats ja ofereixen registres de PHP-FPM i del servidor web. Anota’n la zona horària, la conservació i el domini i controlador PHP que cobreixen.
Si el registre existent conté l’error fatal, utilitza’l. Duplicar registres consumeix disc i recull més informació sensible.
No descarreguis el registre complet del compte quan n’hi ha prou amb uns minuts al voltant de la incidència.
Fes còpia de la configuració
Copia wp-config.php a una ubicació protegida i confirma quina és l’arrel activa de WordPress. En multilloc o configuracions desplaçades, un altre fitxer pot definir les constants de depuració.
Busca definicions existents de WP_DEBUG. Declarar dues vegades una constant genera avisos i fa confús el valor efectiu.
Si l’administració falla, no editis des de WordPress; utilitza un gestor de fitxers, SFTP o SSH autoritzat.
Configura el registre de WordPress
Col·loca aquestes definicions abans de la línia final «stop editing»:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOG escriu normalment a wp-content/debug.log. Recull els missatges de WordPress i PHP que arriben a aquesta configuració, no totes les fallades de PHP-FPM o del servidor web.
No activis display_errors en un web públic.
Tria una ubicació protegida
Quan sigui compatible, estableix a WP_DEBUG_LOG una ruta absoluta fora del directori públic:
define( 'WP_DEBUG_LOG', '/protected/path/wordpress-debug.log' );L’usuari PHP ha de poder escriure al fitxer, però cap visitant l’ha de poder descarregar. Utilitza una ruta facilitada per l’allotjament en lloc d’inventar permisos.
No facis mai escrivible per a tothom tot el directori.
Configura el registre de PHP
Alguns errors passen abans que es carregui WordPress. Des de cPanel, Plesk o la configuració PHP activa, habilita log_errors i selecciona un error_log protegit.
Confirma que PHP web i CLI utilitzen els fitxers de configuració previstos. Recarrega PHP només mitjançant controls compatibles.
No desis credencials en comentaris de php.ini ni en pàgines públiques de diagnòstic.
Reprodueix amb una hora exacta
Anota hora, URL o acció, estat de l’usuari i una referència que no contingui dades privades. Reprodueix una vegada i consulta només les línies noves.
Extreu:
classe de l'error
missatge
fitxer i línia
pila de crides
referència de la peticióOculta galetes, valors de consulta, noms de compte del servidor i dades personals abans de compartir.
Anonimitza sense destruir la prova
Conserva la classe de l’error, la ruta relativa del component, la línia, l’hora i un identificador generat. Substitueix correus, IP, tokens i valors de manera consistent per reconèixer referències repetides.
No confiïs en una expressió regular genèrica: pot deixar secrets dins d’arrays. Revisa manualment el fragment abans d’enviar-lo i confirma si el receptor necessita tota la traça o només l’error principal.
Controla el creixement
Un avís dins d’un bucle pot omplir el disc ràpidament. Vigila la mida i atura el registre si creix de manera anormal.
Utilitza la rotació de l’allotjament i una conservació limitada. No executis una neteja genèrica que pugui eliminar registres d’auditoria o d’altres aplicacions.
La manca de disc crea fallades noves, per tant el registre no s’ha de convertir en la incidència.
Desactiva i verifica
Després de reparar, posa WP_DEBUG a false o restaura la configuració anterior, elimina diagnòstics temporals i confirma que els visitants continuen sense veure errors.
Conserva només l’extracte anonimitzat necessari per documentar la incidència i elimina els fitxers segons la política establerta.
El manteniment recurrent hauria de centralitzar errors fatals protegits i alertar davant de signatures noves. Un registre segur aporta proves suficients per reparar sense convertir informació interna en contingut públic.