El editor de WordPress se bloquea: conflictos de plugins y cómo identificar al culpable

enero 31, 2026 • febrero 3, 2026 • Lectura: 25 min • Views: 10

¿Te fue útil?

Si tu editor de WordPress se bloquea, se recarga, queda en blanco o se queda atascado en un spinner, no estás teniendo “un mal día con el navegador”. Estás frente a una cadena de fallos: error de JavaScript → petición REST falla → autosave muere → el editor se rinde. O fatales de PHP detrás del telón. O un plugin peleando con otro plugin con la sutileza de dos niños en una sala de servidores.

La buena noticia: la mayoría de los “bloqueos” del editor son diagnosticables en menos de una hora si trabajas como un operador. Reproduce. Aísla. Lee los registros. Cambia una variable a la vez. Luego señala al culpable con pruebas, no sensaciones.

Guía rápida de diagnóstico

Esta es la versión “tengo cinco minutos y un stakeholder viéndome compartir pantalla”. El objetivo no es arreglarlo todo. El objetivo es localizar la capa que está fallando: JS del navegador, REST/AJAX de WordPress, PHP, base de datos o infraestructura.

Primero: determina si es JavaScript del cliente o PHP del servidor

Abre las DevTools del navegador → Consola. Si ves errores en rojo (TypeError, “Cannot read properties”, scripts bloqueados, CORS), estás en el terreno del JS.
Abre DevTools → Network y recarga el editor. Filtra por wp-json y admin-ajax.php. Si esas llamadas devuelven 401/403/500 o se agotan, estás en el terreno de API/PHP.

Segundo: reproduce en una sesión limpia

Ventana de incógnito/privada (sin extensiones, cookies limpias). Si funciona allí, tienes problemas de caché de autenticación/sesión, una extensión del navegador rompiendo el JS del admin, o un caché de borde agresivo.
Cambia temporalmente a un tema por defecto. Los temas pueden y suelen envenenar las pantallas del admin vía scripts globales.

Tercero: aísla conflictos de plugins agresivamente

Desactiva todos los plugins, confirma la estabilidad del editor y luego reactívalos en lotes (búsqueda binaria). No actives 37 plugins uno por uno a menos que disfrutes del sufrimiento.
Si desactivar lo arregla, ahora tienes un conflicto, no “WordPress siendo WordPress”. Afina la búsqueda.

Cuarto: revisa los registros con intención

Registro de errores de PHP para fatales, agotamiento de memoria, funciones indefinidas.
Registro de depuración de WordPress para avisos/notices que correlacionen con la carga del editor.
Registros del servidor web para 500s, 403s, timeouts en endpoints REST.

Quinto: confirma la corrección con una reproducción limpia

Edita una entrada, fuerza un autosave, inserta un bloque, abre bloques reutilizables/patrones, publica.
Observa Network y Console por nuevos errores. Las soluciones que “parecen estar bien” pero dejan errores en la consola son incidentes futuros con bigote falso.

Una idea parafraseada a menudo atribuida al pensamiento SRE (parafraseada): La esperanza no es una estrategia; la fiabilidad viene del diseño deliberado y la verificación. — común en cultura de operaciones y fiabilidad.

Qué significa realmente “bloqueo del editor” en WordPress

“Bloqueo” es una palabra de usuario. WordPress no ejecuta un único proceso de editor que haga segfault; es una aplicación web. Cuando los usuarios dicen “el editor se bloquea”, generalmente significa una de estas cosas:

Pantalla en blanco (white screen of death) en la ruta del editor porque hay fatales de PHP, o la salida se corrompe antes de enviar respuestas JSON.
El editor de bloques carga pero queda no receptivo debido a una excepción de JavaScript, a menudo por un plugin que inyecta scripts, bloquea scripts core o genera conflictos en dependencias de React.
Spinner de carga atascado porque llamadas a la REST API fallan (401/403/500), o las peticiones son bloqueadas por reglas de WAF/CDN.
Fallos de autosave que se encadenan en “Actualización fallida” y finalmente hacen que el editor parezca roto.
El editor carga pero no puede publicar por permisos, nonce, autenticación REST o filtros de contenido que devuelven respuestas inválidas.

