Instalar um plugin para cada necessidade parece a solução óbvia no GLPI - até o dia do upgrade, quando metade deles não sobe. Depois de anos sustentando ambientes GLPI de clientes, aprendemos que o gargalo raramente é um plugin ruim: é a soma de uma dúzia de plugins avulsos, cada um com seu ciclo de release, sua dependência e seu mantenedor. Este guia mostra como escolher e combinar extensões sem cair no "plugin sprawl", onde a abordagem modular do NexTool encaixa - e, com honestidade, onde ela não é necessária.
O problema: o "plugin sprawl"
Cada plugin do ecossistema GLPI é um projeto à parte: mantenedor próprio, repositório próprio, ritmo de release próprio. Isso é uma força da comunidade open source, mas vira passivo quando você acumula uma dúzia deles no mesmo ambiente. Os sintomas que vemos com mais frequência:
- Compatibilidade descasada com o core - o GLPI lança uma versão maior e cada plugin precisa de uma atualização própria para acompanhar. Basta um não ter sido portado para o ambiente inteiro travar no upgrade.
- Conflitos entre plugins - dois plugins que sobrescrevem o mesmo hook, injetam CSS concorrente ou registram a mesma rota. O sintoma costuma aparecer longe da causa.
- Dependências implícitas - um plugin que só funciona com outro instalado, sem que isso esteja documentado. Desligar o errado derruba uma função que ninguém associava a ele.
- Superfície de manutenção multiplicada - cada plugin é um changelog para acompanhar, um CVE para vigiar e um "será que sobe na próxima?" a cada janela de manutenção.
Como funciona a abordagem modular
A alternativa não é abrir mão de recursos - é reduzir o número de coisas independentes que precisam ser gerenciadas. O NexTool inverte a lógica: em vez de N plugins, um único plugin base (gratuito) que hospeda módulos ativados sob demanda.
- Um único ponto de instalação - você instala e atualiza o plugin base; os módulos vivem dentro dele, sem cada um ser um pacote separado no marketplace.
- Ative só o que usa - o catálogo traz IA, comunicação, documentos, segurança, automação e mais; você liga módulo a módulo conforme a necessidade, sem carregar o que não usa.
- Sem gerenciar dependências entre módulos - a compatibilidade entre eles é responsabilidade de um único fornecedor, testada em conjunto a cada release.
- Catálogo que cresce - novos módulos chegam sem exigir uma nova instalação de plugin; aparecem na tela de módulos do plugin já instalado.
- Base gratuita - o plugin base e boa parte dos módulos são FREE; os licenciados convivem no mesmo lugar, e você paga só pelo que ativa.
Como ativar
- Instale o plugin base NexTool como qualquer plugin do GLPI: descompacte em
plugins/, depois instale e ative em Configurar > Plugins. - No menu, vá em Configuração > NexTool > Módulos.
- Localize o módulo desejado no catálogo e clique em ativar.
- Abra a tela configurar do módulo e ajuste os parâmetros (chaves de API, canais, perfis, o que couber).
- Repita para cada módulo. Nenhum passo exige reinstalar o plugin base nem resolver dependências à mão.
As três abordagens, lado a lado
Nem toda necessidade pede a mesma resposta. A tabela resume o trade-off entre resolver uma lacuna com um plugin avulso da comunidade, com um módulo do NexTool ou com um recurso já nativo do GLPI 11:
| Critério | Plugin avulso da comunidade | Módulo NexTool | Recurso nativo do GLPI 11 |
|---|---|---|---|
| Dependências | Uma por plugin, muitas vezes implícitas | Um único plugin base; módulos testados em conjunto | Nenhuma - faz parte do core |
| Atualização / upgrade | Cada plugin no seu ritmo; um atrasado trava o upgrade | Um pacote para atualizar, compatibilidade garantida pelo fornecedor | Sobe junto com o GLPI |
| Conflitos | Risco real entre plugins de mantenedores diferentes | Módulos convivem no mesmo espaço, sem colisão de hooks | Zero - é o próprio core |
| Suporte | Comunidade / voluntário, sem SLA | Fornecedor único com canal de suporte | Roadmap oficial do projeto GLPI |
| Curva de manutenção | Cresce com o número de plugins | Plana - um ponto para acompanhar | Mínima, mas limitada ao que o core cobre |
Antes de qualquer upgrade, a primeira coisa que fazemos é inventariar o que está instalado e em que estado. A consulta que rodamos direto no banco:
-- Inventario dos plugins instalados no GLPI e o estado de cada um.
-- state = 1 significa ativado; os demais estados merecem atencao antes do upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;O que aprendemos na sustentação
Num cliente com mais de 15 plugins avulsos, um upgrade menor do GLPI derrubou metade deles: o ambiente subia, mas quatro plugins ficavam em estado "a atualizar" e sumiam do menu. O que ninguém esperava é que um plugin de relatórios dependia de uma tabela que outro plugin criava - desligar o segundo apagava silenciosamente o primeiro. Levamos uma janela inteira só para mapear qual plugin travava qual. Decidimos, a partir dali, tratar cada plugin novo como dívida de manutenção, não como recurso grátis: antes de instalar, a pergunta passou a ser "quem mantém, com que ritmo de release e o que quebra se ele não subir no próximo upgrade?". O erro comum - que já cometemos - é instalar um plugin para um único relatório e esquecê-lo instalado por dois anos, até ele ser o motivo de um upgrade não fechar.
Para quem é indicado (e quando NÃO usar)
A abordagem modular brilha quando você precisa de vários recursos coesos - IA no chamado, notificação por WhatsApp, ordem de serviço em PDF, fluxo de aprovação - e quer um único fornecedor responsável pela compatibilidade e pelo suporte. Se a sua operação vive de janelas de manutenção apertadas e não pode se dar ao luxo de um upgrade travado por um plugin órfão, centralizar compensa.
Mas seja honesto sobre o oposto: se um único plugin da comunidade já resolve bem a sua única necessidade, instale-o e siga em frente - não há por que trazer um plugin base para ligar um módulo só. E, principalmente, olhe primeiro para o que o GLPI já faz nativamente. O inventário nativo (GLPI Inventory, desde o GLPI 10) substitui o antigo FusionInventory na maioria dos casos; os formulários e os objetos personalizados, que exigiam FormCreator e GenericObject, foram incorporados ao core no GLPI 11. Nem tudo precisa de plugin, e muito menos de NexTool: o melhor plugin costuma ser o que você não precisa instalar.
Compatibilidade
O plugin base do NexTool é gratuito e roda tanto no GLPI 10 quanto no GLPI 11 - os módulos funcionam nas duas versões sem adaptação. Isso importa na prática: quem está migrando do 10 para o 11 mantém a mesma base de módulos dos dois lados, sem reescrever integração. Os módulos licenciados convivem com os gratuitos na mesma tela, e você ativa apenas o que precisa.
Se a sua operação chegou ao ponto em que gerenciar plugins virou um trabalho por si só, vale conhecer o NexTool como hub modular - ou fale com a equipe para avaliar se o seu caso pede centralização ou se o core já resolve.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
