Shop Bundle Laravel Package

Getting Started

First, the framework reality check. This is not a Laravel package. There is no service provider, no config/shop.php, no auto-discovery entry, no Eloquent models. enhavo/shop-bundle is a Symfony bundle (a subtree split of the Enhavo CMS monorepo) built on Sylius components. If you are in a Laravel app, there is no "getting started" path here that is a sane use of time — you would be rebuilding Enhavo's resource/routing/block abstractions and Sylius's component wiring inside Laravel's container. Stop and evaluate sylius/* components directly, or a Laravel-native commerce option, instead.

If you are legitimately on Symfony (and ideally already on Enhavo), the minimal path is:

1. Read the monorepo, not this repo. This split is [READ-ONLY]; README is a logo and a pointer. Go to github.com/enhavo/enhavo, find the shop bundle directory, and read its composer.json, DependencyInjection/, Resources/config/, and Entity/ first. Those four places tell you the constraint matrix, the services, the routes, and the domain model — i.e. everything the split won't tell you.
2. Install via the monorepo, not the split. Add the main repository as a VCS/path dependency and pin to a parent release tag. Register the bundle in config/bundles.php alongside its Enhavo prerequisites (resource, routing, block, media, user/permission) — the shop bundle does not stand alone; it inherits that bundle graph.
3. Find the entry point in the admin UI. Because the shop is wired through Enhavo's resource abstraction, the fastest orientation is to boot the CMS, log into the admin, and look at the generated product/shop routes. The admin is the map: each resource maps to a controller, a form, a repository, and a template. That route → resource → entity chain is your reading order.
4. First use case: one vertical slice. Product create/edit in the admin → expose a product to a Twig template → add to cart → persist an order. Do this in a sandbox Symfony app before touching a real project. It exercises the resource layer, the Sylius product/order primitives, and the templating integration in one pass, and it will surface any container-compile failures early.

Budget a spike (days, not hours) just to get the container compiling with the right bundle set. If that compiles cleanly and the slice works, you have a foundation. If it fights you, treat that as the answer.

Implementation Patterns

Resource-driven CRUD (the dominant pattern). Enhavo's resource abstraction is how the shop's entities are managed. Day-to-day this means you are not hand-writing controllers and admin screens for products and shop data — you declare a resource (entity class, form type, repository, routing) and Enhavo generates the admin CRUD around it. When you need a new shop-related admin entity, the idiomatic move is add a resource, not write a controller. Learn this pattern first; it is the single highest-leverage thing in the bundle.

Sylius components for domain, Enhavo for presentation. The split of responsibility is: Sylius components supply the commerce domain concepts (product, order, pricing, cart semantics), Enhavo supplies the CMS/admin/resource/Twig layer. So when a requirement is "how is price calculated," go to Sylius component source and configuration; when it's "how does an editor manage this in the admin," go to Enhavo resources. Keeping that line clear prevents you from hunting for pricing logic in the CMS layer or admin wiring in Sylius.

Content-coupled storefronts. The bundle's real value proposition is merchandising driven by editorial content: landing pages, lookbooks, campaign pages that surface products, rather than a pure catalog grid. The pattern is to build storefront pages as Enhavo content/block structures and reference shop entities from them, letting editors compose product-bearing pages in the CMS. Lean into this — it is where the bundle is differentiated and where the Sylius-components-without-full-Sylius footprint pays off.

Service overrides via the container. Because this is Symfony DI, integration tweaks happen through service decoration/overriding and parameters rather than config files. If you need custom pricing, a modified repository, or a decorated cart service, define your service in your app's services.yaml and decorate the Enhavo/Sylius service. This is the extension mechanism you'll reach for most; keep a running note of service IDs you override, because that list is your upgrade surface.

Template overrides. Storefront and admin rendering is Twig. Overriding templates (via bundle template precedence / your app's templates/bundles/... paths) is the standard way to adjust UI without forking the bundle. Do visual/logic changes in overridden templates and keep the bundle source pristine so upstream updates stay mergeable.

Keep a dependency register. Because the split lags the monorepo, record the mapping: your pinned parent release tag ↔ the split commit ↔ the Sylius component versions pulled. That mapping is the only reliable way to answer "what are we actually running" during upgrades or CVE triage.

Gotchas and Tips

• It is not Laravel. This is the gotcha. No service provider, no auto-discovery, no Laravel config, Eloquent models don't exist here. Any plan assuming composer require enhavo/shop-bundle in a Laravel app "just works" is wrong. Correct that assumption in writing before it propagates.
• Do not file issues or PRs here. This repo is [READ-ONLY]; the tracker is a dead end. Everything goes to github.com/enhavo/enhavo. Wire that into your team's contribution norms so people don't lose time on a mirror.
• Zero stars, zero dependents is a real signal. No third-party plugins, no external validation, no community fixes. Treat this as "source-available reference implementation you own," and price the maintenance accordingly.
• Pin exactly and monitor upstream. Pin to a parent release tag, and check upstream release activity quarterly. If Enhavo stalls or the Sylius component constraints fall behind security patches, start the exit path. A commerce bundle — money, orders, inventory — on stale Sylius constraints is a liability that compounds.
• Constraint matrix is the go/no-go gate. Before any code: confirm PHP version, Symfony major, Sylius component majors, Doctrine ORM/DBAL versions, and whether any are already EOL. Do this first; it kills or greenlights the effort cheaply.
• Container compile is the real smoke test. Does the bundle boot without the full Enhavo CMS bundle graph, or does it hard-require core bundles at compile time? Answer this in a bare Symfony app before building anything. If it hard-requires the whole CMS, accept that you're adopting Enhavo, not just a shop.
• Watch the admin/CMS surface when scaling. App-level scaling is standard PHP-FPM/Doctrine. The risk is Enhavo's block/media abstractions on the admin side adding heavy queries and file-storage coupling. Load-test the storefront/checkout path specifically — don't assume the CMS's read patterns generalize to checkout traffic.
• Sylius major upgrades are breaking. Budget for the component upgrade, not just the bundle upgrade. Decoration lists (the services you override) are your migration checklist.
• No docs means reading source is the onboarding plan. Plan a spike, not a rollout. Whoever owns this should be comfortable in Symfony, Doctrine, and Sylius source, because that's the only documentation you get.
• Design an exit path now. Because the underlying commerce primitives are Sylius components, you can reduce lock-in by keeping your custom logic in services that decorate Sylius/Enhavo services rather than forking the bundle. If adoption sours, "drop Enhavo, keep Sylius components" becomes plausible instead of a rewrite.
• Confirm what ships. Verify whether the bundle includes migrations, fixtures, and admin UI or domain logic only — this changes your install and data-seeding work substantially, and the split gives you no hint.