Weave Code
Content Decorator Bundle Laravel Package
kaliop/content-decorator-bundle
A Symfony bundle from Kaliop that adds a decoration layer for content objects, letting you attach custom presentation methods and computed values without changing the underlying content model. Helps keep templates clean by moving view-specific logic into reusable decorators.
At a glance
Frequently asked questions about Content Decorator Bundle
- What is kaliop/content-decorator-bundle and what does it do?
- It is a Symfony bundle from Kaliop that adds a lightweight decoration layer on top of Ibexa (formerly eZ Platform) content objects. Decorators are registered through configuration and resolved on demand, so you can attach computed, presentation-ready values to content and location objects without pushing that logic into controllers or templates. The underlying content model stays untouched, and the three-layer split (src/contracts, src/lib, src/bundle) keeps the declared API separate from the wiring.
- Is it a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. There is no Laravel service provider, facade, or config bridge, and the bundle layer is a Symfony DI extension aimed at Ibexa applications. If your stack is Laravel-only, this is a first-order mismatch you should resolve before evaluating anything else.
- Which Ibexa, Symfony, and PHP versions does it support?
- The 2.x line pins Ibexa 5.0, Symfony 7.4 LTS, and PHP 8.3 or newer. The 1.x line pins Ibexa 4.6, Symfony 5.4 LTS, and PHP 8.1 or newer. The maintainers explicitly forbid widening these constraints within a major line, so your upgrade calendar becomes coupled to theirs. Never mix major lines across environments.
- How do I install and enable it with Composer?
- Install it with Composer using a constraint that matches your Ibexa major, then enable the bundle in your Symfony bundles configuration and declare your decorators in the bundle config. Validate the result with composer validate --strict and a full install into a representative Ibexa application, since Ibexa installations are dependency-heavy and transitive conflicts are the real risk. Mirror the upstream matrix in CI (PHP 8.3, Symfony 7.4, Ibexa 5.0 for 2.x) and confirm no clashes with bundles you already run.
- How do I write and register a custom decorator?
- Extend the base classes the bundle provides, implement the contracts exposed in src/contracts, and register your class through the bundle's service tag and configuration rather than hand-wiring services. Declarative configuration means no boilerplate wiring. Because evaluation is lazy and on demand, decorators only run when a view actually asks for the value, which keeps rendering fast.
- Does it work with Twig templates?
- Yes, the bundle is designed to integrate cleanly with Twig and your existing Symfony services. The point of the decoration layer is to keep templates clean by moving view-specific logic into reusable decorators that templates can call. That gives your views exactly the data they need without sprinkling Ibexa field identifiers and version bookkeeping through markup.
- Are decorators evaluated lazily, and what is the performance impact?
- Decorators are resolved on demand and evaluated lazily, so values are only computed when the view requests them. That keeps rendering fast compared with eagerly building every computed value up front. The main cost to watch is any decorator that itself hits the Ibexa repository layer, so keep expensive lookups inside a single decorator call rather than repeating them per field.
- What are the maintenance and production risks?
- The ecosystem signals are weak: roughly two stars, zero dependents, and the appearance of a single maintainer, which means no downstream validation or community troubleshooting. The release metadata should be treated as unreliable until you verify the actual tags on the repository. Against that, the engineering hygiene is unusually strong for a project this size: deptrac-enforced layering, PHPStan, coding-standard checks, a SemVer policy, maintenance branches, and tag-driven CI releases to Packagist. That combination makes a fork cheap to own, because the scope is small and the quality gates already exist.
- Does it cover versions, languages, locations, relations, and custom field types?
- src/contracts is the declared stable API surface, so audit it against your top five content types and field types before committing. The hard parts to verify are mapping coverage for versions, languages, locations, relations, and custom field types, because anything missing means patching src/lib and owning a fork. Run a spike that maps one real content type end to end through a decorator and its repository, then size any gaps immediately.
- Can I use it in Laravel by porting src/lib, or should I look elsewhere?
- The repository layer over Ibexa's untyped Content, ContentInfo, and field-value API is nominally separable, but it carries Symfony service and Ibexa repository-interface dependencies, so extraction is more work than the layer names imply. On Laravel, either reject the package or re-scope to porting src/lib behind your own interfaces rather than bridging Symfony's container into Laravel's. The glue cost is not justified by the payload, and wrapping the contracts in a thin anti-corruption layer keeps your dependency surface to one namespace.
Weaver
How can I help you explore Laravel packages today?