One codebase for GLPI 11 and 12: what I watch out for

Every Sayru-Yön plugin runs on GLPI 11 and 12 installations from the same zip. The reason I chose this is simple: customers are on different versions at the same time, and maintaining two branches means twice the bugs. Below are the points that cost me the most time while making that decision work.

Typed properties

GLPI 12 gave some class properties type declarations. Where you would write public $dohistory = true; out of habit on 11, version 12 throws a fatal error because it clashes with public bool $dohistory in the parent class. The fix is to declare the property with exactly the same type as the parent; 11 does not mind.

// works on both 11 and 12
public bool $dohistory = true;
public static $rightname = 'plugin_example';

Front pages and CSRF

Taking the form action from PHP_SELF breaks silently on 11; write the address yourself. Do not call the CSRF check by hand either: the core already does it, and a second call consumes the token.

A small but measurable speed gain

If the plugin's locales folder is empty, every __() call costs about 0.16 ms; on a page with hundreds of calls you can feel it. Shipping an empty en_GB.mo file is enough.

The test installation

I keep a separate test installation for each version, and a package is opened there first, not at the customer. Before a version bump, a load check (loadcheck) loads every class once and catches type errors.

• Do not define the version constant before the core boots; on a shared installation it deactivates the plugin.
• Avoid MariaDB-only syntax in install SQL; the customer may be on MySQL 8.
• Keep updates additive: never rewrite an existing report, rule or right.