The extension installer returned as soon as an add-on was installed, in
whatever version. A new pin in meta/addons/ therefore reached a fresh wiki
only, and an existing wiki kept the version it was first deployed with.
The installer now skips an add-on only when the installed version equals
the pin. Otherwise it calls install(id, version, namespace), which the
Extension Manager resolves as an upgrade, and it reports an error when the
add-on is not on the pin afterwards.
The check that follows the installer compared presence only. It takes the
pin as well, so a deploy fails when an add-on is installed in another
version.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Added 'plugins' section in config/main.yml to declare enabled extensions in a structured way
- Introduced new static file 'files/extension_installer_b64.groovy' that decodes Base64 JSON of requested plugins
- Simplified 04_extensions.yml: now builds installer code from static file and removed hardcoded OIDC/LDAP checks
- Dropped redundant XWIKI_EXT_* variables in vars/main.yml
- Added XWIKI_PLUGINS fact to collect enabled plugin items from config/main.yml
This refactor makes extension installation more generic, easier to unit test, and extendable beyond OIDC/LDAP.
See: https://chatgpt.com/share/68ca25e3-cbc4-800f-a45e-2b152369811a
kevinveenbirkenbachandClaude Opus 5.5