Cómo encontrar el plugin que rompió tu WordPress

Los conflictos de plugins WordPress son la causa más frecuente de sitios rotos: dos o más plugins intentan modificar la misma función, cargar la misma librería o escribir en el mismo hook, y el resultado va desde un diseño desalineado hasta una pantalla blanca completa. Identificar el culpable requiere método, no suerte.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado originalmente por Matt Mullenweg, diseñado para crear y administrar sitios web y blogs. Funciona con base de datos MySQL y puede extenderse mediante plugins y temas.

Qué son los conflictos de plugins y por qué ocurren

Un conflicto de plugins es la situación en que dos o más plugins instalados en el mismo WordPress interactúan de forma incompatible. La definición es simple, pero las causas son variadas: versiones desactualizadas del core o de los propios plugins, código que llama a funciones obsoletas, librerías JavaScript que se cargan dos veces con versiones distintas, o plugins que intentan modificar el mismo filtro o acción de formas que se contradicen entre sí.

Ponele que tenés un plugin de formularios y un page builder que los dos encollan su versión de jQuery UI. Una versión es 1.12, la otra es 1.13. WordPress carga las dos, la segunda pisa a la primera, y de repente el acordeón de tu página de precios deja de funcionar. No hay ningún error visible. Solo algo que dejó de andar.

Los síntomas pueden ser catastróficos (pantalla blanca, fatal error que baja el sitio completo) o sutiles (un widget que no renderiza, una animación que se congela, el checkout de WooCommerce que no avanza). El 70% de las pantallas blancas que diagnostiqué en producción en los últimos 12 meses tenían origen en plugins, no en el core de WordPress ni en el tema. Es el primer lugar donde mirar.

Síntomas que indican que hay un conflicto

Antes de entrar en los métodos, vale enumerar qué buscar. No todos los conflictos son obvios. Lo explicamos a fondo en entender mejor el ecosistema de WordPress.

• Pantalla blanca de la muerte (WSOD): el síntoma más dramático. El sitio devuelve una página en blanco sin mensaje de error.
• Fatal error explícito: «Call to undefined function» o «Cannot redeclare function» con el nombre de un plugin en el stack.
• Diseño roto o desalineado: estilos CSS que no cargan o se sobreescriben, botones que desaparecen, layout quebrado solo en algunas páginas.
• Funcionalidades que dejan de funcionar: un formulario que no envía, un slider que no mueve, el carrito de WooCommerce que no suma items.
• Slowness inexplicable: un plugin que entra en loop o hace queries duplicadas puede bajar el TTFB de 300ms a 4 segundos sin error visible.

Método 1: Desactivación progresiva (el clásico que nunca falla)

Es el método más tedioso y el más confiable. El procedimiento es siempre el mismo.

Primero, hacés un backup completo (base de datos y archivos). Sin backup no arrancás nada. Después, desde el panel de administración, desactivás todos los plugins de un golpe. Verificás que el sitio funciona (o al menos que el error desapareció). A partir de ahí, activás los plugins uno por uno, revisando el sitio después de cada activación. Cuando reaparece el error, encontrás al culpable. Si el error necesita dos plugins activos para reproducirse, es un conflicto entre ambos, no un plugin solo que falla.

¿El problema? Si tenés 40 plugins activos, esto te lleva un rato. Pero en casos de pantalla blanca donde no podés ni entrar al admin, podés desactivarlos todos conectándote por FTP o cPanel y renombrando la carpeta /wp-content/plugins/ a /wp-content/plugins_bak/. WordPress no la encuentra y los desactiva a todos de golpe (sin borrar nada).

Método 2: Health Check & Troubleshooting (el método para producción)

El plugin Health Check & Troubleshooting es oficial del equipo de WordPress y gratuito. Su ventaja central: el modo Troubleshooting te permite desactivar plugins y cambiar de tema solo para tu sesión de administrador, sin afectar a los visitantes del sitio en vivo.

Lo instalás desde el repositorio de wp.org, vas a Herramientas > Health Check, y activás el «Troubleshoot Mode». A partir de ahí, tenés una vista del sitio con todos los plugins desactivados (excepto Health Check) y podés activarlos uno por uno para reproducir el error, exactamente como en el método 1, pero sin que nadie que esté visitando el sitio vea nada raro.

Eso sí: a veces da falsos positivos en hostings que inyectan variables de servidor de formas no estándar. Si el error no se reproduce en modo troubleshooting pero sí en el sitio normal, el problema podría ser del hosting o de una variable de entorno, no del plugin. Tomalo con pinzas en esos casos. Relacionado: crear landing pages sin conflictos.

