Standard Design Laravel Package

Technical Evaluation

What this package actually is. ibexa/standard-design is not a Laravel package. It is a first-party Symfony bundle shipped as part of Ibexa DXP (formerly eZ Platform), containing the default design/theme — Twig templates, asset mappings, and design configuration consumed by ezplatform-design-engine. It has no service provider, no Laravel auto-discovery, no Eloquent, no Artisan surface. Any evaluation framed as "Laravel/PHP package adoption" should be reframed: the real decision is whether to adopt Ibexa DXP as the content platform. This bundle is an artifact of that decision, not an independent one.

Architecture fit. Fit is binary and high-friction. If the target platform is Ibexa DXP, this bundle is essentially mandatory scaffolding — it is the reference theme the design engine resolves against, and forking it is the intended customization path (override templates/assets in a child design, do not edit vendor). If the target platform is Laravel, Symfony, or a headless CMS/API stack, the fit is zero: there is no meaningful way to wire this into a Laravel application, and the only thing transferable is static CSS/Twig markup, which you would copy rather than depend on.

Integration feasibility. Low as a standalone integration, high as a platform-embedded component. The README is explicit: "To use this package, install Ibexa DXP." There is no documented standalone install path, no configuration reference, and no API surface beyond the design-engine contract. Practical feasibility therefore depends entirely on the host DXP's install profile and version.

Technical risk.

• Licensing (highest risk). NOASSERTION reflects a genuine dual-license: Ibexa Business Use License (BUL) v2.4+ or GPL v2. The BUL is granted only with a valid Ibexa DXP subscription and is not an OSI open-source license; GPL v2 is copyleft. This is a commercial-use gate, not a formality. Legal review is a prerequisite, not a follow-up. Note also the "or later versions" clause on BUL — terms can shift under you.
• Ecosystem signal. 3 stars and 0 dependents is expected for a vendor-split bundle and should not be read as abandonment, but it does mean near-zero community troubleshooting corpus. Support is vendor-contract-only.
• Version coupling. The design bundle is tightly version-locked to the DXP release and to ezplatform-design-engine. Minor DXP upgrades can break template overrides.
• Release metadata anomaly. Last release dated 2026-08-20 is a future date relative to normal release cadence — likely a metadata/registry artifact or a scheduled tag. Do not treat it as evidence of active maintenance until verified against the DXP changelog.
• Maturity scope. "readme, releases" only — no CI badge, no test suite, no contribution guide. Normal for a theme bundle, but it means you own all regression testing on overrides.

Key questions for the vendor / team.

1. Which Ibexa DXP edition and version tier are we on, and does our subscription cover this bundle's BUL terms?
2. Is the intended customization model child-design override (documented upstream), and where is that documented?
3. What is the DXP upgrade cadence, and what is the tested override-compatibility window across minor versions?
4. Confirm the 2026-08-20 release date and the actual current supported branch.
5. Is a headless/decoupled front end viable, so this theme becomes optional rather than load-bearing?

Integration Approach

Stack fit. Assume a Symfony/Ibexa stack. This bundle sits in the view layer: it registers a design, provides Twig template overrides, and ships front-end assets. It should never be referenced by application or domain code. Treat it as a vendor dependency pinned by the DXP metapackage, and keep all project-specific theming in a separate custom design bundle that declares this one as a parent.

Migration path. If coming from a legacy eZ Platform or custom theme:

1. Stand up a clean Ibexa DXP install at the target version, with this bundle at its vendor-resolved version — do not hand-pin it initially.
2. Inventory the existing theme's templates, assets, and content-view configuration against the standard design to identify true deltas versus incidental differences. Expect the delta to be much smaller than it looks; most customization is content-view and template-block override.
3. Create a custom design bundle that depends on ibexa/standard-design, overriding only the identified deltas.
4. Port assets behind a build step (Vite/Webpack) rather than committing compiled output, so upgrades to vendor assets remain distinguishable from ours.
5. Cut over content views and siteaccess design configuration last, behind a feature flag where the design engine permits.

