¿Por qué hay plugins WordPress que no se borran del todo? ¿Cómo me deshago de ellos?

¿A que es fácil instalar plugins WordPress? Pero ¿y desinstalarlos?, igual de fácil ¿no?. Pues no, resulta que no siempre es fácil desinstalar completamente un plugin, y por completamente me refiero a borrarlo del todo, sin que quede rastro alguno del plugin en tu instalación.

En un mundo ideal, al desinstalar un plugin WordPress no quedaría ningún resto de que ese plugin ha estado alguna vez instalado y/o activo en tu sitio, pero eso no es siempre así.

Como ya vimos en la guía para desinstalar plugins de caché, a veces quedan restos en la base de datos, archivos sueltos, incluso añadidos a los archivos de configuración .htaccess y wp-config.php.

Y no son cosas menores, pues tanto los registros en los archivos de configuración como entradas en la base de datos pueden provocar conflictos e incluso que tu web deje de funcionar.

Entonces ¿cómo se desinstala completamente un plugin? Pero antes…

Motivos para desinstalar un plugin WordPress

Porque antes de desinstalar un plugin deberías plantearte por qué quieres hacerlo, y pueden ser varias las razones…

No me sirve para lo que necesitaba – Pasa mucho que, tras instalar un plugin que en principio parecía que iba a cubrir nuestras necesidades, tras activarlo, comprobamos que o le falta alguna herramienta o simplemente no funciona correctamente o como esperabas.
Ya no lo necesitas – Es muy común que, tras un tiempo usando un plugin descubras que ya no lo necesitas, bien porque has comprobado que no aporta nada relevante a tu web, bien porque lo has sustituido por otro, o por una función que hace lo mismo.
No funciona – Pasa menos pero también puede ocurrir que instales un plugin y no funcione en absoluto, o que incluso provoque un error en tu instalación. Y da lo mismo si lo instalas desde el directorio oficial de WordPress u otro sitio, a veces pasa.
Contiene código malicioso – Esta sería la peor situación de todas, cuando descubres que, tras instalar un plugin, este contiene código malintencionado que podría arruinar tu web, tu SEO, tu reputación, todo. Especialmente en este tipo de casos es dónde deberías ser más exhaustivo a la hora de desinstalarlo, asegurándote de que no deja ningún rastro (malware, o puertas traseras, por ejemplo), y si no estás seguro contratar profesionales para que limpien la instalación por ti.

¿Por qué los plugins dejan restos tras desinstalarlos?

¿Son mala gente los desarrolladores de plugins? ¿tienen algún pacto secreto para llenar de basura huérfana en nuestras bases de datos? ¿quieren acaso dejar un vestigio de su paso por el planeta?

No pienses mal, pues salvo en el caso de que el plugin contenga código malicioso, normalmente hay «motivos inocentes» para que un plugin no se desinstale completamente.

Los principales motivos por los que un plugin no se desinstale completamente al desactivarlo o incluso borrarlo son estos:

Conservar ajustes – Los desarrolladores saben que, en ocasiones, puedes desinstalar o incluso borrar su plugin pero que, más tarde, puedes decidir volver a instalarlo, y algunos plugins conservan sus configuraciones en la base de datos y más sitios, por si posteriormente decides volver a instalarlo, para evitarte la tarea de volver a configurarlo completamente. Un ejemplo típico es WooCommerce, del que ya expliqué cómo desinstalarlo completamente mediante un truco.
El desinstalador de WordPress – La aplicación de desinstalación de WordPress no es perfecta, y a veces puede fallar a la hora de desinstalar completamente un plugin, no eliminando todo lo que debería.
Error o desconocimiento del desarrollador – Más común es que, por error o desconocimiento por parte del desarrollador, no incorpore las rutinas necesarias para desinstalar completamente todos los archivos, registros y configuraciones de su plugin.
Inyectar código malicioso – Por supuesto, si el objetivo de un plugin es inyectar malware, puertas traseras o cualquier otro código malintencionado, se cuidará mucho de que aunque borres y desinstales el plugin deje por ahí en tu instalación su código.

¿Cómo borrar completamente un plugin?

Ahora que ya sabemos los motivos y razones, si ya tienes claro que quieres desinstalar del todo algún plugin, veamos cómo hacerlo completamente.

Primero comprobamos si el plugin nos ofrece un borrado completo

No es algo que hagan la mayoría de los plugins, pero sí que es cierto que algunos plugins ofrecen en su página de ajustes una configuración para que, al desinstalar el plugin, se borre todo resto del mismo, y es algo a aprovechar, siempre que esté disponible.