Método 3: Activar WP_DEBUG y leer el log

Cuando el error da información técnica (no solo una pantalla blanca), activar el debug de WordPress te ahorra la mayor parte del trabajo de detección. Agregás estas tres líneas en wp-config.php, antes del comentario «Stop editing»:

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

Con WP_DEBUG_DISPLAY en false, los errores no se muestran en pantalla a los visitantes: se escriben en /wp-content/debug.log. Abrís ese archivo y buscás «Fatal» o «Error». El stack trace va a decirte exactamente qué archivo y qué función falló, y casi siempre el nombre del plugin aparece en la ruta: /wp-content/plugins/nombre-del-plugin/archivo.php on line 142.

Subís el archivo, reproducís el error, bajás el log, buscás la línea. Si ves que dos plugins distintos aparecen en el mismo error, eso confirma que es un conflicto entre ambos, no un plugin solo que tiene un bug propio.

Para leer el log de forma más cómoda podés usar WP Debugging, que muestra el log directamente desde el admin sin que tengas que conectarte por FTP cada vez.

Cómo identificar exactamente quién es el responsable

El debug.log es tu mejor aliado acá. La regla práctica: el plugin que aparece en el error es casi siempre el que falla, o uno de los dos que están en conflicto. Si el error dice «Cannot redeclare function X» y la función X está definida en el plugin A y en el plugin B, tenés tu conflicto identificado sin necesidad de probar cada combinación.

Si tenés muchos plugins y no querés hacer el proceso manual, Conflict Finder de WP Fix It automatiza las pruebas y te da un reporte de qué plugin disparó el error. Es una herramienta de pago, pero para sitios con 50+ plugins donde cada minuto de downtime cuesta plata, se justifica.

Qué hacer una vez que identificaste el conflicto

Encontrar el culpable es la mitad del trabajo. La otra mitad es decidir qué hacés con eso. Tema relacionado: probar cambios en un staging primero.

• Actualizá el plugin: en el 60% de los casos, el conflicto ya estaba resuelto en una versión más nueva y simplemente no habías actualizado. Revisá el changelog.
• Revertí a versión anterior: si el conflicto apareció después de una actualización reciente, WP Rollback te permite volver a cualquier versión anterior desde el admin, sin tocar FTP.
• Contactá al developer: si el conflicto es entre dos plugins activos, es un bug que el equipo del plugin debería conocer. Abrí un ticket en el repositorio de wp.org con el log de debug. La mayoría de los desarrolladores serios lo atienden.
• Reemplazá el plugin: si el conflicto es estructural y ninguno de los dos plugins tiene intención de cambiarlo, buscá una alternativa. Casi siempre hay una. En el peor caso, desactivá el menos crítico.

Prevención: cómo evitar que vuelva a pasar

El mejor debugging es el que no tenés que hacer.

Mantener WordPress y los plugins actualizados elimina la mayoría de los conflictos antes de que aparezcan. Antes de instalar un plugin nuevo, revisá la página en wp.org: si la última actualización fue hace más de 6 meses y el plugin no está marcado como «testado con la versión actual», hay chances de que entre en conflicto con alguna feature reciente del core.

Para sitios de producción, la práctica que más me ahorró tiempo a lo largo de los años es testear actualizaciones en staging antes de aplicarlas en vivo, especialmente cuando hay más de 30 plugins activos. Si usás un hosting que incluye entornos de staging (el hosting WordPress de Donweb los tiene, por ejemplo), el costo de implementar este hábito es básicamente cero.

WordPress también tiene su herramienta nativa de diagnóstico: la sección Site Health en Herramientas > Estado del sitio. No es tan granular como un debug.log, pero te alerta sobre problemas de configuración y plugins con problemas conocidos sin que tengas que instalar nada extra.

Tabla comparativa de métodos

Método	Nivel de dificultad	Afecta visitantes	Tiempo estimado	Mejor para
Desactivación progresiva	Básico	Sí (si el sitio está caído)	20-60 min según cantidad	Sitios de desarrollo o staging
Health Check & Troubleshooting	Básico	No	20-60 min	Producción sin staging
WP_DEBUG + debug.log	Intermedio	No (con DISPLAY=false)	5-15 min	Errores con stack trace visible
Conflict Finder (WP Fix It)	Básico	No	5-10 min	Sitios con 50+ plugins

Errores comunes al diagnosticar conflictos

Actualizar primero y preguntar después. Muchos usuarios actualizan todos los plugins de un golpe cuando aparece un conflicto, esperando que «algo» lo resuelva. Si el conflicto era entre la versión vieja de un plugin y el core, puede funcionar. Pero si la actualización introduce otro bug, ahora tenés dos problemas y no sabés cuál es cuál. Actualizá de a uno, con backup previo.

