Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Standard Design

Standard Design Laravel Package

ibexa/standard-design

The Ibexa standard design bundle supplies the default design and theme for Ibexa DXP, managed by ezplatform-design-engine. As part of the Ibexa DXP ecosystem, it provides standard front-end styling and templates for Ibexa-based sites. Install Ibexa DXP to use this package.

View on GitHub
Deep Wiki
Context7

Ibexa Standard Design Bundle

Frequently asked questions about Standard Design
Is ibexa/standard-design a Laravel package I can install with Composer in a Laravel app?
No. It is a first-party Symfony bundle that ships as part of Ibexa DXP (formerly eZ Platform), and it has no service provider, no Laravel auto-discovery, no Artisan commands, and no Eloquent models. There is no meaningful way to wire it into a Laravel application. If you are evaluating it for a Laravel project, the only transferable part is the static CSS and Twig markup, which you would copy rather than depend on.
How do I install ibexa/standard-design?
You do not install it standalone. The README is explicit that you should install Ibexa DXP, and this bundle then comes in as a dependency pinned by the DXP metapackage. There is no documented standalone install path and no configuration reference beyond the design-engine contract. Treat it as a vendor dependency of the platform, not a package you add on its own.
What does this package actually contain?
It contains the default Ibexa DXP design and theme: Twig templates, asset mappings, front-end styling, and design configuration consumed by ezplatform-design-engine. It is the reference theme the design engine resolves against. It is purely a view-layer artifact, so application and domain code should never reference it directly.
Which Laravel or PHP versions does it support?
Laravel version support is not applicable, since this is not a Laravel package. What actually matters is the Ibexa DXP release and the ezplatform-design-engine version the bundle is locked to. Compatibility is determined entirely by the host DXP's install profile and version, so check the DXP changelog for the supported branch.
How do I customize the theme without editing files in vendor?
Use the intended child-design override model: create a separate custom design bundle that declares this standard design as its parent, and override Twig templates and assets there. Never edit vendor files, because composer updates will silently discard your changes. You should also confirm the documented upstream guidance for child-design overrides before you build out a large set of customizations.
What license applies and can I use it commercially?
It is dual-licensed: the Ibexa Business Use License v2.4 or later, or GPL v2. The BUL is granted only with a valid Ibexa DXP subscription and is not an OSI-approved open-source license, while GPL v2 is copyleft. This makes it a commercial-use gate rather than a formality, so legal review is a prerequisite before adoption. Note also that the BUL carries an or later versions clause, meaning the terms can change under you.
Is this package actively maintained, and what is the story with the 2026 release date?
The repository shows a last release dated 2026-08-20, which is a future date relative to normal release cadence and looks like a metadata or registry artifact or a scheduled tag. Do not treat that as proof of active maintenance until you verify it against the Ibexa DXP changelog. Low stars and zero dependents are expected for a vendor-split bundle rather than signs of abandonment, but they do mean there is almost no community troubleshooting corpus, and support is vendor-contract-only.
What testing do I need to do if I override templates?
The repository ships no CI badge, no test suite, and no contribution guide, which is normal for a theme bundle but means you own all regression testing on your overrides. Because the design bundle is tightly version-locked to the DXP release and to ezplatform-design-engine, minor DXP upgrades can break template overrides. Build visual and functional regression checks around your child design before every DXP upgrade.
How tightly is it coupled to Ibexa DXP upgrades, and what is the migration path?
It is tightly coupled: the bundle is version-locked to the DXP release and to ezplatform-design-engine, and the intended customization path is the child-design override. If you are migrating from a legacy eZ Platform or custom theme, stand up a clean Ibexa DXP install at the target version with this bundle resolved from vendor, then port your overrides into a custom design bundle. Ask the vendor for the tested override-compatibility window across minor versions.
What are the alternatives if I am on Laravel or want a headless front end?
If your target platform is Laravel, Symfony, or a headless CMS/API stack, fit for this bundle is effectively zero, and you should look at Laravel-native CMS or headless options instead. If you stay on Ibexa DXP, a headless or decoupled front end can make this theme optional rather than load-bearing. That is worth raising with the vendor, along with which DXP edition and version tier your subscription covers.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console