System Info Laravel Package

Getting Started

Before anything else: this is not a Laravel package. ibexa/system-info is a Symfony bundle that ships as part of the Ibexa DXP metapackage — the equivalent of a first-party vendor package that's already in your app when you install Ibexa. If you're a Laravel dev dropping into an Ibexa codebase, the mental mapping is:

Install / confirm presence

composer show ibexa/system-info        # usually pulled in by ibexa/dxp
# standalone (rare):
composer require ibexa/system-info

Then ensure the bundle is enabled in config/bundles.php (Ibexa installs register it automatically) and clear the cache:

php bin/console cache:clear

Where to look first

1. vendor/ibexa/system-info/ — skim DependencyInjection/, Resources/config/ (services + routing), and the directory holding the collectors (look for a SystemInfoCollector class; the 5.0 changelog explicitly mentions SystemInfoCollector::collect being moved out of the constructor, so that's the core entry point).
2. Resources/views/ — this is what actually renders the admin page.
3. The admin UI itself.

First real use case: log into the Ibexa admin, open the System Information tab (under Admin), and read the report — PHP/Symfony version, database, package versions, service-life data, and environment details. That page exists to be screenshotted into a support ticket. If a user reports "it's broken in production," this is step one before you touch a debugger.

Implementation Patterns

1. Read it as an operator, not a developer (the 80% case). The bundle's primary "API" is the admin tab. Your day-to-day workflow is: reproduce the issue in staging → open System Information in both staging and prod → diff the environments (PHP version, DB driver, package versions, service life warnings). Treat it as a diagnostic artifact generator, not a library you build features on.

2. Pull the report programmatically when you need it in a script or support bundle. Inject the collector service and call collect() explicitly rather than relying on construction-time collection — that behavioural change landed deliberately in 5.0 (EZP-32460). A typical pattern is a small console command that dumps the collected array to JSON so you can archive it per deployment or attach it to an incident ticket.

3. Add your own data to the report. The extension point is a collector: write a class following the same shape as the bundled collectors, expose it as a service, and register it so the page picks it up. This is how you'd surface things Ibexa doesn't know about — your queue worker status, a custom cache backend, a feature-flag summary. Grep the existing collectors for the interface/tag name rather than guessing; the bundle is small enough to read end to end in ten minutes.

4. Override the presentation through theme inheritance. Templates are Twig and the UI is built on Twig components (TwigComponentBundle was added to the test kernel in 5.0.10, and 5.0.0 refactored components for the newer twig-components package). Never edit vendor/. Copy the template into your project's admin theme and override — that survives composer update.

5. Wire it into ops tooling. Run the report in a post-deploy smoke check and compare against the previous deploy's JSON. It's a cheap way to catch "someone downgraded PHP" or "the wrong Ibexa package got resolved" before users do. Pair with composer audit and composer show for the dependency picture.

6. Use it as a support-handoff format. Because the bundle exists specifically for support engineers, structure your bug reports around it: environment section verbatim, then the failing behaviour. It saves a round-trip with Ibexa support.

Gotchas and Tips

• Licensing is the big one. Dual-licensed under Ibexa BUL or GPL v2, and the package metadata reports NOASSERTION. If you don't have a valid Ibexa DXP subscription, the BUL path doesn't apply to you. Don't copy collector code into a non-Ibexa commercial Laravel project without reading LICENSE-bul — GPLv2 has copyleft implications your legal team will care about.
• Version detection is historically fragile. Multiple releases fixed version-detection logic after package renames (ibexa/content → ibexa/headless, IBX-5813). If the "installed version" in the report looks wrong, check the raw composer.lock before filing a bug — the collector may be looking for an old package name.
• Collection touches the repository and DB. Several fields come from the content repository (schema/table-name changes were tracked in IBX-9940/IBX-9941, e.g. the content type version column renamed to status). On large installs don't call collect() on every request or in a hot path — do it on demand from the admin page or a console command.
• Caching bites during development. Template and DI changes need cache:clear; translation keys live in a jms_translation setup (domain names were renamed in IBX-6415), so missing strings usually mean a stale cache rather than a missing key.
• Platform floor is high. PHP 8.3+ and Symfony 6/7 from 5.0 onward (IBX-8119, IBX-8470, IBX-8471). This will not install on a Laravel 10 app's PHP 8.1 stack, and there's no Laravel service provider — attempting to require it outside Ibexa gives you a bundle nothing will register.
• Access is permission-gated. The System Information tab is an admin-UI module; if a user says "I can't see it," check their role/policy assignments before debugging the bundle.
• Debugging entry points: php bin/console debug:container | grep -i system and php bin/console debug:router | grep -i system will locate the service IDs and route names fast. Logs land in the standard Symfony log directory.
• Configuration surface is thin. There's very little to tune in Configuration.php — if you find yourself wanting a config knob, you almost certainly want a custom collector or a theme override instead.
• Maintenance cadence is quiet. Many releases are "No significant changes" — pinning to a patch range and updating with the rest of Ibexa DXP is safer than tracking this package individually.