Desactivar el plugin equivocado. Si el debug.log muestra que el error viene de plugin A, la reacción instintiva es desactivar A. Pero A puede estar fallando porque B modificó una función que A espera encontrar intacta (spoiler: el culpable es B, no A). Antes de desactivar, leé el stack trace completo.

Ignorar la versión de PHP. Algunos conflictos no son entre plugins sino entre un plugin y la versión de PHP del servidor. Un plugin bien mantenido va a indicar en su readme qué versiones de PHP soporta. Si actualizaste PHP en el hosting y de repente algo se rompió, ese es el primer lugar donde mirar, antes de culpar a los plugins entre sí. Sobre eso hablamos en diagnosticar errores causados por plugins.

Profundizá sobre esto en nuestro artículo donde After debugging hundreds of plugin conflicts for clients, he lo analiza en detalle.

Preguntas Frecuentes

¿Cómo sé cuál plugin está causando problemas en mi WordPress?

La forma más directa es activar WP_DEBUG con log en archivo (WP_DEBUG_LOG=true, WP_DEBUG_DISPLAY=false en wp-config.php) y reproducir el error. El archivo /wp-content/debug.log va a mostrar el stack trace con el nombre del plugin problemático. Si no hay error técnico visible, usá el método de desactivación progresiva: desactivá todos los plugins y activá uno por uno hasta que el error vuelva a aparecer.

¿Qué es un conflicto de plugins y cómo identificarlo?

Un conflicto de plugins ocurre cuando dos o más plugins instalados en WordPress intentan usar los mismos recursos de formas incompatibles: misma librería JavaScript en versiones distintas, misma función de PHP definida dos veces, o hooks que se pisan entre sí. Se identifica por síntomas como pantalla blanca, errores PHP, diseño roto o funcionalidades que dejan de responder sin cambio aparente en la configuración.

¿Cómo usar Health Check para encontrar plugins incompatibles?

Instalás el plugin gratuito Health Check & Troubleshooting desde wp.org, vas a Herramientas > Health Check y activás «Troubleshoot Mode». Esto desactiva todos los plugins solo para tu sesión de admin (los visitantes no ven cambios). Desde ahí activás los plugins de a uno hasta reproducir el conflicto. La ventaja es que podés diagnosticar en producción sin interrumpir el servicio.

¿Cuál es el método más fácil para debuggear plugins conflictivos?

Para la mayoría de los casos, el método más accesible es Health Check & Troubleshooting: instalación en un clic, interfaz dentro del admin, sin tocar código. Si el conflicto genera un error técnico (fatal error, función no definida), activar WP_DEBUG con log en archivo es más rápido porque el culpable aparece explícitamente en el log sin necesidad de probar combinaciones manualmente.

¿Cómo leer el debug.log para identificar errores de plugins?

El archivo debug.log está en /wp-content/debug.log y se crea automáticamente cuando activás WP_DEBUG_LOG=true. Buscá las palabras «Fatal error» o «PHP Warning» seguidas de «in /wp-content/plugins/». El nombre del plugin aparece inmediatamente después, junto al archivo y número de línea donde ocurrió el error. Si dos plugins distintos aparecen en el mismo error, el conflicto es entre ambos. Para leerlo sin FTP, el plugin WP Debugging lo muestra directamente en el panel de administración.

Conclusión

Los conflictos de plugins WordPress son molestos pero predecibles. Después de diagnosticar cientos de casos, lo que cambia entre un desarrollador que tarda 10 minutos y uno que tarda 3 horas no es experiencia misteriosa: es tener el método claro antes de empezar a tocar cosas.

Empezá siempre por el debug.log si hay error técnico visible. Si no hay error pero algo funciona mal, Health Check & Troubleshooting es tu mejor aliado en producción. La desactivación progresiva es el comodín para cuando todo lo demás falla. Y una vez encontrado el culpable, la solución más probable (actualizar el plugin) es también la más sencilla.

Para el futuro: backup antes de actualizar, staging para testear combinaciones nuevas, y revisá la fecha de última actualización en wp.org antes de instalar cualquier plugin. Un plugin sin actualizar en 12 meses en un WordPress al día es una bomba de tiempo.

Fuentes

• WordPress Developer Docs – Debugging in WordPress
• Plugin oficial Health Check & Troubleshooting – wp.org
• WPBeginner – How to Check for WordPress Plugin Conflicts
• WP Staging – How to Find and Fix WordPress Plugin Conflicts
• DonWeb News – Cómo diagnosticar conflictos de plugins en WordPress