Instalar un plugin para cada necesidad parece la solución obvia en GLPI - hasta el día de la actualización, cuando la mitad no vuelve a levantar. Después de años dando soporte a entornos GLPI de clientes, aprendimos que el cuello de botella rara vez es un plugin malo: es la suma de una docena de plugins sueltos, cada uno con su ciclo de versiones, su dependencia y su responsable. Esta guía muestra cómo elegir y combinar extensiones sin caer en el "plugin sprawl", dónde encaja el enfoque modular de NexTool - y, con honestidad, dónde no hace falta.
El problema: el "plugin sprawl"
Cada plugin del ecosistema GLPI es un proyecto aparte: responsable propio, repositorio propio, ritmo de versiones propio. Eso es una fortaleza de la comunidad open source, pero se vuelve un pasivo cuando acumulas una docena de ellos en el mismo entorno. Los síntomas que vemos con más frecuencia:
- Compatibilidad desfasada con el core - GLPI publica una versión mayor y cada plugin necesita su propia actualización para seguirle el paso. Basta con que uno no se haya portado para que todo el entorno se quede bloqueado en la actualización.
- Conflictos entre plugins - dos plugins que sobrescriben el mismo hook, inyectan CSS que compite o registran la misma ruta. El síntoma suele aparecer lejos de la causa.
- Dependencias implícitas - un plugin que solo funciona con otro instalado, sin que eso esté documentado. Desactivar el equivocado tumba una función que nadie asociaba a él.
- Superficie de mantenimiento multiplicada - cada plugin es un changelog que seguir, un CVE que vigilar y un "¿volverá a levantar la próxima vez?" en cada ventana de mantenimiento.
Antes que nada: inventaría lo que ya tienes
Antes de cualquier actualización - y antes de instalar un plugin más - lo primero que hacemos es listar qué está instalado y en qué estado. La consulta que lanzamos directo contra la base de datos:
-- Inventario de los plugins instalados en GLPI y el estado de cada uno.
-- state = 1 significa activado; los demas estados merecen atencion antes de la actualizacion.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Para cada fila que aparezca, tres preguntas: quién lo mantiene, con qué ritmo de versiones y qué se rompe si no levanta en la próxima actualización. Un plugin del que nadie sepa responder es candidato a salir antes de la ventana, no durante.
Los tres enfoques, uno al lado del otro
No toda necesidad pide la misma respuesta. La tabla resume el trade-off entre resolver una carencia con un plugin suelto de la comunidad, con un módulo de NexTool o con una función ya nativa de GLPI 11:
| Criterio | Plugin suelto de la comunidad | Módulo NexTool | Función nativa de GLPI 11 |
|---|---|---|---|
| Dependencias | Una por plugin, muchas veces implícitas | Un único plugin base; módulos probados en conjunto | Ninguna - forma parte del core |
| Actualización | Cada plugin a su ritmo; uno atrasado bloquea la actualización | Un paquete que actualizar, con la compatibilidad probada por el proveedor | Sube junto con GLPI |
| Conflictos | Riesgo real entre plugins de responsables distintos | Menor: los módulos se prueban en conjunto. No elimina los bugs - concentra la responsabilidad en un solo lugar | Cero - es el propio core |
| Cobertura de versiones | Varía según el plugin; puede no existir para tu versión | La base corre en GLPI 10 y 11; cada módulo declara en qué versiones funciona (varios son exclusivos del 11) | Acompaña a la versión instalada |
| Soporte | Comunidad / voluntario, sin SLA | Proveedor único con canal de soporte | Hoja de ruta oficial del proyecto GLPI |
| Dependencia del proveedor | Baja - código abierto, puedes bifurcarlo y mantenerlo | Alta - hoja de ruta, precio y continuidad dependen de una sola empresa | La del propio proyecto GLPI |
| Curva de mantenimiento | Crece con el número de plugins | Plana - un solo punto que seguir | Mínima, pero limitada a lo que cubre el core |
Cómo funciona el enfoque modular
La alternativa no es renunciar a funciones - es reducir el número de cosas independientes que hay que gestionar. NexTool invierte la lógica: en lugar de N plugins, un único plugin base (gratuito) que aloja módulos activados bajo demanda.
- Un único punto de instalación - instalas y actualizas el plugin base; los módulos viven dentro de él, sin que cada uno sea un paquete separado en el marketplace.
- Activa solo lo que usas - el catálogo trae IA, comunicación, documentos, seguridad, automatización y más; enciendes módulo a módulo según la necesidad, sin cargar lo que no usas.
- Sin gestionar dependencias entre módulos - la compatibilidad entre ellos es responsabilidad de un único proveedor, probada en conjunto en cada versión.
- Un catálogo que crece - los módulos nuevos llegan sin exigir una nueva instalación de plugin; aparecen en la pantalla de módulos del plugin ya instalado.
- Base gratuita - el plugin base y buena parte de los módulos son FREE; los licenciados conviven en el mismo lugar y pagas solo por lo que activas.
Lo que aprendimos en el soporte
En un cliente con más de 15 plugins sueltos, una actualización menor de GLPI tumbó la mitad: el entorno levantaba, pero cuatro plugins quedaban en estado "a actualizar" y desaparecían del menú. Lo que nadie esperaba es que un plugin de informes dependía de una tabla que creaba otro plugin - desactivar el segundo borraba silenciosamente el primero. Nos llevó una ventana entera solo mapear qué plugin bloqueaba a cuál. A partir de ahí decidimos tratar cada plugin nuevo como deuda de mantenimiento, no como una función gratis. El error común - que ya cometimos - es instalar un plugin para un único informe y olvidarlo instalado durante dos años, hasta que se convierte en el motivo de que una actualización no cierre.
Para quién es (y cuándo NO usarlo)
El enfoque modular brilla cuando necesitas varias funciones cohesionadas - IA en el ticket, notificación por WhatsApp, orden de trabajo en PDF, flujo de aprobación - y quieres un único proveedor responsable de la compatibilidad y del soporte. Si tu operación vive de ventanas de mantenimiento ajustadas y no puede permitirse una actualización bloqueada por un plugin huérfano, centralizar compensa.
Pero sé honesto sobre lo contrario: si un único plugin de la comunidad ya resuelve bien tu única necesidad, instálalo y sigue adelante - no hay motivo para traer un plugin base para encender un solo módulo. Y, sobre todo, mira primero lo que GLPI ya hace de forma nativa. El inventario nativo (GLPI Inventory, desde GLPI 10) sustituye al antiguo FusionInventory en la mayoría de los casos; los formularios y los objetos personalizados, que exigían FormCreator y GenericObject, se incorporaron al core en GLPI 11. No todo necesita un plugin, y mucho menos NexTool: el mejor plugin suele ser el que no hace falta instalar.
Hay además un trade-off que la centralización no resuelve, solo cambia de sitio: concentrar funciones en un único proveedor concentra también el riesgo. Con plugins sueltos de código abierto, si el responsable abandona el proyecto puedes bifurcarlo y seguir. Con un hub propietario, la hoja de ruta, el precio y la continuidad pasan a depender de una sola empresa. No es motivo para descartar el enfoque - es motivo para evaluar al proveedor como evaluarías a cualquier otro: historial de versiones, canal de soporte y qué pasa con tus datos si decides marcharte.
Cómo activar un módulo
- Instala el plugin base NexTool como cualquier plugin de GLPI: descomprime en
plugins/, luego instala y activa en Configurar > Plugins. - En el menú, ve a Configuración > NexTool > Módulos.
- Localiza el módulo deseado en el catálogo, comprueba qué versiones de GLPI soporta y haz clic en activar.
- Abre la pantalla configurar del módulo y ajusta los parámetros (claves de API, canales, perfiles, lo que corresponda).
- Repite para cada módulo. Ningún paso exige reinstalar el plugin base ni resolver dependencias a mano.
Compatibilidad
El plugin base de NexTool es gratuito y funciona tanto en GLPI 10 como en GLPI 11. La compatibilidad de los módulos, en cambio, se declara módulo a módulo: parte del catálogo es cross-version y funciona en las dos, mientras que buena parte de los módulos más recientes es exclusiva de GLPI 11, porque se apoya en funciones que solo existen allí. El catálogo muestra las versiones que soporta cada módulo, y la activación se bloquea con un mensaje explícito cuando el entorno no es compatible - te enteras antes de instalar, no en mitad de la actualización.
En la práctica, para quien migra del 10 al 11: comprueba en el catálogo cuáles de los módulos que usas son cross-version. Es el mismo inventario que este post recomienda para cualquier plugin - con la diferencia de que aquí la información está en un solo sitio, y no repartida por una docena de repositorios.
Si tu operación ha llegado al punto en que gestionar plugins se ha convertido en un trabajo en sí mismo, vale la pena conocer NexTool como hub modular - o habla con el equipo para evaluar si tu caso pide centralización o si el core ya lo resuelve.
Revisado por el equipo de NexTool Solutions.