If migrating away from Ibexa, skip all of the above; this package has no portable value beyond its static markup, which is a copy-paste extraction, not an integration.

Compatibility. The hard constraints are (a) DXP major.minor version, (b) ezplatform-design-engine version, (c) PHP version supported by that DXP release, (d) Twig major version. Lock these in a compatibility matrix in the repo and gate CI on it. Do not assume semantic versioning protects you — vendor bundles in a monorepo split frequently ship breaking template changes in patch releases.

Sequencing.

1. Legal sign-off on BUL/GPL election and subscription status. Blocking.
2. Confirm DXP version target and vendor support window.
3. Clean install + smoke test of the stock design.
4. Build custom child design; port deltas.
5. Automated visual regression baseline (see below).
6. Cutover, then establish the upgrade rehearsal cadence.

Rough effort for a mid-size team: 1–2 weeks for a stock install and evaluation, 3–6 weeks for a substantive theme migration with content-view rework, longer if the existing theme carries years of ad-hoc overrides.

Operational Impact

Maintenance. Low ongoing code maintenance — you should not be modifying this bundle. The real maintenance burden is upgrade rehearsal: every DXP upgrade requires re-validating template overrides against the new standard design. Budget a recurring per-upgrade task, not a one-off. Because the package has no test suite of its own, all regression coverage for overrides is yours.

Support. Vendor-contract support only. With 3 stars and 0 dependents, there is no community fallback: no Stack Overflow corpus, no third-party tutorials for edge cases, no ecosystem of plugins. Escalation runs through the Ibexa subscription. This is acceptable for a licensed commercial platform and unacceptable if the team assumed "open source means self-serve."

Scaling. The bundle itself is static assets and templates — it does not scale or fail as a unit. Scaling behavior is entirely inherited from the DXP (cache tiers, persistence, search). The one lever this package gives you is front-end performance: asset bundling, critical CSS, and image strategies live in the design layer and are worth tuning, since they are the user-visible bottleneck. If traffic growth is a concern, the more important architectural question is whether to go headless and take this theme out of the request path.

Failure modes.

• Silent template override drift after a DXP upgrade: vendor template structure changes, your override no longer matches its parent block, and the page renders wrong or falls back without an error. This is the dominant failure mode. Mitigate with visual regression snapshot tests on key content views per siteaccess.
• Design resolution misconfiguration: wrong design declared in siteaccess config yields unstyled or default-themed output. Catch in smoke tests.
• License lapse: BUL is granted by holding a subscription. If the subscription lapses, your right to use under BUL is gone and you fall back to GPL v2 — a materially different posture, particularly if you distribute. Track renewal as an operational dependency, not a procurement detail.
• Asset pipeline divergence: vendor assets and project assets colliding on the same paths after an upgrade. Enforce namespace separation.
• Version skew in multi-site/multi-app estates where different apps target different DXP versions.

Ramp-up. For a Symfony developer, 1–2 weeks to be productive in the design layer, plus 1 week specifically on the design engine's resolution and override semantics — that is the non-obvious part and the most common source of wasted effort. For a Laravel-only team, add 3–4 weeks of Symfony/Twig/Ibexa content-model ramp-up, and seriously reconsider whether this platform is the right choice at all.

TPM recommendation. Do not evaluate this package in isolation; it has no independent adoption decision. Gate the decision on two things: (1) a confirmed Ibexa DXP subscription with legal sign-off on BUL terms, and (2) a validated upgrade path that keeps your customizations in a child design and out of vendor code. The package scores low on ecosystem opportunity (60.58) and low on community signal, but that is the expected profile of a vendor-internal bundle — the score reflects the platform bet, not this artifact's quality. The genuine risks are licensing posture, version coupling, and the absence of a community safety net, in that order.