Installing a plugin for every need looks like the obvious GLPI move - until upgrade day, when half of them fail to come back up. After years sustaining client GLPI estates, we learned the bottleneck is rarely a bad plugin: it is the sum of a dozen standalone plugins, each with its own release cycle, its own dependency and its own maintainer. This guide shows how to pick and combine extensions without falling into "plugin sprawl", where NexTool's modular approach fits - and, honestly, where it is not needed.
The problem: "plugin sprawl"
Every plugin in the GLPI ecosystem is a separate project: its own maintainer, its own repository, its own release pace. That is a strength of the open source community, but it becomes a liability once you stack a dozen of them in the same environment. The symptoms we see most often:
- Core compatibility drift - GLPI ships a major version and each plugin needs its own update to keep up. Just one that was not ported is enough to freeze the whole environment on the upgrade.
- Plugin-to-plugin conflicts - two plugins overriding the same hook, injecting competing CSS or registering the same route. The symptom usually shows up far from the cause.
- Implicit dependencies - a plugin that only works with another one installed, without that being documented. Disabling the wrong one takes down a function nobody linked to it.
- Multiplied maintenance surface - each plugin is a changelog to follow, a CVE to watch and a "will it come back up next time?" at every maintenance window.
How the modular approach works
The alternative is not giving up features - it is reducing the number of independent things you have to manage. NexTool flips the logic: instead of N plugins, a single base plugin (free) that hosts modules enabled on demand.
- A single install point - you install and update the base plugin; the modules live inside it, none of them a separate marketplace package.
- Enable only what you use - the catalog covers AI, communication, documents, security, automation and more; you switch modules on one by one as needed, without carrying what you do not use.
- No dependency juggling between modules - compatibility between them is one vendor's responsibility, tested together on every release.
- A growing catalog - new modules arrive without requiring a fresh plugin install; they show up in the modules screen of the plugin you already have.
- A free base - the base plugin and much of the catalog are FREE; the licensed modules live in the same place, and you pay only for what you enable.
How to enable it
- Install the NexTool base plugin like any GLPI plugin: unpack into
plugins/, then install and activate under Setup > Plugins. - In the menu, go to Configuration > NexTool > Modules.
- Find the module you want in the catalog and click enable.
- Open the module's configure screen and set the parameters (API keys, channels, profiles, whatever applies).
- Repeat for each module. No step requires reinstalling the base plugin or resolving dependencies by hand.
The three approaches, side by side
Not every need calls for the same answer. The table sums up the trade-off between filling a gap with a standalone community plugin, with a NexTool module or with a feature already native to GLPI 11:
| Criterion | Standalone community plugin | NexTool module | Native GLPI 11 feature |
|---|---|---|---|
| Dependencies | One per plugin, often implicit | A single base plugin; modules tested together | None - part of the core |
| Update / upgrade | Each plugin on its own pace; a late one freezes the upgrade | One package to update, compatibility guaranteed by the vendor | Ships with GLPI itself |
| Conflicts | Real risk between plugins from different maintainers | Modules coexist in the same space, no hook collisions | Zero - it is the core |
| Support | Community / volunteer, no SLA | Single vendor with a support channel | Official GLPI project roadmap |
| Maintenance curve | Grows with the number of plugins | Flat - one point to follow | Minimal, but limited to what the core covers |
Before any upgrade, the first thing we do is inventory what is installed and in what state. The query we run straight against the database:
-- Inventory of plugins installed in GLPI and the state of each one.
-- state = 1 means activated; the other states deserve attention before the upgrade.
SELECT directory AS plugin,
name,
version,
state
FROM glpi_plugins
ORDER BY state, directory;What we learned in sustainment
At one client with more than 15 standalone plugins, a minor GLPI upgrade took down half of them: the environment came up, but four plugins sat in a "to be updated" state and vanished from the menu. What nobody expected was that a reporting plugin depended on a table another plugin created - disabling the second silently wiped the first. We spent an entire window just mapping which plugin froze which. From then on we decided to treat every new plugin as maintenance debt, not a free feature: before installing, the question became "who maintains it, at what release pace, and what breaks if it does not come up on the next upgrade?". The common mistake - one we have made - is installing a plugin for a single report and forgetting it installed for two years, until it becomes the reason an upgrade will not close.
Who it is for (and when NOT to use it)
The modular approach shines when you need several cohesive features - AI on the ticket, WhatsApp notifications, PDF work orders, an approval flow - and want a single vendor accountable for compatibility and support. If your operation lives on tight maintenance windows and cannot afford an upgrade frozen by an orphaned plugin, centralizing pays off.
But be honest about the opposite: if a single community plugin already solves your one need well, install it and move on - there is no reason to bring in a base plugin to switch on a single module. And above all, look first at what GLPI already does natively. Native inventory (GLPI Inventory, since GLPI 10) replaces the old FusionInventory in most cases; the custom forms and objects that used to require FormCreator and GenericObject were folded into the core in GLPI 11. Not everything needs a plugin, let alone NexTool: the best plugin is often the one you do not have to install.
Compatibility
The NexTool base plugin is free and runs on both GLPI 10 and GLPI 11 - the modules work on both versions with no adaptation. That matters in practice: anyone migrating from 10 to 11 keeps the same module base on both sides, without rewriting integrations. Licensed modules coexist with the free ones on the same screen, and you enable only what you need.
If your operation has reached the point where managing plugins became a job in itself, it is worth looking at NexTool as a modular hub - or talk to the team to assess whether your case calls for centralizing or whether the core already covers it.
This content was produced with the assistance of artificial intelligence and reviewed by the Nextool Solutions team.