Los conflictos de plugins son comunes porque los plugins pueden alterar el comportamiento del admin mediante hooks, encolar scripts, registrar bloques, filtrar respuestas REST y modificar el procesamiento de contenido. Ese poder es la ventaja. También es el riesgo.

Broma corta #1: Los plugins son como compañeros en una oficina abierta—individualmente bien, colectivamente ruidosos, y uno de ellos sigue tocando tus ajustes.

Hechos y contexto histórico (por qué sigue ocurriendo)

Algo de contexto útil te ayuda a depurar más rápido, porque te indica dónde están las costuras.

Gutenberg (el editor de bloques) se convirtió en el predeterminado en WordPress 5.0 (2018). Fue un cambio tectónico: una app impulsada por React en el admin, muy dependiente de endpoints REST y empaquetado moderno de JS.
El editor de bloques depende de la REST API para flujos principales. Un plugin que rompe las respuestas REST (salida extra, cabeceras incorrectas, cambios de auth) puede “bloquear” la edición sin tocar el código del editor.
Las páginas de admin de WordPress no son “inmunes” a scripts front-end. Temas y plugins pueden encolar scripts globalmente; una lógica de enqueue descuidada puede contaminar wp-admin.
Muchos page builders y librerías de bloques incluyen sus propios bundles de JS. Si empaquetan versiones incompatibles de paquetería relacionada con React o asumen globals, el editor se convierte en una escena del crimen.
Autosave y revisiones no son caprichos opcionales. Autosave es un flujo REST/AJAX; cuando falla, la confianza del usuario se desploma porque teme perder contenido.
Plugins de seguridad y WAFs inspeccionan cada vez más las llamadas REST del admin. Los falsos positivos son comunes, especialmente para payloads JSON con HTML, shortcodes o cadenas “sospechosas”.
Los límites de memoria de PHP siguen siendo una limitación práctica. El editor puede activar parseo complejo de bloques, procesamiento de imágenes, análisis SEO y renderizado de campos personalizados—todo a la vez.
El cache de objetos puede cambiar el comportamiento de plugins. Algunos plugins manejan mal comprobaciones de capacidades en caché, validación de nonce REST o flags de editor basados en transients.
WP-CLI se convirtió en la forma madura de gestionar plugins a escala. Es más rápido, scriptable y funciona cuando wp-admin está roto.

Modos de fallo comunes: dónde aparecen los conflictos

1) Colisiones de JavaScript en wp-admin

El editor de bloques es una aplicación JS. Un solo error no capturado puede detener el renderizado o romper flujos cruciales como la inserción de bloques. Causas comunes:

Un plugin encola scripts en todas las páginas del admin (en lugar de solo en sus pantallas) e introduce un conflicto de dependencias.
Un plugin añade un script que asume globals de jQuery en contextos que no las cargan (o carga una versión antigua de jQuery).
Plugins de “optimización” concatenan/minifican scripts del admin y reordenan dependencias accidentalmente.

2) Ruptura de REST API y nonce/autenticación

Las acciones del editor llaman a endpoints como /wp-json/wp/v2/posts/<id>. Si esas llamadas fallan, verás “The response is not a valid JSON response”, “Updating failed” o un spinner que nunca se detiene.

Causas comunes:

Plugin de seguridad bloquea o reescribe rutas REST.
WAF/CDN bloquea POSTs con cuerpos JSON o elimina cabeceras.
Plugin imprime espacios en blanco/avisos HTML antes del JSON, haciendo la respuesta inválida.

3) Fatales de PHP y agotamiento de memoria

Los usuarios lo experimentan como pantalla en blanco, “The site is experiencing technical difficulties” o el editor que no carga partes de la UI. En logs, suele aparecer:

Allowed memory size exhausted
Fatal error: Uncaught Error de un plugin que esperaba una clase/función ausente
Errores de tipo tras una actualización de PHP

4) Problemas de base de datos y almacenamiento (sí, almacenamiento)

Los “bloqueos” del editor pueden ser timeouts. Si guardar una entrada desencadena consultas lentas, tablas bloqueadas o almacenamiento saturado, el editor se vuelve poco fiable. El autosave es especialmente sensible porque se ejecuta con frecuencia y los usuarios notan cada titubeo.

