Front Bundle Laravel Package

Getting Started

Before writing a line of integration code, confirm the package actually fits your stack. wizaplace/front-bundle is a Symfony bundle, not a Laravel package — there is no service provider, no facade, no config/front.php. As a Laravel developer your realistic options are (a) run a small Symfony app alongside your Laravel app that mounts this bundle, or (b) treat the repo as a reference implementation and lift the routing/template logic into Laravel. Decide this first; everything below assumes you have read the source.

Minimal steps to get oriented:

1. Open composer.json in the repo and check the require block — it tells you which Symfony and wizaplace/* API client versions you are pinned to (last release was Jan 2022, so expect Symfony 5.x-era constraints).
2. Read src/DependencyInjection/ and src/Resources/config/ — for a bundle this small, the extension class and its YAML/XML service definitions are the documentation. That is where config keys, service IDs, and route prefixes live.
3. Read src/Controller/ — a "front bundle" for a marketplace SaaS almost always means a controller that renders a front-end shell (SPA index.html or a Twig layout) and injects config (API base URL, locale, storefront ID) into it.
4. Check README.md and any docs/ folder for a config snippet; if it is thin (likely, given 2 stars), generate a skeleton Symfony app and register the bundle manually to see what breaks.

First use case: serve the storefront shell. Install via Composer into a Symfony host, add the bundle to config/bundles.php, publish/define the required config (typically API endpoint + storefront identifier), and hit the route the bundle exposes. That request → render cycle is the whole point of the package; get it working before chasing theming or SSR features.

Implementation Patterns

Host-app wrapper pattern (recommended for Laravel teams). Keep Laravel as your application and run this bundle inside a thin Symfony "front" service. Laravel owns auth, admin, and domain logic; the Symfony app owns nothing but the storefront render. Put both behind the same reverse proxy and route by path prefix. This is the lowest-friction way to consume a Symfony-only bundle from a Laravel codebase.

Config injection into the shell. The typical shape is a controller action that renders a template with a JSON blob of runtime config:

// conceptual — verify against src/Controller
return $this->render('@WizaplaceFront/index.html.twig', [
    'frontConfig' => [
        'apiBaseUrl' => $this->getParameter('wizaplace_front.api_base_url'),
        'locale'     => $request->getLocale(),
    ],
]);

Mirror those values from Laravel via an environment variable shared between the two apps (.env → container env) so you never hardcode endpoints in two places.

Template override instead of fork. Symfony resolves bundle templates from templates/bundles/<BundleName>/ in the host app first. Override the shell template there to add your analytics tags, CSP nonces, or asset versioning without touching vendor code. This is the single most valuable extension point and it costs you nothing on upgrade.

Service decoration for behavior changes. If you need to alter how the controller builds its config (e.g. add a currency, inject a feature flag), decorate the relevant service in config/services.yaml rather than editing the bundle. Look at the service definitions in Resources/config for the IDs to target.

Locale/currency middleware. Multi-storefront setups usually want the request locale to drive the front config. Wire a small Symfony EventSubscriber on kernel.request that sets the request locale from a header or path segment before the bundle's controller runs. Do not do this inside the bundle.

Laravel-side port pattern. If you choose option (b), the port is small: a route, a Blade view, and a config array. Recreate the shell template, move the config keys into config/front.php, and skip the bundle entirely. You lose future updates (there won't be many — see Gotchas) but gain full control and no second runtime.

Gotchas and Tips

This is not a Laravel package. The biggest trap is assuming composer require + a provider registration will work. It won't. Budget for either a second Symfony runtime or a port. Do not try to shoehorn a Symfony bundle into Laravel via a bridge package — for a 2-star bundle the bridge will cost more than the port.

Maintenance risk is real. Last release January 2022, 2 stars, 0 dependents. Treat this as effectively unmaintained. Pin the exact version, vendor the repo if you must, and assume you will own any bug fixes. Before committing, check the require constraints — an abandoned bundle pinned to Symfony 5 will block your Symfony 6 upgrade later.

Config caching bites first. Symfony compiles config into the cache, so a changed config key silently does nothing until you run bin/console cache:clear. When a config change "isn't taking effect," clear the cache before debugging anything else. In dev, check var/cache/dev/ for the compiled container to confirm your parameter actually landed.

Parameter naming is guesswork without docs. The bundle's extension class (in DependencyInjection/) defines the config tree — read it to learn the exact key names, defaults, and which are required. Guessing wizaplace_front.api_key when it's wizaplace_front.api.token is the most common first-hour waste. The Configuration.php ->children() block is your source of truth.

Routing prefix collisions. Bundles usually load routes with a prefix. Check Resources/config/routing.xml (or the extension) for the prefix and make sure it doesn't shadow your host app's routes. In the wrapper pattern, terminate the prefix at the proxy so the two apps never contend for the same path.

Debugging the render. Use the Symfony profiler's request/response panels to confirm the bundle's controller is actually the one handling the request (not a host-app catch-all). If the shell renders but is blank, the issue is almost always the injected config blob — inspect the rendered HTML source for the config object before suspecting the front-end.

Extension points to lean on: template overrides (templates/bundles/...), service decoration, and kernel event subscribers. Avoid forking src/ — with no upstream maintenance, a fork becomes permanent and invisible to future you.

Version-pin and isolate. Because the bundle is stale, run it in its own container/app with its own lockfile. Blast radius on a shared composer.json is not worth the convenience of co-locating it with your Laravel app.

Ask up front whether you need it at all. With 0 dependents and a 2022 release, the honest assessment is that the bundle's value is mostly as a reference for how Wizaplace expects a storefront shell to be wired (config keys, template structure, API handshake). Reading it and reimplementing in Laravel is often cheaper and safer than running it.