NexTool Solutions

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.

First things first: inventory what you already have

Before any upgrade - and before installing one more plugin - the first thing we do is list 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;

For every row that comes back, three questions: who maintains it, at what release pace, and what breaks if it does not come up on the next upgrade. A plugin nobody can answer for is a candidate to go before the window, not during it.

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:

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.

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. 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.

There is one more trade-off that centralizing does not solve, only relocates: concentrating features in a single vendor concentrates the risk too. With standalone open source plugins, if the maintainer walks away you can fork and carry on. With a proprietary hub, roadmap, pricing and continuity come to depend on one company. That is not a reason to rule the approach out - it is a reason to assess the vendor the way you would assess any other: release track record, support channel, and what happens to your data if you decide to leave.

How to enable a module

1. Install the NexTool base plugin like any GLPI plugin: unpack into plugins/, then install and activate under Setup > Plugins.
2. In the menu, go to Configuration > NexTool > Modules.
3. Find the module you want in the catalog, check which GLPI versions it supports and click enable.
4. Open the module's configure screen and set the parameters (API keys, channels, profiles, whatever applies).
5. Repeat for each module. No step requires reinstalling the base plugin or resolving dependencies by hand.

Compatibility

The NexTool base plugin is free and runs on both GLPI 10 and GLPI 11. Module compatibility, however, is declared module by module: part of the catalog is cross-version and runs on both, while much of the newer catalog is GLPI 11 only, because it builds on features that exist only there. The catalog shows the versions each module supports, and activation is blocked with an explicit message when the environment is not compatible - you find out before installing, not in the middle of the upgrade.

In practice, for anyone migrating from 10 to 11: check in the catalog which of the modules you use are cross-version. It is the same inventory this post recommends for any plugin - the difference being that here the information sits in one place, instead of scattered across a dozen repositories.

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.

Reviewed by the NexTool Solutions team.