5) CDN, caché y la ilusión de “utilidad”

El admin generalmente no debe cachearse en el edge. Pero ocurren malas configuraciones: respuestas REST cacheadas, páginas de sesión iniciada cacheadas o bundles JS obsoletos. El editor carga assets desajustados y luego se cae.

Broma corta #2: Nada dice “optimización de rendimiento” como cachear el panel de administración y pasarte la tarde explicando por qué la realidad es inconsistente.

Tareas prácticas con comandos: aislar, confirmar, decidir

Estas tareas asumen acceso SSH y una pila de hosting Linux estándar. Si estás en hosting gestionado sin shell, adapta la lógica: los puntos de decisión siguen aplicando.

Reglas de compromiso: cambia una variable a la vez, captura evidencias (fragmentos de log, códigos de estado HTTP, marcas temporales) y deja de adivinar. Adivinar es cómo creas dos incidentes en vez de uno.

Tarea 1: Confirma inventario de WordPress y plugins

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core version && wp plugin list --status=active
6.6.2
+-------------------------+----------+-----------+---------+
| name                    | status   | update    | version |
+-------------------------+----------+-----------+---------+
| wordfence               | active   | none      | 7.11.6  |
| wp-rocket               | active   | available | 3.16.1  |
| advanced-custom-fields  | active   | none      | 6.3.6   |
| custom-block-library    | active   | none      | 2.4.0   |
+-------------------------+----------+-----------+---------+

Qué significa: ahora conoces las piezas en movimiento y si “no cambiamos nada” es ficción.

Decisión: si hay una actualización disponible para un plugin de caché/optimización/seguridad, trátalo como sospechoso (no automáticamente la solución, pero sí sospechoso).

Tarea 2: Reproduce con plugins desactivados (la palanca de aislamiento más rápida)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin deactivate --all
Deactivated 'wordfence' plugin.
Deactivated 'wp-rocket' plugin.
Deactivated 'advanced-custom-fields' plugin.
Deactivated 'custom-block-library' plugin.
Success: Deactivated 4 of 4 plugins.

Qué significa: has eliminado la mayoría del comportamiento de terceros. Si el editor aún “se bloquea”, tu problema probablemente sea el tema, core, PHP o infraestructura.

Decisión: prueba el editor ahora. Si es estable, el bloqueo está relacionado con plugins; procede a reactivar de forma controlada.

Tarea 3: Reactiva plugins usando búsqueda binaria

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin activate advanced-custom-fields custom-block-library
Plugin 'advanced-custom-fields' activated.
Plugin 'custom-block-library' activated.
Success: Activated 2 of 2 plugins.

Qué significa: estás estrechando la búsqueda. Prueba el editor. Si se rompe, sabes que el culpable está en este conjunto.

Decisión: si falla, desactiva uno de los dos y vuelve a probar para identificar el plugin específico.

Tarea 4: Cambia a un tema por defecto (los temas también pueden envenenar el admin)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp theme list --status=active && wp theme activate twentytwentyfour
+-----------+--------+-----------+---------+
| name      | status | update    | version |
+-----------+--------+-----------+---------+
| corp-theme| active | none      | 1.9.3   |
+-----------+--------+-----------+---------+
Success: Switched to 'Twenty Twenty-Four' theme.

Qué significa: has eliminado la lógica de enqueue a nivel de tema, estilos de editor personalizados y efectos secundarios de functions.php.

Decisión: si el editor se vuelve estable solo con un tema por defecto, tu “conflicto de plugins” podría ser en realidad código del tema o interacción tema-plugin.

Tarea 5: Activa la depuración de WordPress sin spammear la pantalla

cr0x@server:~$ cd /var/www/example.com/htdocs && wp config set WP_DEBUG true --raw && wp config set WP_DEBUG_LOG true --raw && wp config set WP_DEBUG_DISPLAY false --raw
Success: Updated the constant 'WP_DEBUG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_LOG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_DISPLAY' in the 'wp-config.php' file with the raw value 'false'.

Qué significa: los errores irán a wp-content/debug.log en lugar de romper las respuestas JSON al imprimir warnings dentro de ellas.

Decisión: reproduce el bloqueo una vez y luego inspecciona el log inmediatamente.