Así que, antes de siquiera desactivar el plugin del que quieras deshacerte, pásate por sus ajustes, y busca a ver si hay alguna casilla que te ofrezca esta posibilidad.

Por ejemplo, el plugin Redirection sería el modo perfecto de hacerlo, pues si pulsas el botón de borrar el plugin, no solo borra todo rastro del mismo en base de datos y archivos, sino que de paso lo desactiva. Luego solo te quedaría borrarlo desde el desinstalador de WordPress.

Pero no es lo habitual, como mucho te encontrarás algo parecido a lo que ofrece por ejemplo WordFence.

En sus opciones generales verás una casilla que, si la activas y guardas los cambios, al desinstalar el plugin se borrarán todos sus ajustes.

¿No hay plugins para eso?

Los plugins de seguridad en ocasiones tienen una herramienta de detección de cambios frente a los archivos originales del directorio de plugins y el núcleo de WordPress, pero solo lo comprueban con la vista puesta en la seguridad, así que no será completo.

Mi consejo es que siempre lo revises manualmente.

A continuación le daremos una oportunidad al desinstalador de WordPress

Aunque puedas pensar mal (y a veces acertarás) y creer que ¿para qué confiar en el desinstalador de WordPress si es posible que queden restos? ¿no será mejor borrar el plugin manualmente desde FTP o el administrador de archivos del hosting? te equivocas en el orden.

Si primero borras el plugin por FTP o un gestor de archivos estás desperdiciando la posibilidad de que las rutinas del plugin, mediante el desinstalador de WordPress, borren no solo la carpeta del plugin y sus archivos, sino también otros elementos que, de hacerlo manualmente borrando la carpeta del plugin, no hará.

Así que el siguiente paso siempre será usar el desinstalador de WordPress, que comprende 2 pasos:

Desactivar el plugin.
Borrar el plugin.

Será a partir de aquí cuando nos pondremos en modo CSI para empezar a buscar más posibles restos.

CSI de archivos

Entramos en el modo de investigación, casi siempre a ciegas, en este caso de archivos o código añadido a archivos que haya podido dejar el plugin tras desactivarlo y borrarlo.

Como te digo, aquí vamos a ciegas, salvo que el desarrollador haya tenido el detalle de incluir en el archivo README del plugin el detalle de todo lo que añade a nuestra instalación y cómo quitarlo, algo que no suele ser nada común, y debería ser incluso obligatorio.

Mi línea de investigación en estos casos suele ser en este orden:

Comprobar que se ha borrado del todo la carpeta del plugin y los archivos que contiene. Estará en la carpeta /wp-content/plugins/nombre-del-plugin/.
Comprobar si el plugin ha dejado algún archivo o carpeta en la carpeta /wp-content/plugins/, algo muy común en plugins de caché y optimización.
Comprobar si el plugin ha dejado algún archivo o carpeta en la carpeta /wp-content/, habitual en plugins de caché, optimización, galerías, avatares, seguridad, backups, casi de todo.
Comprobar si el plugin ha dejado algún archivo o carpeta en la carpeta /wp-content/uploads, bastante probable en plugins de galerías, avatares, backups, etc.
Comprobar si el plugin ha dejado líneas en el archivo .htaccess, muy probable en plugins de optimización, caché, seguridad y SEO.
Comprobar si el plugin ha dejado líneas en el archivo wp-config.php, bastante probable en plugins de optimización, caché y seguridad.
Comprobar si el plugin ha dejado líneas en el archivo php.ini, posible con plugins de optimización.
Comprobar si el plugin ha dejado algún archivo en la carpeta raíz (/) de la instalación, habitual en plugins de seguridad.
Comprobar la integridad de todos los archivos PHP y JS, en el caso de plugins sospechosos de incluir código malicioso.

Como verás, no es algo trivial, y la experiencia te enseña que no debes dejar nada al azar, para no tener que lamentarte.

CSI de la base de datos

Aquí entramos en terreno pantanoso, con arenas movedizas, en una noche oscura sin luna, con niebla, animales peligrosos y plantas venenosas.

Esta es la parte más difícil y complicada de limpiar, pues los desarrolladores de plugins no siempre ayudan a la hora de identificar qué tablas y opciones añaden.

¿Tanto cuesta poner a las tablas y opciones de tu plugin un nombre único, que las distinga del resto?

Pues parece ser que sí, y solo mucha experiencia y años viendo bases de datos de instalaciones de WordPress te ayudarán en esta tarea de distinguir unas tablas y opciones de otras, aunque ya te anticipo que en ocasiones será imposible detectar a qué plugin pertenecen algunas.

