Matomo Tag Manager for GLPI: open-source plugin, architecture and install

We’ve been building GLPI plugins for our own ITSM deployments for a while. The first one we’re opening up is Matomo Tag Manager: it’s now published on GitHub under a free licence. Here’s why, how it’s built, and how to install it.

Why open source

A plugin that injects a tracking container into every page only earns trust if you can read it. That’s the whole point of publishing this one openly:

• transparency on what runs in your users’ browsers — no obfuscated analytics, no hidden calls;
• the freedom to fork, pin or strip the loader to fit your privacy policy;
• community review on a security-sensitive feature, and no proprietary lock-in on your ITSM.

Written to GLPI 10/11 best practices, with privacy and a minimal footprint as first principles.

The need

We want to measure GLPI usage with a privacy-respecting, self-hostable solution (Matomo), without:

• editing core templates (which break on every upgrade);
• adding yet another database table to maintain;
• exposing new configuration surface beyond what GLPI already protects.

The plugin boils down to one idea: one container URL, pasted once, loaded everywhere.

How it works

On every request, the plugin hooks into GLPI’s native header hook ($PLUGIN_HOOKS) and outputs a <script> tag pointing at a tiny static loader (public/js/mtm-loader.js). That loader in turn loads your Matomo container URL. Loading is asynchronous — no perceptible overhead. Everything is configured from the admin panel; FR/EN interface, compatible with GLPI 10.x and 11.x.

The container is injected on every page — authenticated screens and the login screen — so you can follow the full journey, starting at login.

The container URL is read from GLPI’s core configuration store:

Config::getConfigurationValues('plugin:matomo', ['container_url']);

No plugin table is created, no per-asset data is stored. The setting lives in the plugin:matomo configuration context, and that’s it.

Security

A plugin that injects JavaScript into every page — login included — has to be airtight. Our guardrails:

• the container URL is validated: it must start with https:// before it’s saved;
• output is escaped (htmlspecialchars, ENT_QUOTES) when rendered into the page;
• the configuration page is gated by the core config: UPDATE right (typically the super-admin profile) — the same right that protects GLPI’s general setup;
• the plugin is csrf_compliant: the form posts through GLPI 11’s CSRF-protected controller;
• no custom right is registered, and the plugin writes only to GLPI’s configuration store — it touches no core or third-party tables.

Requirements

Installation

Grab the latest release archive (or install it straight from git with our Git Plugin Installer plugin), then:

# extract into plugins/ so the path is plugins/matomo/
sudo -u apache php bin/console plugin:install matomo
sudo -u apache php bin/console plugin:activate matomo
sudo -u apache php bin/console cache:clear

Getting started

1. Setup → Matomo Tag Manager.
2. Paste your Matomo Container URL (e.g. https://stats.example.com/js/container_XXXXXXXX.js).
3. Save — the container is injected on the next page load, tracking starts immediately.

Why so minimal

The plugin does one thing and does it well. No table, no custom right, no patched template: less surface, less breakage on upgrades, and a review that takes minutes. That’s our line across the whole GLPI ecosystem we publish.

Stable release 1.0.0, licensed GPL v2.0-or-later.

→ Code, releases and issues: https://github.com/FathiBenNasr/glpi-matomo

What’s next

More plugins from our deployments are on the roadmap and will be published as they stabilise.

Running GLPI and need a custom plugin, managed operations or hardening? See our GLPI ITSM & plugin services or let’s talk. And follow us on GitHub for the next releases.