Tarea 6: Inspecciona el log de depuración de WordPress en la marca temporal exacta

cr0x@server:~$ cd /var/www/example.com/htdocs && tail -n 60 wp-content/debug.log
[27-Dec-2025 14:18:02 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/debug.php:12) in /var/www/example.com/htdocs/wp-includes/rest-api/class-wp-rest-server.php on line 1898
[27-Dec-2025 14:18:02 UTC] PHP Notice:  Trying to access array offset on value of type null in /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/rest.php on line 77

Qué significa: ese “headers already sent” es un clásico que mata al editor porque las respuestas REST deben ser JSON limpio con cabeceras correctas. Un plugin imprimió salida temprano.

Decisión: desactiva ese plugin inmediatamente o parchea la salida. No “aumentes la memoria” esperando que desaparezca.

Tarea 7: Revisa PHP-FPM y logs del servidor web por fatales y timeouts

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 14:18:02] WARNING: [pool www] child 18422 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/example.com/htdocs/wp-content/plugins/advanced-custom-fields/pro/fields/class-acf-field-flexible-content.php on line 312"

Qué significa: el editor alcanzó un límite de memoria durante una ruta de render/guardado. Esto puede presentarse como spinner atascado o fallo genérico.

Decisión: o aumentas la memoria responsablemente (y mides), o reduces el comportamiento que consume memoria (configuración de campos ACF, patrones de bloques, meta boxes pesados). Verifica también que no haya fuga de memoria/regresión tras actualizaciones.

Tarea 8: Valida la salud de la REST API desde el servidor (evita ruido del navegador)

cr0x@server:~$ curl -s -D - https://example.com/wp-json/ -o /dev/null | head
HTTP/2 200
content-type: application/json; charset=UTF-8
x-robots-tag: noindex

Qué significa: el endpoint índice de REST responde con JSON y un 200. El enrutado básico está vivo.

Decisión: si ves 403/503 o content-type HTML, sospecha reglas de WAF, páginas de mantenimiento o corrupción de salida de PHP.

Tarea 9: Comprueba si admin-ajax devuelve errores (común en flujos del Classic Editor)

cr0x@server:~$ curl -s -D - -X POST https://example.com/wp-admin/admin-ajax.php -d 'action=heartbeat' -o /dev/null | head
HTTP/2 200
content-type: text/html; charset=UTF-8

Qué significa: heartbeat responde. Para más detalle necesitarías cookies de autenticación, pero un 500 aquí sería un gran aviso rojo.

Decisión: si es 500, ve directo a los logs de PHP; si es 403, sospecha cambios de seguridad/WAF/capacidades.

Tarea 10: Encuentra peticiones lentas y endpoints fallando en access logs

cr0x@server:~$ sudo awk '$9 ~ /500|502|503|504/ {print $4, $5, $7, $9}' /var/log/nginx/access.log | tail -n 20
[27/Dec/2025:14:18:02 +0000] "/wp-json/wp/v2/posts/219?context=edit" 500
[27/Dec/2025:14:18:03 +0000] "/wp-admin/post.php?post=219&action=edit" 200

Qué significa: la página del editor carga (200), pero la llamada REST para obtener datos del post falla (500). Por eso la UI “se bloquea”.

Decisión: depura la falla de la ruta REST en PHP (plugins, filtros del tema, salida), no la página HTML.

Tarea 11: Revisa la presión de cron/heartbeat de WordPress (a veces no es un bloqueo, es carga)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp cron event list --due-now | head
+---------------------+-------------------+------------+---------------------+
| hook                | next_run_gmt      | recurrence | args                |
+---------------------+-------------------+------------+---------------------+
| wp_version_check    | 2025-12-27 14:20  | twice_daily| []                  |
| wordfence_daily_cron| 2025-12-27 14:20  | daily      | []                  |
+---------------------+-------------------+------------+---------------------+

Qué significa: hay cron jobs programados y pueden solaparse con sesiones de edición, aumentando carga y latencia.

Decisión: si las ediciones fallan en momentos específicos, correlaciónalas con ventanas intensas de cron; considera programar cron reales y limitar escaneos pesados de seguridad.