El primer paso, y más sencillo, es detectar posibles tablas del plugin, y para eso no hay mejor comienzo que saber qué tablas son de WordPress y cuáles no.

En el ejemplo anterior hemos identificado las 12 tablas de cualquier instalación limpia de WordPress, así que las otras 2 tablas, lógicamente, pertenecerán a algún plugin o tema, que también habrá.

Ahora ¿cómo saber a qué plugin pertenecen esas tablas?

En mi (triste a veces) experiencia, el método que suelo seguir para «adivinar» a qué plugin o tema pertenece una tabla es el siguiente:

Reviso la instalación de WordPress apuntando el nombre de cada plugin y tema, activo o inactivo, y los apunto o capturo. A continuación compruebo si el nombre de la tabla contiene el nombre del plugin o tema. Por ejemplo, si el plugin se llama Redirection, compruebo si alguna tabla se llama prefijo_redirection_log o similar.
Reviso de nuevo la instalación de WordPress apuntando el nombre de la empresa o desarrollador de cada plugin y tema, activo o inactivo. Y compruebo si, en vez del nombre del plugin, el desarrollador ha nombrado sus tablas con su propio nombre o el de su empresa. Si no encuentro el plugin por su nombre, y la empresa es, digamos, Automattic, busco una tabla que se llame prefijo_automattic_algo.
Hago lo mismo que en los 2 pasos anteriores, pero ahora con solamente las iniciales del nombre del plugin/tema/desarrollador/empresa. Un ejemplo podría ser el plugin si el plugin se llama SiteGround Security y encuentro una tabla que se llame prefijo_sgs_algo. Si te fijas, es precisamente lo que pasa en la captura anterior, donde hay 2 tablas denominadas bvx_sgs_logs_events y bvx_sgs_log_visitors. No es todo lo intuitivo que podría ser, pero se adivina – si antes has comprobado que el plugin SiteGround Security está instalado – que son tablas que almacenan registros (logs) de eventos y visitantes, como es el caso de este plugin, que tiene una herramienta para esta función precisamente.
Si todo lo anterior falla, abro la tabla por si alguno de sus registros me da una pista de qué información almacena o a qué plugin pertenece.

De este último caso esta captura sería un ejemplo real:

Inicialmente, la tabla llamada gce_zbs_settings lo único que me dice es que es de ajustes (settings) de algo llamado zbs.

Pero resulta que no hay nada instalado que se llame ZBS ni de ninguna empresa que tenga esas iniciales, así que abro la tabla y, en uno de los registros, identifico que uno de los ajustes indica que se ha configurado algo en el sitio como «CRM Bisnis», y ya sé que es un plugin de CRM.

Y, sorpresa, hay un plugin instalado, llamado Jetpack CRM que, investigando, anteriormente pertenecía a la empresa Zero BS (de ahí el zbs), compañía que compró Automattic, y luego renombró el plugin, pero ha mantenido la estructura de las tablas y opciones de la base de datos.

Parece enrevesado el proceso, pero te vas a encontrar muchas veces casos así de raros o incluso peores.

Lo bueno es que, tras hacer esta investigación (¿ves como era un CSI?), ya puedo borrar todas las tablas y opciones que contengan zbs si sé que ya no voy a utilizar el plugin Jetpack CRM en esa instalación.

¿Crees que has terminado? ¡ni de coña! Ahora toca revisar las tablas estándar de WordPress, con especial cuidado de la tabla options.

De hecho yo siempre empiezo por la tabla options de WordPress.

Y el proceso es el mismo para los registros de la tabla options que el que hemos visto para las tablas, exactamente igual.

Si tienes suerte, y ya diste con algún identificador válido del plugin a borrar, estás de enhorabuena, pero no siempre vas a tener tanta suerte.

En ocasiones te vas a encontrar con tablas y opciones en las que ni el nombre, ni el contenido de la misma te dará pista alguna de a qué pertenece o ha pertenecido, y te tocará tomar una de estas 2 decisiones:

Borrar la tabla/opción y ver si pasa algo.
Dejar la tabla/opción sin borrar, asumiendo ese tamaño extra posiblemente innecesario.

En estos casos, un paso intermedio que siempre hago y te recomiendo en los registros huérfanos de la tabla options es cambiar el valor de Autoload a no, y comprobar si en una siguiente carga de la web se ha cambiado a yes, lo que indicaría que el registro pertenece a un plugin o función activa, con lo que tocaría revisar de nuevo la instalación.