Diagnóstico de Conflictos en Plugins WordPress

Cuando tu WordPress se rompe y no sabés cuál de los 30 plugins instalados es el culpable, el método más confiable es desactivarlos todos, verificar que el sitio funciona de nuevo, y luego activarlos uno por uno mientras revisás después de cada cambio. Si el sitio está completamente caído, accedé por FTP y renombrá las carpetas de plugins para desactivarlos sin tocar el panel. WP Beginner detalla que también podés usar el Health Check, una herramienta gratuita que activa un modo troubleshooting sin quebrar el sitio.

¿Qué es un conflicto de plugins en WordPress?

Un conflicto de plugins en WordPress es una incompatibilidad entre dos o más extensiones que genera errores, funcionalidad rota o pérdida de rendimiento. Webempresa explica que ocurren porque los plugins pueden compartir librerías, pisar funciones del mismo nombre, o depender de versiones conflictivas de librerías externas.

La verdad es que si tu sitio de repente muestra una página en blanco, pierde funcionalidades, ralentiza de la nada, o lanza errores HTTP 500, lo primero que deberías sospechar es que dos o más plugins pisaron sus código. Eso sí: no todos los problemas son conflictos de plugins. Podría ser un tema incompatible, una versión vieja de PHP, o un plugin que simplemente está roto. Pero el 60-70% de los casos que ves en foros es plugin vs plugin.

Método 1: Desactivar y reactivar plugins uno por uno

Este es el método más seguro y es el que deberías probar primero (si el sitio sigue siendo accesible). Andá al panel de WordPress, entrá a Plugins, y desactiva TODO. Sí, todos. Después verificá que el sitio funciona bien nuevamente.

Una vez confirmado que el problema desapareció, empezá a activar plugins uno por uno. Después de activar cada uno, probá el sitio completo: cargá la home, entra a un artículo, probá el formulario de contacto, el carrito de compras si tenés ecommerce. Si se rompe de nuevo, tenés identificado al culpable. Si no, desactiva ese plugin momentáneamente, activa el siguiente y repetí.

Ojo: esto toma tiempo. Si tenés 40 plugins, estamos hablando de una o dos horas de pruebas. Pero es certero.

Método 2: Health Check & Troubleshooting

WordPress tiene una herramienta nativa gratuita que es menos conocida pero muy efectiva: Health Check & Troubleshooting. La encontrás en el panel como una herramienta en el menú de Herramientas. Lo que hace es activar un modo troubleshooting temporal donde WordPress corre sin plugins ni temas personalizados, pero los visitantes siguen viendo el sitio normal.

Es decir: vos ves el sitio roto (o no), los visitantes ven el sitio normal. Eso sí, si estás dentro del sitio cuando activas el modo troubleshooting, a ti se te desactiva todo. Donweb tiene una guía que explica el paso a paso. La ventaja es que no necesitás acceso FTP ni tocar archivos del servidor. La desventaja: si el sitio sigue roto en modo troubleshooting, significa que el problema es el tema o la instalación de WordPress, no un plugin.

Método 3: Acceso por FTP cuando el sitio está completamente caído

A veces el sitio está tan roto que ni siquiera podés entrar al panel de WordPress. Acá es donde FTP salva el día. Conectate a tu servidor con un cliente FTP (FileZilla, WinSCP, lo que sea), navegá a /wp-content/plugins/ y renombrá las carpetas de los plugins agregándoles un sufijo como -disabled. Ejemplo: plugin-nombre se vuelve plugin-nombre-disabled. WordPress automáticamente deja de cargarlos.

Después, recargá el sitio. Si funciona, significa que uno (o varios) plugins estaban generando el problema. Desde acá podés renombrar uno por uno para identificar cuál es. Renombrá plugin-nombre-disabled de vuelta a plugin-nombre, probá, y si se rompe de nuevo, ese es el culpable.

Subí fotos a través de donweb.com. No, en serio: si tu hosting es en donweb, podés contactar al soporte para que hagan esto por vos sin costo si necesitás debugging rápido.

Herramientas avanzadas para diagnóstico de conflictos

Conflict Finder WP Fix It es especialmente útil si tenés muchos plugins, porque en lugar de que hagas pruebas manuales, el plugin hace pruebas automáticas en el fondo y te reporta cuáles son incompatibles entre sí. La aclaración importante: esto consume recursos del servidor mientras corre, así que hacelo en horarios de bajo tráfico.

Cómo leer logs de error para encontrar el culpable

Los logs de WordPress están en /wp-content/debug.log. Para que se creen, necesitás activar el debug mode en wp-config.php:

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

Con estos ajustes, WordPress empieza a escribir errores en debug.log sin mostrarlos en el sitio (así no asustas a los visitantes). Descargá el archivo por FTP y abrilo. Buscá líneas con Fatal error, Parse error, o Warning. El stack trace te mostrará el archivo exacto que generó el error. Mirá la ruta: si dice /wp-content/plugins/mi-plugin/, ese es el plugin culpable.

