Admin Ui Laravel Package

Product Decisions This Supports

• Back-office / editorial UX roadmap. This bundle is the Ibexa DXP Back Office interface — content tree, content editing, translations, sections, trash, notifications, permissions screens. Any roadmap item framed as "improve the authoring experience" lands here, not in a greenfield UI project.
• Build vs. buy on admin surface. The bundle is the strongest argument for buy: it is a maintained, vendor-owned UI layer (release notes show steady defect and polish work across 4.6 and 5.0 lines — collapse header clipping, image picker edge cases, filter button spacing, creator clear button, datepicker localization). Rebuilding that surface in-house is a multi-quarter commitment with a long tail of micro-fixes.
• Localization strategy. Recent work is heavily translation-centric: translation selector extension points, passing target language when creating a draft during translation, fixing datepicker locale, anchor links with translations enabled, dropdown lazy-init for dynamically populated translation selects. If multi-language authoring is a differentiator, this is the leverage point.
• Content modeling and field-type UX. BaseFieldValidator gives a documented JS pattern for client-side validation per field type; the richtext extensibility point and matrix column identifier validation show the field system is extensible rather than closed. Supports decisions like "add a custom field type" vs. "constrain authors to existing types."
• Commerce-adjacent content. Product collection/embed blocks, "customers also viewed" menus, product tours, image picker fixes — relevant if the roadmap includes merchandising content inside the editorial experience rather than a separate PIM storefront admin.
• Upgrade and support-window planning. Parallel 4.6.x and 5.0.x release branches (with Symfony 7.4 LTS bump on 5.0) give a concrete decision: stay on 4.6 for stability, or move to 5.0 to stay on a supported Symfony LTS. Treat release cadence as a planning input, not a feature.
• Extend vs. fork. Documented extension points (field validator subclassing, richtext config, translation selector, table action dropdowns) mean most customization should be additive. Reserve forking for cases the extension points genuinely cannot reach — forking a vendor bundle is an ongoing merge tax.

When to Consider This Package

Consider it when:

• You are already on, or actively evaluating, Ibexa DXP. The README is explicit: to use this package, install Ibexa DXP. It is a component of a platform, not a standalone dependency.
• You need an enterprise-grade, multi-site, multi-language back office and are prepared to hold an Ibexa subscription (the Ibexa Business Use License is granted via a valid DXP subscription).
• Your team is comfortable with Symfony/PHP on the backend and a substantial JS front end (modals, dropdowns, pickers, Behat-covered UI flows).
• You want vendor-maintained editorial UX rather than owning it, and you can absorb a regular patch cadence.
• Legal has reviewed the licensing: the repo is dual-licensed Ibexa BUL 2.4+ or GPLv2. The GPLv2 option is copyleft and has real obligations if you distribute modifications; the commercial path requires an active subscription. Do not treat the "NOASSERTION" metadata as permission to use freely.

Look elsewhere when:

• You are building a Laravel application and want an admin panel. This is a Symfony-based DXP bundle with no Laravel integration; a Laravel-native admin (Filament, Nova, Backpack) or a headless CMS is the fit.
• You need an MIT/Apache-licensed dependency, or your org prohibits copyleft or subscription-gated components.
• Community support is a hard requirement. 7 stars and 0 dependents reflect how it ships (inside the DXP metapackage via a private/vendor channel), not quality — but it does mean no third-party ecosystem, no Stack Overflow corpus, and support that runs through Ibexa's commercial channel.
• The admin interface is not a differentiator for your product. You are paying for a platform to get this surface; if a thin internal tool would do, the license and upgrade overhead are unjustified.
• You need to heavily restructure the admin UI beyond the documented extension points. Extension points are the supported path; deep forks of a vendor bundle are a maintenance liability.
• You are pre-revenue or proof-of-concept and cannot commit to subscription costs and periodic upgrades.

How to Pitch It (Stakeholders)

For executives (one paragraph):

ibexa/admin-ui is not a product we would adopt on its own — it is the back-office interface of Ibexa DXP, the platform we would license. Its value is time-to-market on the editorial experience: multi-language authoring, content modeling, notifications, permissions, and commerce content blocks are already built and actively maintained, with parallel 4.6 and 5.0 release lines. The cost is a subscription plus a recurring upgrade obligation, and the strategic risk is vendor lock-in with a small third-party ecosystem. Recommendation: evaluate it as part of an Ibexa DXP decision, not as a standalone package, and run the dual-license question (commercial BUL vs. GPLv2) past legal before any commitment.

For engineering:

Symfony bundle, shipped as part of the DXP metapackage — install the DXP, don't try to pull it in isolation. Customization should be additive: subclass window.ibexa.BaseFieldValidator for field-level validation, use the richtext and translation-selector extension points, and prefer the documented hooks over patching vendor code. Expect a JS-heavy surface with Behat coverage; 5.0 tracks Symfony 7.4 LTS while 4.6 remains the conservative branch. Upstream is actively patching UI defects, so pin versions and budget for regular patch merges.

For the product team:

Treat this as the baseline, not the differentiator. Map roadmap items to capabilities already present here before scoping custom work — translation editing, field validation UX, table actions, product embeds, and product tours are largely solved. What remains genuinely ours to build is the domain logic and workflow on top of the back office, plus any extension-point integration we need. Flag licensing early: it gates distribution and any redistribution of modified code.