Content Browser Ezplatform Laravel Package

Getting Started

First, resolve the stack question — it determines whether the rest of this document applies. se7enxweb/content-browser-ezplatform is a Symfony bundle for eZ Platform / Ibexa, not a Laravel package. There is no service provider, no facade, no config/content-browser.php publish tag, and no Laravel version constraint. In a Laravel application the only honest integration path is an adapter built against Ibexa exposed over an API — a project, not an install. If your target is a Laravel estate, stop here and read the Implementation Patterns section's "reference implementation" entry instead.

For an Ibexa/eZ Platform estate, the first look is:

1. composer.json — read the require block before anything else. It is the only reliable statement of supported PHP/Symfony/Ibexa versions, and the material supplied here contains no supported-versions matrix.
2. The bundle class (typically src/Se7enXWebContentBrowserBundle.php or similar) — confirms registration mechanics and any compiler passes.
3. The 1.4.1...v1.4.2 compare diff on GitHub. The release note is a bare compare URL with no changelog body, so this diff is the changelog.
4. The admin UI route/entry point defined in the bundle's routing config — that's where the content tree renders.

Minimal install shape (indicative — verify names against the bundle):

composer require se7enxweb/content-browser-ezplatform:1.4.2

Then register the bundle in the kernel (Symfony 4/5: config/bundles.php; older eZ Platform: app/AppKernel.php), clear cache, and rebuild assets if the bundle ships templates/JS:

bin/console cache:clear
bin/console assets:install --symlink

First use case: an editor logs into /admin, opens the content browser, navigates the location tree, filters by content type or text, and jumps straight to a content item's preview/metadata. That tree-plus-preview-plus-filter loop is the entire value proposition — validate it end-to-end in a disposable environment before committing to anything.

Implementation Patterns

Register-and-configure (Ibexa-native). The bundle is consumed the standard Symfony way: Composer, kernel registration, optional YAML under config/packages/. Do not look for a Laravel-style publish workflow; there isn't one. Treat any bundle config as code — commit it, don't click it in.

Pin the exact tag. Given that v1.4.2's release body discloses nothing, pin 1.4.2 exactly (no caret range) and drive upgrades through a branch with a reviewed diff. This is the single highest-value habit with this package.

Reference implementation (Laravel team, recommended). Read the package for its content-tree traversal, filter UX, and preview metadata layout, then reimplement against your own content API. You capture the design value without inheriting a second framework's release train. Concretely: skim the templates for the tree/filter markup, and the controller/service layer for how it resolves child locations and applies filters.

Adapter/bridge (only if you already run Ibexa alongside Laravel). Expose browsing over a thin HTTP endpoint from the Ibexa side — locations, children, filtered search, item metadata — and render it in Laravel. Cache aggressively (location trees are read-heavy and change rarely); invalidate on content publish events. Treat this shim as a product with its own owner and test suite, because it will decay as Laravel and Ibexa majors diverge.

Template/view override (Ibexa-native). Prefer overriding the bundle's Twig templates in your own design/theme layer over forking the bundle. That keeps the upstream dependency intact and your customisations legible in diffs.

Vendor-and-fork plan, documented in advance. For a single-maintainer-namespace project, write down now: who forks it, where the fork lives, and what triggers the fork. Do this before you need it.

Gotchas and Tips

The release notes are empty. v1.4.2's body is one compare URL. A patch bump implies bugfixes under semver convention, but this project publishes no versioning policy. Never auto-merge an upgrade; always read the diff. Budget roughly an engineer-day per release for review-and-verify.

This is not a Laravel package. The most common failure mode in this assessment is a keyword match — "PHP package" routed to a Laravel team. If someone asks why composer require dragged in Symfony, this is why. Escalate the stack-fit question before writing any code.

GPL-2.0 is copyleft. If you vendor, fork, or bridge this into a proprietary codebase, get licence review first. This is a real constraint, not a formality, and it differs sharply from the MIT/Apache packages a Laravel shop is used to.

Composer constraint conflicts are the likely first blocker. eZ/Ibexa extensions pin tightly to a PHP/Symfony matrix. Resolve in a branch and verify the full dependency graph — a conflict here can block unrelated upgrades across the application.

Permissions drive what the browser shows. The tree renders against the current user's content read policies. "Missing content" is usually a policy problem, not a bundle bug. Check the role/policy assignments before debugging code.

Cache is the usual suspect after any change. eZ Platform layers caches (Symfony container, view cache, HTTP cache, legacy caches on older versions). After registering the bundle, changing templates, or bumping the version, clear all of them, not just cache:clear. If the admin UI renders stale or blank, this is the first thing to try.

Debugging entry points. Use the Symfony profiler on the browser route to inspect the controller, queries, and template resolution; bin/console debug:container and debug:router confirm the bundle actually registered; application logs under var/log/ catch Twig and DI errors that surface as a blank admin panel.

Extension points, in order of preference: bundle config (if any), Twig template override, a thin custom controller/service that composes the bundle's services. Forking the bundle itself is a last resort — and one you should have pre-planned given bus-factor risk.

Assume you may need to self-support. No commercial support path is evident. Track upstream issues, and keep the fork option warm. A content browser is an admin read-path component, so the blast radius of failure is a degraded editorial experience rather than data loss — size your investment accordingly.