Soluciona el editor de bloques de WordPress que no carga

La mayoría de las veces, un editor de bloques de WordPress que no carga es un error de JavaScript: un solo script roto de un plugin o tema detiene toda la aplicación React, y el editor nunca termina de renderizarse. Abre la consola de desarrollador de tu navegador (F12, o Cmd+Option+I en Mac), recarga la pantalla de edición y lee el error en rojo. Casi siempre nombra el archivo que lanzó el fallo. Esa única línea te dice qué plugin desactivar, y normalmente puedes volver a escribir en menos de cinco minutos. Reinstalar WordPress, subir el memory_limit de PHP y cambiar al Editor Clásico son las tres sugerencias más comunes en internet, y las tres suelen ser la decisión equivocada.

Por qué el editor falla de la forma en que falla

El editor de bloques (Gutenberg) es una aplicación React de página única que se ejecuta dentro de wp-admin/post.php y post-new.php. WordPress encola una pila de paquetes de scripts —wp-blocks, wp-element, wp-editor, wp-edit-post— y la aplicación arranca a través de wp.domReady(). JavaScript deja de ejecutarse en la primera excepción no capturada. Así que si cualquier script encolado lanza un fallo mientras el editor se está inicializando, todo lo que viene después muere con él. Tu área de entrada cuidadosamente escrita se convierte en un panel blanco en blanco o en el mensaje “El editor ha encontrado un error inesperado”.

Por defecto, WordPress también concatena los scripts del admin en menos peticiones. Eso significa que el JS roto de un plugin puede arrastrar a scripts que no tienen nada que ver, cargados en el mismo paquete, y por eso el culpable no siempre resulta obvio solo por el comportamiento. La consola sí lo es.

El segundo modo de fallo tiene otra pinta: el editor carga, pero al guardar lanza “Error al actualizar. La respuesta no es una respuesta JSON válida”. Eso no es un problema de JavaScript. El editor se comunica con la REST API en /wp-json/wp/v2/, y espera recibir JSON limpio de vuelta. Si un plugin o el functions.php de tu tema emite un aviso, advertencia o fatal error de PHP antes del JSON —o un plugin de seguridad bloquea la ruta REST, o un plugin de redirecciones reescribe la URL— la respuesta queda contaminada y el editor no puede analizarla.

Cómo solucionarlo, lo más rápido primero

1. Lee la consola. Reproduce el fallo con las DevTools abiertas. Un error como Uncaught TypeError ... some-plugin/build/index.js apunta directamente al plugin culpable. Este único paso resuelve la mayoría de los casos y te ahorra ir descartando a ciegas.

2. Descarta el navegador. Haz una recarga forzada (Cmd/Ctrl+Shift+R), luego prueba con una ventana de incógnito con las extensiones desactivadas. Los bloqueadores de anuncios y las extensiones de privacidad a veces eliminan scripts del admin. Si funciona en incógnito, el problema es una extensión del navegador o una caché obsoleta, no tu sitio.

3. Comprueba la REST API directamente si viste el mensaje “no es una respuesta JSON válida”. Visita https://tusitio.com/wp-json/ en un navegador. Deberías obtener un muro de JSON. Si obtienes HTML, un 500 o una redirección al login, ese es tu problema: un plugin está rompiendo la respuesta REST, no el editor en sí.

4. Descarta tus plugins uno a uno. Desactívalos todos, confirma que el editor carga y luego reactívalos de uno en uno hasta que vuelva a romperse. Si estás completamente bloqueado fuera de wp-admin, hazlo por SFTP renombrando la carpeta:

mv wp-content/plugins wp-content/plugins_off

WordPress lo desactiva todo cuando la carpeta desaparece. Vuelve a ponerle el nombre original y luego ve moviendo los plugins dentro y fuera individualmente.

5. Prueba el tema. Cambia a Twenty Twenty-Four. Un tema que encola JS roto del editor o lanza PHP en functions.php produce los mismos síntomas.

6. Activa el log y lee el error real. Especialmente para los fallos de REST/JSON, activa el debug en wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

El fatal error se escribe en wp-content/debug.log con el archivo y el número de línea exactos. Si esa traza es densa —nombres de clase con namespaces, cadenas de require, un fatal enterrado bajo diez líneas de traza— pégala en nuestro descodificador de logs de errores de WordPress para ver, en términos claros, qué plugin y qué línea lo provocaron realmente. Esa es la diferencia entre “algo está roto” y “la línea 214 de este plugin concreto está rota”.

Si sospechas que la concatenación de scripts está ocultando al verdadero culpable, fuerza que cada script se cargue por separado para que el error de la consola apunte a un único archivo:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Qué no hacer

No instales el plugin Classic Editor y lo des por solucionado. No arregla nada: oculta el editor de bloques para que dejes de ver el error. El JavaScript roto o la respuesta REST rota siguen ahí, y volverán a morderte en el editor del sitio, en los widgets o la próxima vez que actualices. Diagnostica primero; recurre al Clásico solo si has tomado la decisión deliberada de dejar de usar bloques.

No subas el memory_limit de PHP por reflejo. Es el arreglo copiar-pegar favorito de internet, pero un editor en blanco rara vez es agotamiento de memoria. El agotamiento real lanza un fatal error específico —“Allowed memory size of N bytes exhausted”— que verás en debug.log. Si esa línea no está ahí, más memoria no cambia nada.

No reinstales el núcleo de WordPress. Los archivos del núcleo son idénticos byte a byte en cada instalación. Si el núcleo fuera el problema, todos los sitios de WordPress del planeta tendrían el editor roto ahora mismo. El fallo casi siempre está en tus plugins o en tu tema, y reinstalar el núcleo corre el riesgo de sobrescribir cosas sin arreglar nada.

No borres ni desactives a ciegas tu plugin de caché como primer paso. La minificación y concatenación agresivas de JS pueden romper el editor, así que vale la pena probarlo, pero mira la consola antes de ponerte a vaciar cachés al azar. Adivinar es como un arreglo de cinco minutos se convierte en una tarde entera.

¿Sigues atascado?

Si la consola está limpia, la REST API devuelve JSON válido y un descarte completo de plugins y tema sigue dejando el editor muerto, la respuesta casi siempre está en debug.log. Activa WP_DEBUG_LOG, reproduce el fallo una vez y pasa el fatal error resultante por el descodificador de logs de errores. La traza nombra el archivo: empieza por ahí.