Tarea 12: Inspecciona la configuración de PHP para límites de memoria y ejecución

cr0x@server:~$ php -i | egrep 'memory_limit|max_execution_time|max_input_vars' | head -n 20
memory_limit => 256M => 256M
max_execution_time => 30 => 30
max_input_vars => 1000 => 1000

Qué significa: 256M puede o no ser suficiente dependiendo del stack de plugins; max_input_vars=1000 puede romper formularios con meta boxes grandes.

Decisión: si ves fatales de memoria, aumenta memory_limit (y settings de PHP-FPM) de forma controlada; si guardar formularios grandes falla, incrementa max_input_vars y vuelve a probar.

Tarea 13: Detecta si un plugin de optimización está alterando assets del admin

cr0x@server:~$ cd /var/www/example.com/htdocs && wp option get wp_rocket_settings | head
a:5:{s:9:"minify_js";i:1;s:15:"combine_js";i:1;s:12:"exclude_js";a:0:{}s:17:"cache_logged_user";i:1;s:17:"cache_ssl";i:1;}

Qué significa: la configuración sugiere minificación/combinar JS y caché para usuarios logueados. Esa es una combinación de alto riesgo para la estabilidad de wp-admin/editor.

Decisión: desactiva minificar/combinar para rutas admin/editor, y no cachees sesiones iniciadas en el edge o en la capa de página.

Tarea 14: Confirma que no estás sirviendo assets mezclados o desactualizados tras un deploy

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core verify-checksums
Success: WordPress installation verifies against checksums.

Qué significa: los archivos core están intactos. Si el editor sigue fallando, céntrate en plugins/temas/mu-plugins y capas de caché.

Decisión: si las sumas no coinciden, para todo. Arregla la integridad del sistema de ficheros primero; depurar conflictos de plugins sobre un core corrupto es como tunear un motor con arena dentro.

Tarea 15: Revisa must-use plugins y drop-ins (los influenciadores ocultos)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin list --status=must-use && ls -1 wp-content | egrep 'mu-plugins|object-cache.php|advanced-cache.php'
+-------------------+----------+--------+---------+
| name              | status   | update | version |
+-------------------+----------+--------+---------+
| platform-mu-stack | must-use | none   | 1.4.2   |
+-------------------+----------+--------+---------+
advanced-cache.php
mu-plugins
object-cache.php

Qué significa: los MU plugins y drop-ins pueden alterar REST, caché, autenticación y logging. A menudo son la verdadera fuente de “desactivamos todos los plugins y aún falla”.

Decisión: inspecciona el código de MU plugins y drop-ins de caché si el toggling normal de plugins no cambia el comportamiento.

Tarea 16: Verifica la salud del almacenamiento y filesystem cuando los guardados hacen timeouts

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (web01) 	12/27/2025 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    4.15    9.72    0.00   73.82

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          8.00    512.00     0.00   0.00    3.20    64.00   110.00   4096.00    18.00  14.06   45.10    37.24    5.12  92.00

Qué significa: alto %util y alto w_await sugieren contención en escritura del almacenamiento. Los guardados y autosaves son escrituras.

Decisión: si los guardados del editor correlacionan con alta latencia de escritura, investiga I/O de base de datos, consultas lentas, jobs de backup o vecinos ruidosos. No culpes al JavaScript por lo que es esencialmente un problema de cola de disco.

Tres microhistorias corporativas desde el frente

Microhistoria 1: El incidente causado por una suposición equivocada

La compañía estaba desplegando un flujo editorial renovado. Nuevos bloques, un par de tipos de contenido personalizados y un plugin “pequeño” que añadía un panel lateral para metadatos de cumplimiento. El editor empezó a bloquearse solo en un sitio de la red multisite. Naturalmente, todos asumieron que era “relacionado con el contenido” porque ocurría en posts con muchos embeds.

Pasaron medio día extrayendo “posts malos”, limpiando HTML, quitando embeds y probando distintos navegadores. Nada fue consistente. El bloqueo parecía aleatorio: a veces al cargar, otras al insertar un bloque, y a veces solo después de unos minutos. El clásico incidente donde el equipo empieza a culpar al usuario, porque culpar al usuario reconforta emocionalmente.

