Front Bundle Laravel Package

Getting Started

First, calibrate expectations. monofony/front-bundle is a Symfony bundle from the Monofony e-commerce framework (a Sylius derivative). There is no service provider, no facade, no Eloquent, no Blade. If you are on Laravel, the "getting started" step is a reading exercise, not a composer require — pulling it into a Laravel app is a port, not an integration. The realistic first move for a Laravel dev is to clone the repo and read it as reference material.

If you genuinely are on Symfony/Monofony, the minimal path:

composer require monofony/front-bundle

Register in config/bundles.php, ordered after the bundles it depends on:

return [
    // ...
    Sylius\Bundle\ResourceBundle\SyliusResourceBundle::class => ['all' => true],
    Sylius\Bundle\GridBundle\SyliusGridBundle::class => ['all' => true],
    Monofony\Bundle\CoreBundle\MonofonyCoreBundle::class => ['all' => true],
    Monofony\Bundle\FrontBundle\MonofonyFrontBundle::class => ['all' => true],
];

Import routing last in config/routes.yaml so your own routes can shadow the bundle's:

monofony_front:
    resource: "@MonofonyFrontBundle/Resources/config/routing.yml"
    prefix: /

Where to look first, in order:

1. src/Controller/ — every entry point. Read all of them before writing anything; the value of this bundle is knowing exactly which actions exist and what they render. This is also your MVP checklist: catalog, product detail, cart entry, checkout entry.
2. src/Resources/config/routing/ — route names you'll be reverse-routing to (monofony_front_homepage, taxon/product routes).
3. src/Resources/views/ — the Twig hierarchy, i.e. every block you can override.
4. src/DependencyInjection/ — the extension class reveals config keys, service aliases, and what's public.

First use case: get the homepage rendering. bin/console debug:router | grep monofony to confirm monofony_front_homepage resolves, then hit /. Blank page / template-not-found / missing-taxon errors here almost always mean missing fixture data or an unregistered Sylius resource — not a bundle bug.

For a Laravel team, the equivalent first use case is: skim the controllers against your own feature list and decide whether the shape (route-per-action, repository-driven fetches, Twig partials per component) is worth reimplementing in Laravel controllers and Blade components.

Implementation Patterns

Template overriding is the dominant day-to-day workflow. Copy a template from vendor/monofony/front-bundle/src/Resources/views/ into templates/bundles/MonofonyFrontBundle/<same relative path> and edit. This is Symfony's standard bundle override path, survives composer update cleanly, and is the least invasive extension point. Keep an explicit list of shadowed files — that list is your upgrade diff when you eventually bump the dependency.

Extend or decorate controllers; don't fork the routing. If controllers are registered as services, decorate them:

App\Controller\Shop\ProductController:
    decorates: monofony.front.controller.product
    arguments: ['@.inner']

If they're classic AbstractController subclasses invoked via Controller::method, subclass them and point your route at App\Controller\...::show, leaving the bundle's route file untouched. Either way, the bundle remains the single source of routing truth; you only change behaviour.

Resource configuration is the data contract. Monofony/Sylius-style bundles expect you to declare your own entity classes in config/packages/_sylius.yaml (or monofony.yaml) and map them to the bundle's interfaces. Front controllers fetch via repository services keyed on those resource names. Rename a resource or swap a repository class and routing still works — but show/index actions will 404 or throw. When confused: bin/console debug:container | grep -i <resource>.

Grid definitions drive listing pages. Product and taxon listings come from Sylius Grid definitions rather than controller logic. To change what appears on a listing, change filters/sorters/columns in the grid config, not the controller. This is the Sylius-family idiom and the first thing that surprises people coming from hand-rolled queries.

Composition over inheritance for the storefront shell. Keep a layout template that composes bundle blocks (header, nav, cart widget, footer) rather than overriding one giant layout.html.twig. Overriding the top-level layout is a maintenance trap — the next minor release invalidates your copy wholesale.

If you're reimplementing in Laravel (the realistic path): mirror the route surface and controller-per-action structure, translate Twig blocks into Blade components, and treat Sylius resource repositories as Eloquent repositories behind interfaces. The bundle is useful here precisely because it's a worked example of storefront decomposition — catalog, taxon, product, cart — that you can port piecemeal.

Gotchas and Tips

This is not a Laravel package, despite how it's indexed. No ServiceProvider, no config publish, no artisan commands. Every integration guide assumes Symfony DI, Twig, the Sylius resource layer, and the Symfony event dispatcher. A composer require in a Laravel app will install transitive Sylius packages that do nothing and clutter your dependency tree. Don't.

Version lock is the sharpest edge. Monofony historically tracked Symfony 4/5. The bundle's composer.json constraints are typically looser than the actually tested matrix, and Sylius component pins (plus Doctrine and Twig) propagate transitively. Before committing to anything, run a dependency-resolution spike in a throwaway branch against your exact target Symfony minor. Do not trust the constraints alone.

Adoption signals are a hard gate, not a footnote. One star, zero dependents, no release cadence, no security disclosure surface, single-maintainer risk. Treat this as source code to fork and own, not a package to track. If nobody on the team will own the fork (Symfony upgrades, Doctrine compatibility, CVE response), the answer is no. Sylius's own ShopBundle has orders of magnitude more adoption and documentation if you're staying in that family.

Template-not-found and missing-taxon errors are almost never the bundle. They mean missing fixtures, an unregistered resource, or routing imported before the bundle that defines the resources it needs. Check debug:router, debug:container, and your fixture load order before reading vendor source.

Route ordering matters. Import the bundle routing last so your app routes shadow it. If you override routing in the wrong order, your controllers silently never run and you'll debug the bundle for an hour.

Bundle registration order matters too. It must come after TwigBundle, SyliusResourceBundle, SyliusGridBundle, and MonofonyCoreBundle. Wrong order gives you DI errors that point at the wrong file.

Overrides break silently on internal changes. Because the bundle wraps Sylius internals with loose constraints, template-block names and service IDs can shift between Sylius minors without a major version bump here. Pin the transitive Sylius versions in composer.lock and treat any Sylius bump as a potentially breaking change you must manually verify against your shadowed templates.

No escaping the platform commitment. Adopting this bundle is a de facto decision to standardize on Monofony/Sylius conventions — resource/grid configuration, repository-keyed controllers, Twig hierarchy. That's a platform-architecture decision, not a library swap. Evaluate it at that level before writing a line of integration code.

Highest-value use for most teams: read it. The controller and routing surface is a fast, concrete enumeration of what a minimum viable storefront needs (catalog browse, product detail, cart entry, checkout entry) — useful as a scoping checklist even if you never install it, and as a structural reference if you build the front end yourself in Laravel or go headless.