System Info Laravel Package

Technical Evaluation

Architecture fit. ibexa/system-info is not a general-purpose PHP utility — it is a Symfony bundle that ships inside the Ibexa DXP bundle set and registers a "System Information" admin panel plus collectors that report PHP version, runtime environment, installed packages, service-life/version data, and repository configuration. It has no meaning outside an Ibexa DXP kernel: the release notes show it binding directly to Ibexa core internals (repository configuration provider contracts, core schema table names, content type version columns, TwigComponentBundle). For a Laravel or standalone Symfony codebase, architecture fit is effectively zero; the only transferable asset is the pattern (a read-only diagnostics panel surfaced to admins and support).

Integration feasibility. Feasible only in one scenario: you already operate Ibexa DXP. In that case the bundle is almost certainly installed transitively via the DXP metapackage, and "integration" is verification plus access control, not development. Signals confirm this: 3 stars and 0 dependents indicate nobody adopts it directly — it is a bundled component, not a destination package. The dual release train (v4.6.x for Ibexa 4.6, v5.0.x for Ibexa 5) means the integration decision is really an Ibexa-version decision already made elsewhere.

Technical risk.

• Licensing ambiguity. NOASSERTION in metadata reflects a dual-license model: Ibexa BUL (requires a valid DXP subscription) or GPL v2. Legal must confirm which applies to your deployment and whether redistribution or modification triggers GPL obligations. This is the single highest-impact unknown.
• Hard coupling to core. Historical fixes — version detection breaking after a package rename (IBX-5813), table-name alignment to new core schema, content-type column rename — show the collectors are fragile against Ibexa core changes. Expect breakage at each DXP major upgrade.
• Information disclosure. The panel exposes stack, versions, and configuration detail by design. Misconfigured access policy turns a support aid into reconnaissance material.
• Low external scrutiny. 3 stars / 0 dependents means minimal outside review; defect discovery depends on Ibexa's own QA and support tickets.
• Version skew. v5 requires PHP 8.3+ and Symfony 6/7; v4.6.x tracks the older line. Mixed-version fleets need per-environment validation.

Key questions.

1. Do we actually run Ibexa DXP, on which major (4.6 vs 5.0), and is this bundle already present?
2. Do we hold an Ibexa BUL subscription, or are we relying on GPL v2 — and has legal ruled on which?
3. Who is permitted to view the System Information tab, and is that enforced by policy rather than assumption?
4. Do we need custom collectors (e.g., our own infrastructure metadata), or is stock output sufficient?
5. Is our support workflow able to consume the output, or do we need an export/redaction step before sharing externally?

Integration Approach

Stack fit. Only viable on Ibexa DXP (Symfony-based). If the target platform is Laravel, do not adopt — there is no port path, and the effort to reimplement is small but the value is modest. Recommendation: treat as a platform capability to confirm and govern, not a package to integrate.

Migration path. None required in the normal case. The realistic work is: confirm presence via composer show ibexa/system-info, confirm bundle registration in the kernel, confirm the admin route and its permission policy, and confirm the version branch matches the DXP major. If the bundle is absent from a custom build, add the pinned version matching the DXP line rather than "latest."

Compatibility.

Sequencing.

1. Legal: resolve BUL vs GPL position before any internal redistribution or fork.
2. Platform: inventory Ibexa instances, majors, and whether the bundle is already deployed.
3. Security: define viewer roles for the System Information tab; verify enforcement in a non-production environment.
4. Validation: capture baseline output on staging, compare against production after deploy; store a redacted snapshot in the support runbook.
5. Operations: add "attach system-info snapshot" to the standard escalation template.

Operational Impact

Maintenance. Low effort, low influence. Release cadence is vendor-driven and mostly cosmetic — the provided history shows many consecutive releases with "no significant changes," plus occasional PHP 8/Symfony upgrades and copy/icon tweaks. You absorb changes with DXP upgrades rather than scheduling them independently. Budget verification time per DXP upgrade; budget nothing for feature development.

Support. Defect resolution routes through Ibexa's issue tracker and support portal, not community channels. That is acceptable with a subscription and a liability without one — an important consideration given the GPL-only path offers no vendor obligation. Internal first-line support will need a short guide on reading the panel.

Scaling. Negligible runtime footprint: an admin-only page and on-demand collectors. Watch two things at scale: collector queries against large repositories or content catalogs, and any temptation to poll the page from monitoring — it is a diagnostic view, not a metrics endpoint. If you need continuous environment telemetry, this is the wrong tool.

Failure modes.

• Panel renders but shows stale/incorrect version or service-life data after a core upgrade (documented precedent).
• Collector exceptions after schema or package renames, surfacing as an error page in admin.
• Version-detection drift when Ibexa packages are renamed or split.
• Over-broad access policy exposing environment details to non-admin roles.
• Silent divergence between staging and production output undermining its use as a comparison baseline.

Ramp-up. Practically zero for an Ibexa administrator — it is a tab in the existing admin UI. The real ramp-up is interpretive: support engineers need Ibexa-specific context to act on what they see (which versions are supported, what "service life" means, which configuration deltas matter). Estimate half a day of enablement plus a one-page runbook; do not staff a dedicated owner. Given the 26.9 composite score, 3 stars, and 0 dependents, position this as a low-investment operational hygiene item inside an existing Ibexa estate, and explicitly out of scope if the estate is Laravel-based.