The `icinga-php-legacy` library is the successor to the standalone
`icingaweb2-module-incubator` module. Modules such as director and
vspheredb that still declare `incubator` as a dependency should load
without a separate incubator installation once `icinga-php-legacy` is
present.
`Module::getRequiredLibraries` now maps an `incubator` module
requirement to an `icinga-php-legacy` library requirement when that
library is available, and `getRequiredModules` drops `incubator` from
the list so the dependency check does not fail. `Manager::loadModule`
skips calling `register()` for the incubator module under the same
condition, folding that guard into the existing `ipl`/`reactbundle`
exclusion to avoid a double-registration.
https://github.com/Icinga/icinga-php-legacy replaces
https://github.com/Icinga/icingaweb2-module-incubator.
W/o this the login page, if on PHP 8.2, says:
Deprecated: Creation of dynamic property Icinga\Application\Modules\Module::$configdir is deprecated in /usr/share/icingaweb2/library/Icinga/Application/Modules/Module.php on line 264
This breaks modules (if any) which use the property and not the getter.
This is the successor of `Depends` and allows to
define dependencies for libraries and modules:
`Requires: <lib-name>[ (<ver>)][, <lib-name>[ (<ver>)]] ...`
or
```
Requires:
Libraries: <name>[ (<ver>)][, <name>[ (<ver>)]] ...
Modules: <name>[ (<ver>)][, <name>[ (<ver>)]] ...
```
Because assets are not registered in the CLI context,
CLI actions cannot access the full style sheet.
This is necessary for Icinga Reporting though in order to send PDF reports.
This reverts commit f1a1f41192.
It makes absolutely sense to remove depcreated code, but this removal introduces too many problems while not being really necessary.
Some of our modules and modules written by others still rely on the deprecated code. A upgrade of Icinga Web 2 would break many running systems out there.
Before removing this code we should upgrade our modules and notify the authors of other modules about the deprecation.
Further, we should maintain something like a deprecation info file because nobody reads @deprecated tags.
All of the above will not protect us from systems where modules aren't up to date. We also have to implement a mechanism where it is still possible to disable faulty modules.
This allows now totally different values for an item's name and label
and fixes the bug that permissions declared in the configuration.php
were not evaluated for menu items.
fixes#11431