La suposición equivocada: “Si fuera un plugin, fallaría en todas partes”. En realidad, el plugin tenía una opción por sitio que activaba salida de depuración en producción. Imprimía una sola línea antes de las respuestas REST. No era suficiente para mostrarse en la página, pero sí para corromper JSON.

Cuando pusieron en paralelo el tail del log de depuración y los access logs del servidor, quedó claro: cada bloqueo del editor se alineaba con un 500 REST y un aviso de “headers already sent” apuntando al plugin de cumplimiento. Desactivaron el plugin en ese sitio y el editor se estabilizó al instante. Luego arreglaron el plugin para que nunca hiciera echo/print en rutas de producción y desplegaron una migración de configuración que desactivó la flag de debug.

Conclusión: nunca asumas el alcance basándote en “es un plugin”. Los plugins pueden comportarse diferente por sitio, por rol, por tipo de contenido y por entorno. La evidencia vence a las suposiciones. Siempre.

Microhistoria 2: La optimización que salió mal

Un equipo de marketing exigió “admin más rápido” porque los editores se quejaban de lentitud. Alguien activó combinación y minificación agresiva de scripts—en todo, incluidos usuarios logueados—porque los números del dashboard de rendimiento quedaban mejor si medías la página principal y fingías que el editor no existía.

Durante una semana pareció estar bien. Luego el editor empezó a lanzar errores intermitentes de JavaScript. No siempre el mismo. A veces no se insertaban bloques. A veces la biblioteca de medios no se abría. Publicar se volvió una ruleta. Los tickets de soporte llegaron con un ritmo predecible: lo suficiente para ser doloroso, no lo suficiente para forzar un rollback completo.

El culpable no fue la “minificación” como concepto. Fue el orden de dependencias y la obsolescencia de caché. El plugin de optimización produjo un bundle administrativo combinado que ocasionalmente servía una versión obsoleta tras una actualización de plugin, mientras otro plugin esperaba la build más nueva. El editor cargó paquetes desajustados y falló a mitad del render.

La solución fue aburrida e inmediata: deja de optimizar wp-admin como si fuera una página pública de marketing. Excluye rutas admin/editor de combinar/minificar y deja de cachear respuestas de usuarios logueados a nivel de página. Tras eso pudieron seguir optimizando el front-end—donde la invalidación de caché es predecible y el impacto de fallo es menor.

Conclusión: el trabajo de rendimiento que ignora modos de fallo es solo ingeniería de incidentes con una etiqueta más bonita. Optimiza el front-end; mantén el admin determinista.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un gran portal de noticias interno tenía una política estricta de cambios para actualizaciones de WordPress: las actualizaciones de plugins se agrupaban, se desplegaban a staging y se probaban con un script corto pero consistente: abrir editor, insertar bloques, subir media, autosave, publicar y verificar revisiones. Sin heroísmos, solo repetición.

Una mañana, un editor reportó que el editor de bloques se quedaba cargando. El ingeniero on-call no entró en pánico ni empezó a togglear ajustes al azar. Revisó las notas del último despliegue, vio una actualización de un plugin de seguridad y siguió el playbook establecido: reproduce, revisa llamadas REST, lee logs y compara con staging.

Staging estaba bien. Producción no. Esa diferencia importó. Inspeccionaron los logs del WAF y encontraron una regla nueva que bloqueaba POSTs REST que contenían ciertos patrones HTML. La actualización del plugin de seguridad fue una coincidencia—tentadora, pero errónea. La práctica aburrida de “apuntar qué cambió” evitó un rollback innecesario.

Ajustaron la regla del WAF para el tráfico autenticado de wp-admin y confirmaron la recuperación del editor. El postmortem fue corto, poco glamuroso y útil. La política de cambios no evitó el incidente, pero evitó que el equipo culpara al componente equivocado y perdiera un día.

Conclusión: el seguimiento disciplinado de cambios y un script de prueba repetible no son burocracia. Son cómo mantienes los incidentes pequeños.

Errores comunes: síntoma → causa raíz → solución

Estos son patrones que veo repetidamente. Hacen perder tiempo porque los síntomas engañan.

1) “The response is not a valid JSON response” al actualizar

