Streamline Logging

1 Initial Problem

Logging as a component is due a bit of spring cleaning. In particular, It has accumulated a few small features that should be removed: the option "Log Memory Usage" hasn't worked for a number of releases, "Browser Console Log" is a worrying potential point of failure from a security standpoint, and "Caching" doesn't seem to be used very widely.

What makes this clean up particularly necessary now is the Component revision project: Logging is a dependency of many of the components in ILIAS, so any dependency of Logging makes the new bootstrapping mechanism more complicated. The Logging component should thus be kept as lean as possible.

2 Conceptual Summary

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

All the settings on the subtab 'Logging Settings' of the Logging administration will be removed, so the whole subtab will be removed with them.

Because there will be no configurable log level for "Root" anymore, that row will be removed from the "Components" table.

3.3 New User Interface Concepts

No new UI.

3.4 Accessibility Implications

No accessibility implications.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

As part of this streamlining, the Logging component will be refactored, with the explicit aim of bringing Logging in line with the component revision: dependency management will be cleaned up, and lazy initialization mechanisms will be implemented where appropriate. Logging needs to work with the new bootstrapping mechanism without much friction.

Further, the Logger interface will be made compliant with PSR-3.

Necessary changes to the `ilias.ini.php` of pre-existing ILIAS installations will be made via the setup. "path" will be prepended to "file" and then removed. If no "level" is set, the field will be inserted with the corresponding value from the `settings` database table.

We will try to replace the existing usages of the root logger via a PR. If there is any usage that can't be clearly assigned to a single component, we will raise the issue with the JF.

4.3 Privacy

No personal data is processed.

4.4 Security

Stripping down the feature set of Logging will reduce the surface area of the component, which is helpful for security in general. In particular, abandoning browser logging will remove a potential point of failure.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Schmitz, Tim [tschmitz]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

Jansen, Michael [mjansen] 27 JUL 2026: The proposed streamlining of Logging is understandable, especially since the component is a bootstrap dependency for many other components. A concrete question regarding the Component Revision: If you are adapting Logging to the new component integration mechanisms anyway, have you considered also allowing the contribution of formatters and handlers through exactly those mechanisms? This way, handlers such as the browser-console handler or the FingersCrossedhandler (currently labeled “Caching”), and similar ones would no longer be hardwired into Logging itself (which we do in customer branches or plugins by utilizing the reflection API), but could be contributed by suitable components. Logging would stay lean and bootstrap-capable, and optional handlers would only be loaded when actually needed. Such a contribution mechanism could also open the door for enterprise logging setups, for example integrating ILIAS with Graylog via the GELF log format through a custom handler, or connecting to error-tracking systems (of course this is also related to ErrorHandling, but even domain-specific errors being already logged could be pushed to such systems) such as Sentry or GlitchTip.

Furthermore: If we agree to remove the root logger, we need an alternative for ILIAS plugins (as long as they are still supported) and other third-party components. As far as I can see, such components cannot yet define their own log component via the existing <logging /> mechanism. Without a supported way to register a configurable log component, the root logger effectively remains the only practical fallback for many plugins. How should these consumers obtain and configure a logger once root is gone?

6 Implementation

Feature has been implemented by Schmitz, Tim [tschmitz]

6.1 Description and Screenshots

Implemented as described above, with the following exceptions:

The implementation of the changes related to this feature in outher ILIAS components will be completed with the PR 11859, see there for details. Most notably, this will replace almost all usages of the root logger (with its configurable log level already removed). The exception is the logger exposed through an ancient global `ilLog` \ `log`. This is still used by a handful of components, most crucially Init\ErrorHandling, but tracking down all usages exactly is tricky. That logger identifies itself now as legacy_root in the log. It does not have a configurable log level, and always uses the default log level.

A mechanism for contributing handlers and formatters to the loggers in ILIAS, see again Michaels comment, will follow at a later date.

6.2 Test Cases

The following testcases have been removed from Testrail or modified.

6.3 Privacy

no change required

6.4 Approval

Approval not required.