White Label Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package. Before anything else, confirm you're actually on a Symfony 2.x codebase — if you're in Laravel, stop here and read the "Gotchas" section, because you cannot composer require this into a Laravel app due to its symfony/symfony version constraints.

Assuming Symfony 2.x:

1. Require it (likely dev-master or a 2.x tag — check Packagist, the repo is low-traffic):

   composer require simonoche/white-label-bundle
   

2. Register the bundle in app/AppKernel.php:

   new Simonoche\WhiteLabelBundle\SimonocheWhiteLabelBundle(),
   

3. Look first at DependencyInjection/Configuration.php and DependencyInjection/*Extension.php. The README will be sparse; the config tree is the source of truth for available keys (brand name, logo, color, etc.).
4. Add a minimal config block in app/config/config.yml (the root key is almost certainly simonoche_white_label — verify against Configuration.php).
5. First use case: render the brand name and logo in your base Twig layout via the bundle's Twig extension/global, so a single config change rebrands every page:

   <img src="{{ white_label.logo }}" alt="{{ white_label.name }}">
   

Implementation Patterns

• Centralize branding in config, not templates. Put brand name, logo path, primary color, support email, and footer text in parameters.yml (or an environment-specific config_<env>.yml), then reference them through the bundle's Twig helpers rather than hardcoding in base.html.twig.
• Environment-specific branding. Use config_dev.yml / config_prod.yml overrides to show a "DEV" badge or alternate logo in non-prod, without touching templates.
• Runtime/service-level access. Inject the bundle's service (check Resources/config/services.yml for the service ID) into controllers or your own services when you need the brand values outside Twig — e.g., generating emails, PDF invoices, or API responses.
• Multi-tenant / per-domain branding. The common real-world pattern is a kernel.request listener that inspects $request->getHost() and swaps the active brand config (or sets a brand identifier in the request). This bundle likely only exposes static config, so you'd wrap it: a BrandResolver service that reads the bundle's config as a default and overrides per-host.
• Override templates, don't fork. If the bundle ships any default Twig views, override them in app/Resources/SimonocheWhiteLabelBundle/views/ using standard Symfony bundle inheritance.
• Porting the idea to Laravel. If you're a Laravel dev evaluating this for a Laravel project, don't install it — replicate the pattern with config/white-label.php, a Brand service bound as a singleton, and a View::composer('*', ...) to expose $brand to all views. That's a 30-minute port and avoids dragging in Symfony 2.

Gotchas and Tips

• Dead Symfony2 dependency. This will not install on Symfony 3+, Symfony 4/5/6/7, or PHP 8. If your composer.json requires a modern symfony/*, resolution will fail or force ancient versions. Pin only in a legacy app.
• Zero Laravel compatibility. No service provider, no facade, no config publishing. Any "Laravel usage" is a conceptual port, not an install.
• Config keys are undocumented. Always run bin/console config:dump-reference simonoche_white_label (Symfony 2.6+) or read Configuration.php; guessing key names from the README wastes time.
• Twig extension may not be auto-wired. On older Symfony2 versions, confirm the Twig extension is tagged twig.extension in Resources/config/services.yml. If brand variables render empty, this is usually why.
• Asset paths. Logo config values are typically raw strings passed through asset(). Store them relative to web/ (e.g., bundles/app/img/logo.png), not as absolute filesystem paths.
• Cache. After editing branding config, run bin/console cache:clear --env=prod — Symfony2 config is compiled into the container, so stale values are a frequent "bug."
• Extension point for custom fields. If you need extra brand attributes (e.g., a secondary color or social links), subclass the bundle's config extension or add a compiler pass that merges your own parameters into the same namespace, rather than editing vendor files.
• Vendor lock risk. With effectively no maintenance, treat any use as a fork: copy the bundle into src/ (or a private repo) so you control fixes, and audit it for anything referencing deprecated Symfony APIs before upgrading PHP.
• Debugging tip. Dump the resolved container parameters ($container->getParameterBag()->all()) in a test kernel to see exactly what the bundle registered — faster than tracing the extension by hand.