Síntoma: el editor muestra error de respuesta JSON; Network muestra que la llamada REST devuelve HTML o caracteres extra.
Causa raíz: plugin/tema imprime warnings/notices/echo antes del JSON; o una capa de seguridad inyecta una página de desafío.
Solución: pon WP_DEBUG_DISPLAY en false; desactiva el plugin ofensivo; busca en logs “headers already sent”; whitelist de rutas REST en el WAF para usuarios autenticados.

2) Pantalla blanca o “error crítico” solo en páginas del editor

Síntoma: wp-admin carga pero la ruta del editor queda en blanco.
Causa raíz: fatal de PHP en un meta box, renderer de campo personalizado o registro de bloque; suele activarse solo al editar un tipo de contenido específico.
Solución: tail del log de PHP-FPM, identifica archivo/línea del fatal, desactiva el plugin y verifica compatibilidad con la versión de PHP.

3) El editor carga pero queda no receptivo al hacer clic en “Añadir bloque”

Síntoma: la UI se congela; la Consola muestra TypeError en script de un plugin.
Causa raíz: plugin inyecta JS del admin globalmente, entra en conflicto con paquetes de Gutenberg o asume globals.
Solución: desactiva el plugin sospechoso; si lo mantienes, corrige las condiciones de enqueue y dependencias; evita empaquetar versiones conflictivas de paquetes de Gutenberg.

4) Autosave falló, luego todo parece roto

Síntoma: indicador de autosave falla; a veces “Publicación fallida”.
Causa raíz: llamadas REST bloqueadas (403), nonce desajustado por caché, o timeouts por DB/almacenamiento lento.
Solución: asegúrate de que respuestas admin/rest no se cacheen; revisa códigos de estado REST; investiga latencia I/O y consultas lentas.

5) Funciona para administradores, falla para editores/autores

Síntoma: bloqueos del editor o paneles faltantes según rol.
Causa raíz: comprobaciones de capacidades cacheadas indebidamente; plugin restringe rutas REST según roles; modificaciones de roles personalizados en conflicto con expectativas del plugin.
Solución: prueba con el mismo rol; audita plugins de roles/capacidades; limpia cache de objetos; revisa MU plugins que afecten autenticación.

6) Solo falla detrás de CDN / solo en producción

Síntoma: staging OK; producción editor se bloquea de forma intermitente.
Causa raíz: cache en el edge de páginas logueadas, reglas WAF, malconfiguración Brotli/gzip o caché de assets sirviendo versiones desajustadas.
Solución: evita caché para /wp-admin/, /wp-json/ cuando hay sesiones iniciadas; purga caches tras despliegues; verifica cabeceras.

Listas de verificación / plan paso a paso

A. Plan disciplinado de aislamiento (recomendado)

Captura los síntomas con precisión: qué editor (bloques/clásico/builder), qué tipo de entrada, qué rol, qué navegador, cuál es el mensaje de error exacto.
Reproduce con DevTools abiertos: anota errores de la Consola y llamadas de Network que fallan (endpoint + código de estado).
Desactiva todos los plugins: confirma si la estabilidad regresa.
Cambia a un tema por defecto: confirma si hay implicación del tema.
Reactiva plugins en lotes: búsqueda binaria hasta identificar el conjunto culpable y luego el plugin específico.
Confirma evidencia del lado servidor: empareja la marca temporal de la falla con logs de PHP-FPM y servidor web.
Confirma integridad REST: las respuestas REST deben ser JSON, sin warnings, sin inyección HTML.
Arregla o mitiga: actualiza plugin, ajusta configuración, excluye admin de optimización, aumenta memoria o parchea código.
Verifica la corrección vía un script de prueba: carga el editor, inserta bloques, sube media, autosave, publica, edita de nuevo.
Escribe una nota de incidente corta: qué rompió, cómo lo probaste, qué cambiaste y cómo detectarlo la próxima vez.

B. Plan de recuperación “no puedo iniciar sesión en wp-admin”

SSH al servidor y desactiva plugins con WP-CLI.
Si no hay WP-CLI, renombra el directorio de plugins (último recurso) o desactiva carpetas de plugins específicas.
Estabiliza el editor primero, luego reintroduce componentes con cuidado.

