Why GLPI plugins stop working after a major update and what to plan for
Since GLPI 11.0, plugins are suspended as soon as a new GLPI version is detected, and they must be reactivated after a major update. For a team running a self-hosted GLPI 10 instance with plugins, this means the upgrade is not finished when the application files are replaced and php bin/console db:update completes. Every plugin in use has to be checked, updated where a compatible release exists, reactivated, and tested, one at a time. The supported path from GLPI 10 to 11 is the one to plan around, and GLPI 11.0.0 was released on October 1, 2025, with 11.0.11 following on October 1, 2026. GLPI 12.0.0 was released on October 7, 2026, so any upgrade that also targets 12 needs its own compatibility review before the first move.
The suspension is a safety measure, and the work it forces is plugin by plugin rather than a single switch. Start by listing every active plugin in the GLPI 10 instance, recording its version, its maintainer, and whether its features are now provided by the core. Plugins that have been absorbed into GLPI 11, such as the ones covered by the Formcreator, Generic Objects and Racks and Domains migration paths, should be retired or replaced rather than reactivated. For the rest, confirm with each maintainer that a release supports the target GLPI version, and check the plugin's own changelog for database or PHP requirements. The GLPI installation docs on updating GLPI describe the suspension behavior, and the GLPI command-line documentation lists the plugin:suspend_execution and plugin:resume_execution commands that control it.
Plan the reactivation on a copy of the GLPI 10 database, not on production. Restore the backup into a staging instance with the same PHP and database versions you intend to run, then reactivate plugins in dependency order and record each result. A plugin that fails to activate, or activates but misbehaves on a ticket or asset form, is a decision point: upgrade it, replace it, or remove the feature. Ask the team who owns each plugin decision, and ask the vendor or maintainer to confirm compatibility in writing for the exact GLPI version. Keep the backup of glpi.key and glpicrypt.key with the copy, since encrypted plugin settings depend on them. Schedule the production cutover only after every plugin in the register has a recorded outcome.
Which changes affect plugins in GLPI 11 and 12
This table compares the GLPI changes that touch installed plugins, from the GLPI 11 suspension behavior to the GLPI 12.0.0 release items that alter screens and rights. Read each row as a question to answer before the upgrade: what the change does to a plugin, and what your team must check or do. The main takeaway is that a plugin can be suspended or broken without any error on the plugin itself, so compatibility checks belong in the upgrade plan.
| Change | Impact | Action needed |
|---|---|---|
| Plugin suspension after a new version is detected (GLPI 11.0 onward) | Plugins are suspended when GLPI detects a new version, so their features stop working until they are handled | Plan a window for reactivation, and confirm each plugin's status in the console after the update |
| Reactivation required after major updates | Suspended plugins stay off until an administrator reactivates them, which can surprise users who expect existing forms or screens | Check each plugin's GLPI 11 or 12 compatibility, then reactivate in a test copy before production |
| PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 for GLPI 11.0 | Older PHP or database versions block the upgrade, and plugins may use functions tied to a specific PHP version | Confirm the PHP and database versions on the test copy and check each plugin's supported PHP range |
| PHP 8.3 or later and MariaDB 10.11 or MySQL 8.0 in the current README | Requirements move forward, so a host that met GLPI 11.0 may not meet the current GLPI release | Compare your server versions with the current requirements before choosing a target release |
| Only MySQL and MariaDB are supported | Plugins or custom database work that assume PostgreSQL or other engines have no supported path | Confirm that custom plugin code and reports use MySQL or MariaDB syntax only |
| GLPI 12.0.0 rewritten knowledge base | Plugins that extend or restyle knowledge base screens may render differently or fail | Test knowledge base customizations and plugin hooks on the new interface |
| GLPI 12.0.0 session revocation and step-up authentication | Plugins that run administrative actions or custom login flows may hit new re-authentication prompts | Test plugin actions that change data or rights, and confirm that scheduled or API tasks still work |
| GLPI 12.0.0 group-managed OLAs and accessibility work | Plugins that touch SLA, OLA or form markup may show different fields or labels | Review plugin screens that depend on OLA data or custom markup, and re-check rights for those screens |
How to check plugin compatibility before the major update
This sequence builds a written inventory of every GLPI plugin, confirms each one's compatibility with the target version, and decides whether it stays, is replaced or is retired before anyone touches the production application files. The output is a signed-off list that tells the upgrade team exactly what to reactivate, migrate or remove.
Export the list of installed plugins
Start from the live GLPI instance, not from memory or old change records. Open the plugin management screen in the GLPI console as a super-administrator and export or copy every installed plugin with its listed version, state (active or inactive) and key. Run the same check against the database copy that will be used for rehearsal, because the two can differ. The step is done when the list matches the plugin entries in the database and every entry, including inactive ones, appears on the sheet.
Classify each plugin by origin
Mark every plugin as supported, community or custom. Supported plugins come from the publisher that maintains GLPI's official plugin line, community plugins are maintained by third parties, and custom plugins were written or modified by your own team or a contractor. Record the author, the source repository or package, and the person accountable for it. Custom plugins usually carry the most risk because no one outside your organization will confirm compatibility, so flag them now. The step is done when every row has an origin and an owner.
Confirm target version compatibility with each publisher
For each plugin, check the plugin's own documentation, release notes or repository for a statement about the target GLPI major version. Where the documentation is silent, ask the publisher in writing which GLPI versions the current release supports and whether a newer release is planned. Record the answer, the date you asked, and the source. Do not assume that a plugin working on the current version will work on the next one. The step is done when each plugin has one of three recorded outcomes: confirmed compatible, confirmed incompatible, or no answer yet.
Check whether features moved into core
Some plugin functions now exist in GLPI core, so the plugin may be redundant rather than incompatible. Compare each plugin's feature list against the GLPI 11 release documentation and the migration documentation for the target version, and note which functions are now native. Where a plugin's data has a documented migration path into core, add that path to the plan. Where a feature exists in core but behaves differently, record the difference for the business owner to review. The step is done when every plugin is tagged as still needed, covered by core, or partly covered by core.
Test installs on a copy of the instance
Restore a copy of the production database and files into a non-production environment running the target GLPI version and its required PHP and database versions. Reinstall each plugin that is still needed, attempt activation, and run the plugin's main workflows. Check the GLPI logs and the plugin's own error output after each attempt. If a plugin cannot be installed or activated, record the exact error. The step is done when each plugin has a test result tied to the target version, not to the current one.
Decide keep, replace, migrate or retire
For each plugin, make one decision with a named owner: keep it on the target version, replace it with a core feature, migrate its data before removing it, or retire it because nothing depends on it. Base the decision on the test result, the core comparison and the business need, and record any custom work the choice creates. Plugins that are still needed but unsupported on the target version become blocking items for the upgrade plan. The step is done when every plugin has a decision and every blocking item has an owner.
Sign off the compatibility register
Assemble the inventory, origin, compatibility evidence, core comparison, test results and decisions into one register that the technical owner and the business owner both review. Confirm that the register lists every plugin from the first export and that no row is left without an outcome. Keep the register with the backup plan for the upgrade, because it tells the team which plugins to reactivate after the major update and which to leave suspended. The step is done when both owners have approved the register in writing.
What suspension looks like and how reactivation works
GLPI suspends plugins when it detects a new core version, so that no plugin code runs against a core it has not been checked against. The suspension is a safety gate, not a fault: the platform stays up, but plugin hooks, menu entries and plugin-supplied behavior are held back until someone decides each plugin is safe to run. In practice, after you replace the application files and run php bin/console db:update, expect plugin features to be missing or inactive until you have reviewed them. Treat that state as the start of the work, not evidence that the upgrade failed. The GLPI update documentation states that plugins are suspended and must be reactivated after major updates, which is the rule your plan should be built around.
The console gives you the controls to manage this state. Alongside the plugin install, activate and deactivate commands, GLPI provides plugin:suspend_execution and plugin:resume_execution, which let you pause and restore plugin execution deliberately. Use the list of plugins and their status in your console as the starting inventory, then record for each plugin whether it was active before the upgrade, whether a newer release exists for the new version, and who owns the decision to resume it. Confirm the exact behavior of each command, including what it changes in the database and whether it applies to every plugin or a named one, in the GLPI command-line interface documentation for the version you are running, because command behavior has changed between releases.
Reactivation should happen one plugin at a time, on a copy of the production database, with a written check after each step: confirm the plugin loads, its pages render, its database tables match what the plugin expects, and the business workflow it supports completes. Keep the pre-upgrade backup and the glpi.key and glpicrypt.key files available throughout, since a failed plugin resume may need a rollback to the previous state. A plugin that fails or has no release for the new version should not be forced back on. Record it as a replace-or-retire decision with an owner and a date, because leaving a suspended plugin in place indefinitely hides a gap in functionality that users will eventually hit.
Reactivate, replace or retire: the three outcomes for each plugin
After an upgrade, every plugin on the inventory ends in one of a few states: it runs again, it is replaced by a core feature, or it is retired. The cards below set out each path, what it involves and what to verify before you commit to it, so the decision rests on evidence rather than on whether the plugin happened to load.
Reactivate a compatible plugin
A plugin that declares support for the target GLPI version, has a release built for it and passes your test copy can be reactivated. After a major update, GLPI suspends plugins until you reactivate them, so this is the normal path for active plugins. Check the plugin's release notes for the exact GLPI version it supports, then run the plugin's own functions on the test copy: forms, custom fields, rights and any scheduled tasks it registers. Reactivate only after those checks pass.
Replace with a core feature
Some plugin functions now live in the GLPI 11 core, so the plugin is redundant and should not be reactivated alongside its replacement. Forms and generic asset types are the main examples covered in the upgrade sibling topics. Map each plugin function to its core equivalent, list the data and rights it depended on, and confirm the core feature covers your workflows before you switch. Keep the old plugin disabled until the migrated data is verified.
Update a custom plugin
Plugins your organization wrote or commissioned are your responsibility after an upgrade, because no vendor will fix them for you. Assign an owner, confirm whether the code uses the GLPI hooks, classes and database schema that changed, and plan the change against the target version in a development copy. Keep the source under version control so each fix is traceable and can be rolled back with the rest of the instance.
Retire a plugin after migrating its data
When a plugin's data has been moved into core tables by a console migration, the plugin itself can be removed once the data is confirmed. Run the migration on the test copy, compare record counts, rights and linked objects against the source, and keep a database backup from before the migration. Only then deactivate and uninstall the plugin. Do not delete its files until you have a tested restore path.
Plugin without a maintained release
A plugin with no release for the target version, no recent commits or no published support channel is a risk to the upgrade, even if it still works on the old version. Ask the publisher or the community for written evidence of support for your target GLPI version, and check the release history against the GLPI releases. If no evidence exists, plan a replacement or a funded fork before the upgrade rather than discovering the gap after it.
Plugin that depends on removed APIs
Plugins that call interfaces GLPI has removed or changed will fail even when their code is otherwise sound. The XML-RPC API removed in GLPI 11 is one example, and the sibling upgrade topic covers it in detail. Search the plugin code and the integrations that call it for the endpoints, then decide whether the caller or the plugin must change. Record each dependency in the compatibility inventory so nothing is left unowned at cutover.
The upgrade sequence for plugins, with rollback points
This sequence moves a GLPI instance to a new major version with its plugins accounted for at every stage, so each plugin is either working, replaced or deliberately retired before users return. It also sets two rollback points where restoring from backup is the practical way back.
Back up the database, files and config directory
The administrator takes a full database dump, copies the GLPI application files and archives the config directory, including
glpi.keyandglpicrypt.key. The encryption keys matter because stored credentials and encrypted fields cannot be read without them, so a backup missing those files is incomplete. Confirm the backup by restoring it to a separate host or database and checking that GLPI starts and that a known ticket and asset are present. This is the first rollback point: if the restore check fails, stop and fix the backup before going further.Rehearse the upgrade on a copy
The team builds a copy of the production instance from the backup, on separate infrastructure with its own database, and runs the full upgrade there first. The copy shows which plugins the new version suspends, which fail on the target PHP and database versions, and how long the database update takes on your data. Record each finding in a list tied to the plugin name and version. Prerequisites for the target release should be confirmed with the GLPI installation documentation before the rehearsal starts. Done means the rehearsal finishes with a documented list of plugin outcomes and no unexplained errors.
Replace the application files
On the production host, the administrator puts the new GLPI application files in place while keeping the config directory and the encryption keys intact. Plugin directories are handled as a separate decision, so the team copies in only the plugin versions already confirmed as compatible in the rehearsal. Ownership and permissions on the files should match the previous release so the web server can read them. Done means the file tree matches the release package apart from the intentionally retained configuration and plugin files, and nothing has yet been run against the database.
Run the database update
The administrator runs
php bin/console db:updatefrom the GLPI root and reviews the output for schema changes and errors. The console is also the point where GLPI detects the new version and suspends plugins that have not been reactivated for it. This is the second rollback point: after this command, the database schema has changed and rolling back means restoring the database and files from the backup taken in the first step, not reversing the command. Done means the command completes without errors and the admin interface loads.Review the suspended plugins
The administrator lists plugins in the GLPI interface or console and compares each status with the rehearsal findings. Each plugin falls into one of three groups: confirmed compatible, needing an update or replacement, or no longer needed because its features now exist in the core. Plugins whose functions moved into the core should not be reactivated, since they can duplicate core behavior. Record the decision for every plugin, with an owner. Done means every suspended plugin has a recorded outcome.
Update or replace plugins in a test copy
For plugins that need a new version or a replacement, the team applies the change to the test copy first and checks that the plugin installs, activates and keeps its data. Where a plugin's data has been migrated into the core, the migration follows that plugin's own guidance and is run on the copy before production. The team confirms the console commands for suspending and resuming plugin execution are available in the release in use. Done means each changed plugin passes installation and a data check on the copy, and the production change list is final.
Reactivate plugins one at a time
On production, the administrator resumes or activates plugins individually rather than in one batch, following the order set in the rehearsal. After each plugin is reactivated, the admin checks the GLPI error log and confirms that the plugin's pages and forms load. A failure is isolated to one plugin, which can be deactivated again while the others keep running. Done means every plugin on the approved list is either active and checked or recorded as retired.
Run the functional checks
The team runs a written set of checks covering login, ticket creation and assignment, asset search, notifications, scheduled tasks and each reactivated plugin's main workflow, using test accounts that match real profiles. Results are compared with the expected behavior recorded during the rehearsal. The checks should also confirm that the upgraded instance is reachable through the intended web server configuration. Done means every check passes or has a documented fix, and the owner signs off that the instance is ready for users.
What makes plugin handling take longer
This table compares the factors that expand plugin work during a GLPI major update and the direction each one pushes the effort. Read each row as a question to answer for your own instance before you agree a scope. The main takeaway is that plugin count alone matters less than how deeply plugins and custom code depend on internals that change between versions.
| Driver | Effect on the work |
|---|---|
| Number of plugins, supported or custom | More plugins mean more compatibility checks and more reactivation steps. Custom plugins usually need a developer to review code, while supported plugins depend on the vendor's release for the new version. |
| Customizations that depend on plugin internals | Overrides, direct database queries and hooks tied to plugin tables break when the plugin changes. Each one adds a code review and a test case. |
| Plugins whose features moved into the core | Data must be migrated before or after the update, in a planned order. Plugins that were replaced by core features add migration runs, verification and retirement steps. |
| Database size and the length of the db:update run | Larger databases lengthen the update and the backup and restore windows. Plugin migrations on large tables can extend the run, so confirm timing on a copy of the production database. |
| Availability of plugin authors or internal developers | When the author or developer is unavailable, fixes for incompatible plugins wait, which can hold up the whole cutover. Confirm who will answer questions and approve fixes before the window is set. |
| Number of test scenarios by profile and entity | Each user profile and entity can see plugin features differently. More profiles and entities mean more scenarios to test for rights, visibility and workflows. |
| Integrations that call plugin endpoints | Connected systems that call plugin endpoints or plugin-specific API fields need retesting. Confirm each endpoint still exists and returns the same data shape after the update. |
Questions teams ask before handling GLPI plugins after an update
What does handling GLPI plugins after an update cost, and who pays for it?
Most of the cost is labor, and it is paid by whoever does the compatibility checks, test runs, fixes and cutover. If your own staff do it, the cost is their time and any vendor licenses they already hold. If a partner does it under a fixed-scope agreement, the quote follows from the written scope: how many plugins, how many of them need a newer release or a data migration, and how many test cycles are included. The GLPI Network subscription prices in the public materials are for GLPI Network hosting and support, not for plugin migration work, so they do not price this job. Ask for the cost of the plugin inventory and test phase separately from the cost of any rebuild, because only the second one varies much with the plugin set.
How long does it take to get GLPI plugins working after a major update?
The duration depends mainly on how many plugins are active, how many have a release for the new GLPI version, and whether any of them store data that must be moved. A plugin with a matching release and no schema change usually reactivates quickly after testing. A plugin that needs a replacement, a custom rebuild or a data migration takes longer, and the test cycles on a database copy add time before the production cutover. Ask for the duration of each phase: inventory, compatibility review, test copy, fixes, production run and post-cutover checks. No general duration applies, so ask for a timeline based on your own plugin list.
What does the team need to provide before plugin work starts?
The work moves faster when your team supplies four things before the first test run:
- A list of every installed plugin, its version and the owner who uses it
- A recent copy of the database, the files and the config directory, including
glpi.keyandglpicrypt.key - A test environment with the same PHP and database versions as the target
- Named people who can confirm business behavior and sign off on each plugin
Access to the server, the web host and the plugin vendor or source repositories also matters, because a plugin that needs a fix may require a code change and a review by someone who knows its behavior.
Can our own team handle GLPI plugins after a major update?
Yes, if your team has Linux, PHP and database skills and time to test. The GLPI console provides commands to install, activate and deactivate plugins, along with plugin:suspend_execution and plugin:resume_execution, so a competent administrator can reactivate a plugin that has a matching release. The harder part is judging whether a plugin behaves correctly after the change, and deciding whether to replace it. Teams that run GLPI with a small staff often find the test cycles and the business sign-off take the most time. Compare your staff's available hours and skills against the plugin list before deciding.
What happens if a plugin has no release for the new GLPI version?
The plugin stays suspended after the update until you decide its future. Your options are to find a maintained fork or newer release, to rebuild the function with core features or another plugin, or to retire it and accept the loss of that feature. Before choosing, check the plugin's release history, its open issues and whether its maintainer still responds. A plugin without a release may still run, but it carries risk for security and future upgrades. Record the decision and the owner for each unsupported plugin before the production cutover.
How do we avoid losing data when a plugin feature moved into GLPI core?
Do not deactivate or remove the old plugin until its data has been moved and checked. Some features that were plugin-only now live in the core, and GLPI provides console migration commands for several of them. Run each migration on a copy of the database first, compare record counts and sample records, and check rights, capacities and integrations that used the old objects. Keep the full backup from before the update until the business owner signs off. Ask your partner or vendor which migration commands apply to your plugins and in what order they must run.
What to confirm with the vendor and in your environment
Treat each plugin's status as an open question until you have confirmed it. Do not assume a plugin works on GLPI 11 or 12 because it worked on GLPI 10. For every plugin in use, confirm with its publisher whether it declares support for your target GLPI version, and whether that declaration covers the exact release you plan to run. Check whether the plugin's features now exist in the GLPI core, since some functions that previously needed a plugin have moved into the core, and a plugin that duplicates core behavior may need to be retired instead of reactivated. Ask for the data migration command the publisher expects, and confirm whether it runs in the plugin's own tooling or through the GLPI console. Also confirm the support terms for community plugins, because many have no service commitment, no fixed release cycle and no guaranteed response when a new GLPI version breaks them. Record the answers per plugin in your change plan so that the owner, the decision and the source of each answer are visible.
Confirm the platform baseline for the release you choose before you schedule any plugin work. Check the PHP and database versions required by the exact GLPI version in your plan, since the requirements for GLPI 11 and 12 differ from those for GLPI 10 and the current project README may not match the version you install. Confirm which database engines the release supports, and whether your existing database character set and storage engine need conversion first. Ask your team and your plugin publishers to name the versions they have tested against. The GLPI update documentation is the next read: it covers the backup steps, the handling of the glpi.key and glpicrypt.key files, and the php bin/console db:update step where plugins are suspended. Use it to build your rehearsal runbook, and repeat the plugin checks on a copy of your production database before any change window.
How DeployOpen scopes and delivers plugin handling in a GLPI upgrade
DeployOpen approaches plugin handling in a GLPI upgrade as a written, fixed-scope piece of work inside infrastructure you control. We start with an inventory of what is installed and what each plugin does for your service desk, then test reactivation or replacement on a copy of your instance before anything changes in production.
How we scope
- We inventory every installed plugin, its version, its owner and the workflows it supports in your GLPI instance.
- We check each plugin's compatibility with the target GLPI version and record which ones must be reactivated, replaced or retired.
- The written scope names the plugins covered, the test copy, the acceptance checks and the deliverables before work starts.
How we build
- We run the upgrade on a copy of the production database and files, including the glpi.key and glpicrypt.key files.
- We reactivate suspended plugins in a controlled order with the console commands, then review logs for errors after each step.
- Where a plugin's features have moved into the GLPI core, we plan the data migration and test it against your real records.
How we hand over
- You receive a plugin register listing each plugin's status, version, decision and the reason behind it.
- You receive the runbook for the production cutover, including the rollback steps and the backups taken before each change.
- Your team receives a walkthrough of the checks performed, so they can repeat them on the next major update.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial plugin work is complete.
- Retainer support can cover re-checking plugin compatibility when new GLPI releases or plugin versions are published.
- Ask for the support scope, response expectations and change process in writing before you sign any retainer agreement.
