Desactivar plugins por SQL cuando no hay acceso

Si necesitas desactivar plugins por SQL cuando no hay acceso, el objetivo suele ser recuperar la entrada a WordPress tras un error crítico, una pantalla en blanco, un bucle de acceso o un conflicto que bloquea wp-admin. En la práctica, este método modifica un valor de la base de datos de WordPress —normalmente la opción active_plugins en la tabla de opciones— para que el sistema deje de cargar los plugins activos.

Es una solución útil cuando no puedes entrar al panel y tampoco te resultan viables otras vías más simples, como FTP, administrador de archivos o WP-CLI. Antes de tocar nada, conviene hacer una copia de seguridad de la base de datos y comprobar el prefijo de tablas, porque no siempre será wp_.

Qué significa desactivar plugins por SQL cuando no hay acceso

Significa intervenir directamente en la base de datos de WordPress para cambiar el listado de plugins activos cuando el administrador no carga. WordPress guarda esa información en la opción active_plugins, que contiene un array serializado con las rutas de los plugins activados.

Al vaciar esa activación o sustituirla por una estructura vacía válida, WordPress puede arrancar sin cargar esos plugins. Esto no elimina los plugins del servidor: simplemente deja de marcarlos como activos para intentar recuperar acceso a WordPress.

Cuándo conviene usar este método y qué riesgos tiene

Conviene plantearlo cuando hay un plugin en conflicto en WordPress y no puedes desactivarlo por medios normales. Suele ser razonable si el backend ha caído tras una actualización, aparece un error fatal de PHP o el acceso a wp-admin queda bloqueado.

Los riesgos existen: tocar mal una opción serializada, editar la tabla equivocada o asumir un prefijo incorrecto puede complicar más la incidencia. Además, este procedimiento no siempre resuelve el problema. Si el fallo está en el tema, en la versión de PHP, en la memoria, en la caché o en la integridad de archivos, habrá que seguir diagnosticando.

• Haz copia de seguridad antes de modificar datos.
• Comprueba el prefijo real de las tablas en esa instalación.
• Si es multisite, la activación por red puede requerir revisar otro nivel de configuración.

Cómo localizar la opción active_plugins en la base de datos

La vía más habitual es phpMyAdmin, aunque no es la única. Debes abrir la base de datos asociada a la web y buscar la tabla de opciones, que a menudo será wp_options, pero puede llamarse de otra forma si el prefijo cambia.

1. Identifica la base de datos correcta del sitio.
2. Localiza la tabla de opciones según su prefijo real.
3. Busca la fila cuyo option_name sea active_plugins.
4. Revisa el valor actual antes de editarlo y guárdalo por si necesitas revertir.

En esa fila verás normalmente una cadena serializada. No conviene modificarla a mano sin criterio si quieres desactivar solo uno, porque la serialización debe quedar intacta. Para una recuperación rápida, suele ser más seguro desactivar todos los plugins temporalmente y luego revisar posibles tablas huérfanas de plugins.

Cómo desactivar todos los plugins desde SQL paso a paso

La idea es dejar active_plugins con una estructura vacía válida para que WordPress no cargue ningún plugin al iniciar. Según la herramienta y el entorno, puedes hacerlo editando la fila desde interfaz o con una consulta SQL prudente.

1. Haz una copia de seguridad de la base de datos.
2. Abre la tabla de opciones con el prefijo correcto.
3. Localiza active_plugins.
4. Sustituye su valor por una estructura vacía válida. En muchas instalaciones se usa a:0:{} para representar un array serializado vacío.
5. Guarda el cambio y prueba a cargar de nuevo /wp-admin.

Si tu herramienta requiere una consulta, conviene adaptarla al prefijo real de la tabla. Un ejemplo orientativo sería:

UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

Ese ejemplo no debe copiarse sin verificar el nombre real de la tabla. Si el prefijo no es wp_, tendrás que ajustarlo. En algunos casos, editar el valor desde la interfaz de la herramienta será suficiente y más cómodo.

Qué revisar después para recuperar WordPress sin romper nada

Si el acceso vuelve, no reactives todo de golpe. Lo recomendable es entrar al panel y activar los plugins uno a uno hasta detectar cuál provoca el fallo. Así podrás confirmar si había un plugin en conflicto WordPress o si el problema venía de otro sitio.

• Vacía caché de plugin, servidor o CDN si existe.
• Comprueba el tema activo por si el error no estaba en los plugins.
• Verifica la versión de PHP y posibles incompatibilidades.
• Revisa el registro de errores del servidor o el modo de diagnóstico.
• Confirma que los archivos de WordPress y del plugin no estén corruptos.

Si el problema persiste incluso con todos los plugins desactivados, la causa puede estar en una actualización fallida, memoria insuficiente, caché persistente o integridad de archivos. En ese punto, el cambio en active_plugins solo habrá servido para acotar el diagnóstico.

Errores frecuentes y límites de este procedimiento

• Usar una tabla incorrecta por no comprobar el prefijo.
• Editar mal un valor serializado y dejar la opción inconsistente.
• Pensar que desactivar plugins por SQL resuelve siempre cualquier error crítico en WordPress.
• Olvidar que en multisite puede existir activación por red.
• No guardar el valor original antes de modificarlo.

También conviene recordar que este método actúa sobre el estado de activación, no sobre el código del plugin ni sobre su configuración interna. Puede devolverte el acceso, pero después habrá que validar qué componente falló y por qué.

Como referencia adicional, la documentación oficial de WordPress sobre la base de datos y la tabla de opciones puede ayudar a confirmar la estructura general del sistema: WordPress Options API.

En resumen, desactivar plugins por SQL cuando no hay acceso es un recurso de recuperación útil y bastante directo si no dispones de otras vías, pero exige cuidado, copia de seguridad y verificación posterior. Si necesitas recuperar la web sin asumir riesgos innecesarios, el siguiente paso razonable es revisar el error con soporte técnico especializado antes de tocar más elementos críticos.