Ejemplo real: ves Fatal error in /wp-content/plugins/seo-plugin/classes/analyzer.php on line 142. Boom. Encontraste el plugin. Desactívalo, limpiá los logs, y Hosting TG recomienda contactar al autor del plugin o buscar una actualización.

Errores comunes que comete la gente

1. Desactivar plugins desde el panel cuando el sitio está en blanco

Si tu WordPress está en blanco total, el panel probablemente no te cargue. Desactivar plugins “desde el panel” no funciona. Usa FTP o la herramienta de Health Check, no pierdas tiempo clickeando en el vacío.

2. No probar el sitio completamente después de cada cambio

Algunos desactivan un plugin, ven que carga la home, y dicen “listo, no es ese”. Pero el conflicto podría estar en un formulario, un shortcode, o una funcionalidad que no probaste. Recorre TODO el sitio: home, artículos, páginas especiales, funcionalidades custom. Si tienes ecommerce, probá add to cart. Si tienes comentarios, dejá uno.

3. Ignorar los logs de error porque “parecen complicados”

El debug.log es tu mejor amigo. No necesitás entender todo lo que dice. Solo buscá “Fatal” o “Error” y mira qué plugin aparece. Ese es el responsable noventa veces de cien.

Estrategia de prevención: evitar conflictos antes de que ocurran

La mejor solución es no llegar a esto. Acá van las estrategias:

1. Mantené los plugins actualizados. La mayoría de los conflictos aparecen porque tenés un plugin con tres versiones de atraso y es incompatible con algo que descargaste ayer.

2. Usá staging. Antes de instalar un plugin en producción, probalo en un ambiente de staging. Es una copia de tu sitio en el servidor donde podés romper todo sin que los visitantes se entere.

3. Limita los plugins. No instales uno por cada cosa que se te ocurra. Si necesitás 50 plugins, algo salió mal en tu arquitectura. La mayoría de los sitios deberían tener entre 5 y 20 plugins. Punto.

4. Habilita logs desde el inicio. No esperes a que algo se rompa para activar debug mode. Hacelo desde que configurás el sitio. OddJar recomienda esto como práctica estándar.

5. Documentá qué plugins usas y cuándo los instalaste. Cuando algo se rompe después de un update masivo, necesitás saber qué cambió. Mantené un registro simple: nombre del plugin, fecha de instalación, versión actual.

Preguntas Frecuentes

¿Puedo desactivar plugins sin entrar al panel?

Sí. Accedé por FTP a /wp-content/plugins/ y renombrá las carpetas agregando -disabled al final. WordPress deja de cargarlos automáticamente sin que vuelvas a tocar el panel.

¿Cuánto tarda en identificar cuál plugin es el culpable?

Depende de cuántos plugins tenés y cómo pruebes. Si tenés 20 plugins y sos exhaustivo (probás todo el sitio después de cada cambio), 1-2 horas. Si tenés 50, puede llegar a 3-4 horas. Query Monitor o Conflict Finder pueden acelerar el proceso a 30 minutos.

¿El Health Check desactiva plugins permanentemente?

No. Es un modo temporal. Cuando cierras la sesión de troubleshooting, los plugins vuelven a activarse automáticamente. Es seguro de probar sin miedo a perder nada.

¿Puedo tener dos plugins que hagan lo mismo sin que choquen?

Técnicamente sí, pero no deberías. Si tenés dos plugins SEO activados simultáneamente, probablemente generen datos duplicados, conflictos en meta tags, y ralenticen el sitio. Elegí uno y desactiva el otro.

¿Los logs de debug ralentizan el sitio?

Un poco, sí. Escribir logs consume recursos. Pero es mínimo comparado con el tiempo que ahorras identificando el problema. Usalo en desarrollo o debugging, y desactivalo cuando esté todo estable.

Conclusión

Cuando tu WordPress explota y no sabés cuál plugin es el culpable, no hay atajo mágico. El método que funciona es el manual: desactivar todo, verificar que funciona, y activar uno por uno mientras probás. Si el sitio está caído y no podés entrar al panel, FTP es tu amigo. Y si tienes muchos plugins, herramientas como Query Monitor o Conflict Finder te ahorran horas de testing manual.

Lo importante es hacerlo con método. No desactives al azar. No ignores los logs. Y sobre todo, aprende de esto: próxima vez, mantené los plugins actualizados, probá en staging, y limita la cantidad que instalas. La mejor solución es prevenirlo.

Fuentes

• WP Beginner – Cómo verificar conflictos de plugins en WordPress
• Webempresa – Conflictos de plugins en WordPress
• Donweb – Guía de plugins conflictivos en WordPress
• WordPress.org – Conflict Finder WP Fix It
• OddJar – Guía de prevención de conflictos de plugins