Instalar un plugin para cada necesidad parece la jugada obvia en GLPI - hasta el día de la actualización, cuando la mitad no vuelve a arrancar. Tras años manteniendo parques 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 fuerza 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 seguir el ritmo. Basta con que uno no se haya portado para que todo el entorno se bloquee en la actualización.
- Conflictos entre plugins - dos plugins que sobrescriben el mismo hook, inyectan CSS en competencia 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 "¿arrancará la próxima vez?" en cada ventana de mantenimiento.
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 nuevos módulos llegan sin exigir una nueva instalación de plugin; aparecen en la pantalla de módulos del plugin que ya tienes.
- Una base gratuita - el plugin base y buena parte del catálogo son FREE; los módulos con licencia conviven en el mismo lugar, y pagas solo por lo que activas.
Cómo activarlo
- 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 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.
Los tres enfoques, lado a lado
No toda necesidad pide la misma respuesta. La tabla resume el equilibrio entre cubrir un hueco 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 / upgrade | Cada plugin a su ritmo; uno atrasado bloquea la actualización | Un paquete que actualizar, compatibilidad garantizada por el proveedor | Sube junto con GLPI |
| Conflictos | Riesgo real entre plugins de responsables distintos | Los módulos conviven en el mismo espacio, sin colisión de hooks | Cero - es el propio core |
| Soporte | Comunidad / voluntario, sin SLA | Proveedor único con canal de soporte | Hoja de ruta oficial del proyecto GLPI |
| Curva de mantenimiento | Crece con el número de plugins | Plana - un punto que seguir | Mínima, pero limitada a lo que cubre el core |
Antes de cualquier actualización, lo primero que hacemos es inventariar lo que está instalado y en qué estado. La consulta que ejecutamos directo en 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 del upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;Lo que aprendimos en el mantenimiento
En un cliente con más de 15 plugins sueltos, una actualización menor de GLPI tumbó la mitad: el entorno arrancaba, 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 en silencio 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 función gratis: antes de instalar, la pregunta pasó a ser "¿quién lo mantiene, a qué ritmo de versiones y qué se rompe si no arranca en la próxima actualización?". El error común - que ya cometimos - es instalar un plugin para un único informe y olvidarlo instalado durante dos años, hasta que es 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 servicio 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 con lo contrario: si un único plugin de la comunidad ya resuelve bien tu única necesidad, instálalo y sigue adelante - no hay por qué 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 tienes que instalar.
Compatibilidad
El plugin base de NexTool es gratuito y corre tanto en GLPI 10 como en GLPI 11 - los módulos funcionan en ambas versiones sin adaptación. Eso importa en la práctica: quien migra del 10 al 11 mantiene la misma base de módulos en ambos lados, sin reescribir la integración. Los módulos con licencia conviven con los gratuitos en la misma pantalla, y activas solo lo que necesitas.
Si tu operación llegó al punto en que gestionar plugins se volvió un trabajo en sí mismo, vale la pena conocer NexTool como hub modular - o habla con el equipo para evaluar si tu caso pide centralizar o si el core ya lo resuelve.
Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de Nextool Solutions.
