Content Browser Laravel Package

Getting Started

This is not a Laravel package. se7enxweb/content-browser is a fork of netgen/content-browser 1.4.1 — a Symfony bundle for eZ Platform / Ibexa that ships a content-picker UI (backend REST endpoints + a JS frontend) used by Netgen Layouts and admin UIs. There is no service provider, no facade, no config/content-browser.php. If you are on Laravel, your realistic options are:

1. Consume it over HTTP — the picker's endpoints are plain JSON routes on the eZ Platform host; call them from Laravel with the HTTP client (see Implementation Patterns).
2. Install it properly on the eZ/Ibexa side — if you own that stack too, this is the supported route.

Where to look first, in this order:

• composer.json — confirm the fork declares replace: netgen/content-browser and the php constraint (~8.0 per the release note). This determines whether it will install at all next to existing extensions.
• README.md / docs/ — install steps and the configuration tree.
• bundle/NetgenContentBrowserBundle.php and bundle/Resources/config/ — services, routing, default settings.
• bundle/DependencyInjection/Configuration.php — the authoritative list of config keys (do not trust blog posts; 1.4 keys differ from 0.x/2.x).
• bundle/Resources/public/ (or Resources/public/js) — the JS entry point and the options it accepts.

Minimal install on Platform 2.5 / PHP 8.0:

composer remove netgen/content-browser
composer require se7enxweb/content-browser:^1.4

// app/AppKernel.php
new Netgen\ContentBrowser\Bundle\NetgenContentBrowserBundle(),

# app/config/routing.yml
netgen_content_browser:
    resource: "@NetgenContentBrowserBundle/Resources/config/routing.yml"
    prefix: /content-browser

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

First use case: an editorial "pick a location/content" dialog. Mount the bundled JS browser into a container element, point it at your routing prefix, and read the selected item's locationId / contentId out of the select callback to store in your own model.

Implementation Patterns

Pattern 1 — content picker in an admin template. This is the package's whole reason to exist. Provide a container node, initialise the browser with { rootLocationId, allowedContentTypes, apiRoot }, and handle the selection event by writing the returned ID into a hidden input. Keep the browser instance in a page-level variable so you can destroy/recreate it when a modal reopens — stale instances leak listeners.

Pattern 2 — headless usage from Laravel. Skip the JS entirely and treat the endpoints under your routing prefix as a content API. The set is small and stable in 1.4: browse children of a location (with limit/offset/sort), fetch a single item's details, and search. From Laravel:

$response = Http::withToken(config('services.ez.token'))
    ->baseUrl(config('services.ez.url').'/content-browser/api')
    ->get('/children', ['locationId' => $rootId, 'limit' => 25, 'offset' => 0]);

Wrap it in a ContentBrowser service class with children(), item(), search() methods plus a small cache layer — you do not want an editor's keystroke-by-keystroke search hitting the eZ search backend directly.

Pattern 3 — proxy/aggregate. If your Laravel app is the single front door, expose your own thin endpoint (/api/picker/children) that validates input, forwards to eZ, and normalises the payload into your own DTO. This keeps the eZ URL/token out of the browser and lets you swap the backend later — the fork's continued maintenance is not guaranteed.

Pattern 4 — custom backends (PHP side only). If you are on the Symfony/eZ side, 1.4 is built around pluggable backends and item/value converters: register a service implementing the backend interface, tag it, and reference it from config. Useful for exposing non-content sources (users, taxonomy, external catalogue) in the same picker UI. Same applies to custom item templates via the Twig/JS view layer.

Pattern 5 — embed inside Netgen Layouts / Admin UI. The upstream consumer. Keep this package's version in lockstep with the Layouts version you run; the 1.4 line was built against a specific Layouts generation.

Gotchas and Tips

• The rename is the real breaking change. Package name, vendor, and possibly the bundle class namespace all changed. After swapping, grep your AppKernel, routing.yml, config.yml, and any composer.json of in-house extensions for netgen/content-browser. If a dependency still requires the upstream name and the fork does not replace it, Composer will install both and you will get duplicate bundle registrations and duplicate routes. Verify with composer why netgen/content-browser.
• PHP 8.0 only. The note says "allows PHP 8.0" — that is typically a ~8.0.0 constraint, which will refuse to install on 8.1+. On a mixed fleet, pin per-project: "config": { "platform": { "php": "8.0.30" } }. Do not assume 8.1/8.2 compatibility just because "it's newer".
• Platform 2.5 = old Symfony. Expect Symfony 3.x/4.x idioms: AppKernel, YAML routing, no attributes, no autowired controllers. Laravel-style expectations (package discovery, published config, artisan) simply do not apply.
• Assets go stale silently. After upgrade, the picker often renders blank or with the old UI because web/bundles/... still holds 1.4.1 files. Always assets:install --symlink (or ezplatform:assets:install if that is your flow) plus cache:clear. Blank picker = asset mismatch nine times out of ten.
• Permissions, not configuration, cause empty results. The endpoints respect eZ content read policies. Anonymous or editor roles missing content/read on the root location get a valid but empty list — no error. Check the Network tab for a 200 with [] before debugging config.
• Search behaviour depends on the search engine. Legacy search vs Solr/Elastic produce different result ordering, and limit/offset semantics with filters can differ. Test search against the same engine as production.
• CSRF and sessions. If your install enables CSRF on those routes, a cross-origin call from a Laravel app will fail with 400/419. Either call server-to-server with a token, or explicitly exclude the API routes — and remember the browser frontend relies on the eZ session cookie when used in-admin.
• Caching. Config changes require cache:clear; content changes require the eZ view/content cache to invalidate. In dev, disable the HTTP cache or you will chase phantom stale pickers.
• Debugging checklist. (1) bin/console debug:router | grep content-browser — routes registered? (2) debug:container | grep content_browser — services loaded? (3) hit an endpoint directly with curl using an authenticated cookie — JSON shape sane? (4) browser console — is the JS bundle loaded from the expected path?
• Fork risk. This is a single-maintainer republish with no upstream roadmap. Treat it as a pinned dependency: lock the exact version, wrap every call behind your own adapter class, and keep an exit path (direct eZ API calls, or a native picker) in mind. Do not let its DTO shape leak into your domain models.
• Extension points to know. Backends, item/value converters, and the JS browser options object are the three seams you are most likely to need; all three are stable enough in 1.4 to build on, and none require forking the package.