Content Browser Sylius Laravel Package

Product Decisions This Supports

• Content-and-commerce architecture: Informs whether to keep editorial authoring in a CMS (Netgen Content Browser) and reference it from the commerce admin, rather than duplicating content workflows inside Sylius. This is a "separate systems, shared picker" decision, not a CMS replacement.
• Build vs. buy for an admin content picker: If the roadmap includes "let an editor attach a product, taxon, or custom entity to a page/block/layout," this package is a reuse candidate against 2–6 weeks of custom modal, serialization, and search work. It supplies the browsing/selection backend; the consuming screen is still yours to wire.
• Roadmap fit — merchandised content: Supports PDP/PLP content slots, campaign landing pages, navigation/footer blocks, and cross-sell modules if Netgen Content Browser is already strategically chosen. If it isn't, adopting this package effectively makes the CMS decision for you.
• Platform standardization: Clarifies that this is a Symfony/Sylius artifact, not Laravel. If a "one PHP stack" or Laravel-first decision is on the table, this package is out of scope by construction.
• Vendor/maintenance posture: Given 14 stars, 0 dependents, and a low composite score, the realistic product decision is "adopt as a pinned/forked reference implementation," not "add a community-supported dependency." That distinction should be made explicitly in the architecture decision record.

When to Consider This Package

Consider it when all of the following hold:

• Netgen Content Browser is already adopted or firmly committed as the content source, with a consuming application (typically Netgen Layouts or a custom admin screen) in place or planned.
• Sylius is the commerce platform and you need editors to browse and select Sylius resources (products, taxons, configured custom entities) through a consistent picker.
• You want a single picker across heterogeneous sources, not just "choose a product" — the native Sylius Grid handles simple selection with far less surface area.
• Your team is comfortable with Symfony bundle wiring (DI, service definitions, routes, Twig, asset publication).
• You accept the maintenance profile: a single-vendor, low-traffic bridge. Budget to pin exact versions and keep a vendored-fork path open.

Look elsewhere when:

• You are greenfield on content: evaluate turnkey Sylius CMS plugins, headless CMS options, or native Sylius CMS blocks before adding a bridge to a CMS you don't yet run.
• You need a Laravel-native solution. This is Symfony/Sylius-oriented and will not drop into a Laravel application.
• Simple content needs are met by Sylius' built-in CMS blocks and pages.
• You require active maintenance, SLA, or community support — the adoption signals here are effectively zero, so treat it as read-the-source-code software.
• You need marketplace/B2B-specific content workflows the bridge doesn't cover.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed connector that lets a Sylius storefront surface editorial content managed in Netgen Content Browser — campaign pages, product storytelling, category slots — without standing up a second content system. Technically low risk to try; operationally it is niche (14 stars, no dependents, one apparent maintainer), so the honest framing is "reuse a reference implementation and own the maintenance," not "adopt a supported product." Recommend a one-surface pilot with editorial-velocity metrics, then decide on fork versus replace. Note the stack constraint up front: this is a Sylius/Symfony integration, not a Laravel one.

To engineering: A standard Symfony bundle that registers Content Browser sources backed by Sylius repositories, so the picker reuses existing Content Browser UI/JS instead of a bespoke modal. Work is mostly configuration, bundle registration, route import, asset publication, and wiring the picker into an admin form — no drop-in admin screen. Key caveats: verify version constraints against our Sylius/Symfony release before committing; the browser endpoint must sit behind the admin firewall with resource-level authorization; and asset pipeline mismatch is the most fragile surface across upgrades. Plan for one named owner, a pinned tested version combination in composer.json, a retained native Sylius selection fallback, and an integration test so Sylius minors don't silently break the picker.