WordPress mostra el missatge genèric d’error crític quan PHP s’atura a causa d’un error fatal no controlat. El text visible no permet saber si l’origen és un connector, el tema, un fragment de codi propi, la versió de PHP, un fitxer absent o un recurs exhaurit.
Abans de desactivar components, conserva el primer error i l’historial de canvis recents. La reparació fiable més ràpida comença pel fitxer i el recorregut d’execució que fallen, no pas per una successió de desactivacions a l’atzar.
Delimita la fallada
Anota l’URL exacta, l’hora, l’acció i si falla el web públic, l’administració, l’accés, les tasques programades o només una pàgina. Fes una única prova des d’una finestra privada.
Comprova si immediatament abans hi va haver una actualització, un desplegament, un canvi de PHP o una restauració. Registra les versions i l’operador sense buscar culpables.
No repeteixis una acció d’escriptura, com una importació o l’enviament d’un formulari, fins a saber si es va completar abans de l’error fatal.
Crea una còpia recuperable
Fes una còpia dels fitxers i de la base de dades abans d’editar. Si l’espai és gairebé ple, descarrega-la o utilitza una destinació externa en lloc de crear un altre arxiu gran al mateix compte.
Confirma que funcionen els accessos a cPanel, Plesk, SFTP o SSH i que coneixes l’arrel activa del web. Una còpia que no pots localitzar ni restaurar no és una via de reversió.
Evita sobreescriure l’única còpia coneguda amb una restauració que no s’ha provat.
Llegeix l’error fatal de PHP
Consulta el registre d’errors PHP de l’allotjament i busca la mateixa hora i petició. Normalment, l’error indica un fitxer i una línia, a més d’un missatge com ara funció inexistent, error de tipus o memòria exhaurida.
Dades que cal conservar:
tipus i missatge de l'error fatal
ruta del connector, tema o fitxer
línia i pila de crides
versió de PHP
petició i horaOculta els noms de compte del servidor, els secrets i les dades de clients abans de compartir el registre.
Activa un registre privat de WordPress si cal
Si els registres del servidor no són suficients, afegeix temporalment aquestes línies abans de «stop editing» a wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );No dupliquis constants ni mostris errors als visitants. Quan hagis recollit les proves, desactiva la depuració i protegeix o elimina el registre d’acord amb la política de conservació.
Aïlla el component assenyalat
Si l’error apunta a un connector, canvia el nom només del seu directori des del gestor de fitxers o per SFTP. Si apunta al tema actiu, comprova que hi ha instal·lat un tema predeterminat compatible abans de canviar-lo.
En un connector de fragments personalitzats, desactiva únicament el fragment implicat mitjançant el seu mode segur documentat o, després d’una còpia, des de la base de dades.
No canviïs el nom de tot el directori de connectors si hi ha proves disponibles. Si no n’hi ha, prepara abans un ordre controlat de reactivació.
Comprova PHP i les dependències absents
Una funció inexistent pot indicar que no s’ha carregat un connector necessari o que una actualització ha deixat fitxers incomplets. Un error de tipus pot revelar una incompatibilitat amb la versió actual de PHP.
Compara els requisits de WordPress, del connector o tema i de PHP. Si els checksums o el recompte de fitxers indiquen un desplegament incomplet, reinstal·la exactament el paquet oficial corresponent.
No descarreguis codi substitutiu de repositoris dubtosos ni reverteixis una correcció de seguretat sense un pla posterior.
Aplica la reparació mínima
Actualitza o reverteix un sol component, corregeix el codi propi, restaura la dependència absent o tria una versió compatible de PHP segons les proves. Mantén el canvi reversible i documenta’l.
Buida OPcache i els recursos generats mitjançant els controls compatibles de l’allotjament. Una memòria cau de bytecode antiga pot mantenir actiu l’error anterior.
No editis el nucli de WordPress per amagar el problema.
Comprova més que la pàgina afectada
Prova pàgines públiques, accés, administració, editor, mitjans, tasques programades i l’acció original. Revisa si apareixen nous errors fatals i comprova el correu o les integracions externes vinculades.
Un servei recurrent hauria de vigilar els errors fatals de PHP i provar les actualitzacions abans de producció. La reparació urgent acaba quan s’entén la causa, funciona el recorregut afectat i es conserva una via de reversió; no simplement quan desapareix el missatge genèric.