C. Prueba de humo repetible del editor (úsala tras cada cambio)

Abre una entrada existente con muchos bloques.
Añade un bloque nuevo, muévelo, deshaz/rehaz.
Sube una imagen, insértala, actualiza el texto alternativo.
Espera a que dispare el autosave; confirma que no hay errores.
Publica/actualiza; verifica que la entrada cargue en el front-end.
Reabre la entrada; confirma que existen revisiones y el editor carga limpio.

Preguntas frecuentes

1) ¿El editor de bloques es más propenso a conflictos con plugins que el Classic Editor?

Sí, porque es una app pesada en JS que depende de REST. Classic Editor es más orientado a formularios/AJAX. Modos de fallo diferentes, misma causa raíz: plugins que enganchan demasiado ampliamente.

2) Si desactivar todos los plugins lo arregla, ¿el último plugin que actualicé es siempre el culpable?

No. Las actualizaciones correlacionan con incidentes porque cambian el sistema, pero el disparador real puede ser una capa de caché, una actualización de PHP o un segundo plugin reaccionando a la actualización.

3) ¿Por qué el editor se bloquea solo en una entrada?

Esa entrada puede activar un bloque específico, shortcode o renderer de meta box. Algunos plugins cargan código extra solo cuando existen ciertos bloques/campos meta, por eso una sola entrada puede ser el único reproductor.

4) ¿Qué significa en la práctica “invalid JSON response”?

O bien el servidor devolvió HTML (página de desafío WAF, página de warning de PHP) o devolvió JSON con caracteres extra antes/después (notices de PHP, echo suelto). Los consumidores REST son estrictos; por algo es así.

5) ¿Las extensiones del navegador pueden causar bloqueos del editor de WordPress?

Sí. Gestores de contraseñas, bloqueadores de anuncios y extensiones de “privacidad” pueden bloquear scripts o modificar peticiones. Por eso probar en incógnito/privado es una comprobación rápida de cordura.

6) ¿Debería aumentar memory_limit de PHP para arreglar bloqueos del editor?

A veces. Si los logs muestran agotamiento de memoria, aumentarlo puede ser una mitigación válida. Pero trátalo como comprar tiempo: también arregla el comportamiento del plugin/tema que consume la memoria.

7) ¿Por qué funciona en staging pero no en producción?

Producción suele tener caché en el edge, reglas WAF, tráfico real, jobs en background y comportamiento de cache de objetos diferente. Staging es más calmado. Los bugs aman los entornos calmados porque se pueden esconder.

8) ¿Cómo identifico un conflicto cuando el bloqueo es intermitente?

Instrumenta: registra marcas temporales, captura códigos de estado de Network y correlaciona con logs del servidor. Los problemas intermitentes suelen alinearse con expiración de caché, cron jobs o picos de carga.

9) ¿Es seguro desactivar plugins en un sitio en vivo para depurar?

Depende del plugin. Desactivar brevemente un plugin de seguridad suele ser más seguro que dejar el editor roto por horas. Pero hazlo intencionadamente: anúncialo, limita el tiempo y revierte con cuidado.

10) ¿Y si el culpable es un MU plugin o un drop-in de caché?

Entonces el toggling normal de plugins no ayudará. Necesitarás inspeccionar wp-content/mu-plugins, object-cache.php y advanced-cache.php y coordinar con quien posea la capa de plataforma.

Conclusión: próximos pasos que puedes tomar hoy

Si tu editor de WordPress se bloquea, no lo trates como un problema místico de UI. Trátalo como un incidente de producción con impacto visible para usuarios.

Ejecuta el diagnóstico rápido: Consola + Network de DevTools, luego aisla plugins.
Activa logging de forma segura: registra en archivos, no en pantalla. Protege las respuestas JSON.
Prueba y prueba hasta probar al culpable: desactiva todos los plugins, reactiva por lotes, correlaciona con líneas de log y códigos HTTP.
Arregla la clase de problema: excluye wp-admin de optimizaciones, whitelist REST para usuarios autenticados en el WAF y mantén límites de memoria realistas.
Institucionalízalo: mantén una prueba de humo corta para el editor y ejecútala tras actualizaciones. Aburrido es bueno. Aburrido es estable.