Cada plugin instalado añade código que se ejecuta en el servidor, rutas públicas, tablas, opciones y una relación con un proveedor. Mantener código propio traslada esa carga al equipo y la convierte en trabajo visible. La decisión rara vez es binaria. Suele afectar a piezas concretas, y cada pieza admite una respuesta distinta.
Seis criterios para decidir
- Superficie de ataque. Un plugin suele traer más funciones de las que un sitio usa, y todo su código es alcanzable aunque la función no se utilice. El código propio también tiene superficie, pero se limita a lo que se escribió. Reducir superficie equivale a reducir el número de piezas que pueden fallar de forma explotable.
- Auditabilidad. El código que vive en el repositorio se lee, se revisa y se versiona. El de un plugin comercial depende de lo que el proveedor publique. La verificación de checksums de WP-CLI solo cubre plugins del directorio oficial, de modo que los comerciales y los propios quedan fuera y para estos últimos la referencia es el repositorio.
- Licencia. Determina quién puede recibir actualizaciones, modificar el código o redistribuirlo. Cuando los parches dependen de una licencia de pago vigente, un descuido administrativo equivale a quedarse sin parches. Conviene registrar la condición de renovación de cada licencia.
- Ritmo de parches. Se mide con la fecha de la última versión, el tiempo que tardó el proveedor en responder a fallos conocidos y la distancia entre la versión instalada y la última publicada. Un ritmo lento con vulnerabilidades documentadas inclina la balanza hacia la sustitución.
- Coste de mantenimiento. El código propio exige compatibilidad con las versiones de WordPress, del constructor de páginas y de PHP, pruebas, documentación y corrección de defectos. Ese coste no desaparece al retirar el plugin. El riesgo cambia de dueño.
- Capacidad del equipo. Importan los conocimientos de la API del constructor, el tiempo disponible para soporte y el número de personas que entienden cada pieza. Si solo una persona sabe mantener una pieza, la sustitución crea una dependencia de persona.
Criterio de decisión
| Criterio | Favorece depender | Favorece código propio | Pregunta de comprobación |
|---|---|---|---|
| Superficie de ataque | Se usa casi toda la funcionalidad del plugin | Se usa una fracción pequeña | ¿Cuántas funciones del plugin se emplean realmente? |
| Auditabilidad | Código abierto, revisado por una comunidad amplia | Código cerrado o sin forma de verificar su integridad | ¿Puede comprobarse que el código instalado es el publicado? |
| Licencia | Actualizaciones garantizadas sin condiciones | Parches condicionados a un pago o a un proveedor concreto | ¿Qué ocurre con los parches si la licencia caduca? |
| Ritmo de parches | Versiones frecuentes y respuesta rápida a fallos | Fallos conocidos sin corregir durante meses | ¿Cuánto separa la versión instalada de la última? |
| Coste de mantenimiento | Función compleja y estable, de alto coste de reproducir | Función acotada y fácil de probar | ¿Cuánto trabajo trimestral exigirá mantenerlo? |
| Capacidad del equipo | Poco tiempo y poca experiencia con la API | Conocimiento disponible y más de una persona que lo mantenga | ¿Quién corrige un defecto un lunes a primera hora? |
Ninguna fila decide por sí sola. La tabla ordena la conversación y señala dónde faltan datos. Las preguntas sin respuesta indican qué medir antes de decidir.
Método de sustitución gradual
La sustitución se aborda pieza a pieza y se detiene cuando falta una verificación.
Cargando diagrama...
- Inventario de dependencias. Por cada plugin se anotan la función que cumple realmente, dónde se usa (contenidos, plantillas, opciones, tablas), la versión, la licencia, la fecha de la última actualización y si está activo. Entran también las dependencias indirectas, como filtros del plugin a los que el código propio engancha lógica o metadatos que el código lee con el formato del plugin.
- Equivalencia funcional. Se reproduce el subconjunto que se usa, no el producto completo. Los criterios de aceptación se escriben antes de programar. Una forma de comprobarlos es comparar el HTML renderizado de una pieza antes y después de migrarla.
- Migración por pieza con copia previa y verificación. Primero una copia del contenido y un piloto sobre una sola entrada. Después una simulación que cuente cuántos elementos se tocarán, la aplicación y la verificación. Verificar incluye un barrido de URLs, la búsqueda de rastros del plugin en el HTML servido y el vaciado de todas las cachés, incluida la caché de render del constructor.
- Retirada solo cuando nada activo depende. Se buscan referencias en contenido publicado, borradores, plantillas, metadatos, opciones, revisiones, CSS personalizado y código propio. Se desactiva antes de borrar. Los borrados irreversibles esperan una confirmación expresa y una copia que permita recuperar lo que se pierda.
La misma disciplina de simulación por defecto y copia previa se describe en agente de IA, reglas escritas y escritura segura. El inventario previo a cualquier eliminación se trata con más detalle en migración de URLs, inventario, 301 y QA.
Errores típicos
- Reproducir el plugin entero. Programar todas sus funciones cuando el sitio usa tres multiplica el coste y la superficie.
- Retirar antes de migrar. Si el plugin se desactiva con el contenido sin convertir, los bloques desaparecen de las páginas sin un aviso visible.
- Olvidar la caché de render del constructor. Puede seguir sirviendo marcado antiguo después de la migración, y un barrido de URLs que compruebe solo el código de respuesta no lo detecta.
- Dejar los scripts de migración fuera del control de versiones. Sin ellos no hay un comando que repita la operación en otro entorno.
- Escribir IDs fijos en los scripts de limpieza. Los IDs son de cada instalación y un script con identificadores copiados borra o modifica contenido ajeno.
- Migrar los datos y conservar la lectura del formato antiguo. El código propio que sigue leyendo metadatos con el formato del plugin retirado mantiene una dependencia de datos.
- Reintroducir contenido fijo en el código propio. Los textos, listas e iconos de negocio escritos en una plantilla devuelven el problema a otro sitio. Los controles y los repetidores del constructor lo evitan.
- Publicar valores de ejemplo. Un componente que rellena textos de muestra cuando el campo está vacío acaba mostrándolos en una página real.
- No auditar el código propio con los mismos criterios. Los defectos propios existen. Un recorrido sistemático por los controles de edición suele encontrar secciones sin ajustes de tipografía o duplicados de controles.
- Sustituir sin una medición previa. Sin referencia anterior, cualquier conclusión sobre rendimiento o tiempo de mantenimiento queda sin respaldo.
Del caso al principio
Estos criterios se aplicaron a una web WordPress cuyos widgets vivían en plugins de terceros con vulnerabilidades conocidas y sin parchear. La sustitución por una biblioteca propia de widgets de Elementor siguió el método anterior, con piloto, simulación, copia previa y barrido de URLs. El caso recoge las reglas de la biblioteca, los errores documentados y lo que quedó sin medir en sustituir plugins de widgets de terceros por una biblioteca propia de Elementor.
La auditabilidad se gana y el mantenimiento se asume. Ese trabajo pasa a ser visible, y la capacidad del equipo pesa tanto como la superficie de ataque.