Un error fatal de plugin puede bloquear tanto la web como wp-admin. Puedes hacer que WordPress lo considere no disponible mediante WP-CLI o renombrando su directorio; editar directamente el valor serializado en la base debe ser el último recurso.
Conserva las pruebas y los archivos. Desactivar contiene el fallo, pero todavía no explica su causa.
Identifica el plugin mediante pruebas
Lee los registros PHP o del alojamiento y busca la ruta del error y su hora. Confirma directorio, archivo principal, versión y acción que provocó el fallo.
/wp-content/plugins/example-plugin/...No desactives un plugin solo porque aparezca más abajo en la pila. La primera llamada fallida y el cambio reciente son indicios mejores.
Haz una copia antes de intervenir
Crea una copia de datos y archivos o un snapshot. Confirma que cPanel, Plesk, SFTP o SSH llega a la raíz activa.
No ejecutes Desinstalar ni Eliminar: puede borrar tablas y ajustes. La desactivación segura deja los datos disponibles para reparar.
Comprueba si controla el acceso, mantenimiento o integraciones esenciales y planifica el impacto temporal.
Usa WP-CLI si WordPress puede arrancar
Desde la raíz correcta:
wp plugin deactivate example-plugin
wp plugin status example-pluginEjecuta como el usuario del hosting y revisa la salida. Si PHP falla antes de cargar WP-CLI, utiliza --skip-plugins=example-plugin cuando sea compatible o el método de archivos.
En multisitio, revisa la activación de red y utiliza órdenes específicas.
Renombra el directorio
Desde el gestor de archivos, SFTP o SSH, renombra únicamente el directorio identificado:
example-plugin -> example-plugin.disabledWordPress no encontrará la ruta activa y debería desactivarla al cargar la lista. Conserva propietario y no conviertas la carpeta en un archivo descargable públicamente.
Limpia OPcache si el error persiste tras cambiar la ruta.
Trata plugins obligatorios y drop-ins
Los plugins de wp-content/mu-plugins cargan automáticamente. Los drop-ins object-cache.php, db.php y advanced-cache.php también se cargan aparte.
Sigue el procedimiento documentado por el proveedor; renombrar el plugin normal puede dejar activo su drop-in.
Haz copia y verifica caché o base antes de moverlo.
Evita editar directamente la base
active_plugins es una opción serializada. Editarla como texto puede corromperla y desactivar plugins ajenos.
Si no hay acceso a archivos ni WP-CLI, utiliza una herramienta consciente de WordPress o código que deserialice y actualice de forma segura después de una copia.
Los plugins activos en red se guardan en otra opción.
Diagnostica antes de reactivar
Conserva el directorio y el error. Compara compatibilidad, dependencias, PHP e integridad de archivos en staging.
Actualiza o revierte desde una fuente fiable, o corrige el código de integración propio. Haz otra copia antes de migraciones de esquema.
No reactives repetidamente en producción para provocar la misma caída.
Evalúa el impacto en dependencias
Busca en tema, plugins y registros las clases, bloques o shortcodes que aporta el componente. Un complemento dependiente puede fallar cuando desaparece su base.
Contén el conjunto en el orden del proveedor. Si controla acceso, caché, idiomas o integraciones, prepara una alternativa e informa de lo que queda temporalmente fuera de servicio.
Conserva los límites de seguridad
No desactives control de acceso o seguridad sin trasladar la protección al hosting o cortafuegos. El mantenimiento no debe exponer contenido privado que antes restringía el plugin.
Prueba acceso anónimo en un navegador limpio. La urgencia autoriza la reparación mínima, no una reducción permanente de seguridad.
Verifica contención y recuperación
Prueba páginas, acceso, administración y funciones del plugin. Informa de las prestaciones temporalmente ausentes.
Cuando la versión reparada pase staging, restaura el directorio canónico, activa una vez y revisa registros. El mantenimiento recurrente debe conservar acceso de emergencia e inventario para contener un error fatal sin dañar el resto de WordPress.