Cms User Bundle Laravel Package

Getting Started

Before anything else: confirm what you're actually installing. presta/cms-user-bundle is not a Laravel package — it's a Symfony 2.x bundle built on top of FOSUserBundle and PrestaCMS CoreBundle, last tagged in February 2014 and now archived. composer require presta/cms-user-bundle inside a Laravel 9+/10/11 app will not resolve cleanly; you'll drag in symfony/framework-bundle constraints from the PHP 5.4/5.5 era and Composer will abort on platform requirements.

If you still need to evaluate it (e.g. you're auditing a legacy PrestaCMS install):

1. Read the repo README.md first — it is short and assumes you already run PrestaCMS. There is no Laravel-style "publish the config" step.
2. Check composer.json for the actual Symfony constraint (typically ~2.3), FOSUserBundle version, and PHP floor. This is the real gate on whether it installs at all.
3. In a Symfony 2.3+ app: register PrestaCMSUserBundle in app/AppKernel.php after FOSUserBundle and PrestaCMSCoreBundle, then import its routing.
4. First real use case: it gives you a front user layer (site visitors who register/log in on the public site) separate from the admin PrestaCMS users — registration, login, profile editing, and admin screens to list/manage those front users.

For a Laravel team: treat this as a reference implementation, not a dependency. The concepts (a separate front firewall, a user provider, registration/profile controllers, role hierarchy) all have direct Laravel equivalents — read the bundle's Resources/config/ and controllers, then build the equivalent with Auth, Gate, and a plain Eloquent User model.

Implementation Patterns

If you are on the (legacy) Symfony side, the typical wiring looks like:

• Bundle registration order matters. FOSUserBundle → PrestaCMSCoreBundle → PrestaCMSUserBundle, and the security.yml firewalls list must define a front firewall that points at the bundle's user provider, kept distinct from the admin firewall.
• Entity inheritance. The bundle expects your app to subclass its base user class (Doctrine MappedSuperclass pattern) so you can add fields. In Laravel terms: don't modify the vendor model — extend it via a subclass and let migrations run against your subclass.
• Routing import. presta_cms_user: in app/config/routing.yml pulls in all public-facing routes (register, login, profile, password reset). You override individual templates under app/Resources/PrestaCMSUserBundle/views/ rather than editing the bundle.
• Admin listing. The bundle ships an admin controller/grid for front users — useful as a pattern for "moderator manages site members" flows.

Translating to a Laravel workflow (the part you'll actually use day-to-day):

• Mirror the front vs admin split with two guards in config/auth.php. The bundle exists because mixing CMS editors and site visitors in one user table is painful; keep that separation in any Laravel port.
• The bundle's registration flow is a form type → validator → persist → event. In Laravel: FormRequest → validation → User::create() → fire a Registered event. Same shape.
• Profile editing is a classic "authorize then update own record" pattern — $this->authorize('update', $user) with a policy is the Laravel equivalent of the bundle's voter check.
• Email confirmation / password reset: the bundle leans on FOSUserBundle's token table. In Laravel, use the built-in password_resets / email_verification tokens rather than re-implementing.

Gotchas and Tips

• Archived = unpatched. No security fixes since 2014. Do not deploy this in any environment reachable from the internet without a full audit; it predates modern Symfony security hardening.
• PHP/Symfony version lock. Symfony 2.3-era bundles fail on PHP 8 (deprecated each(), create_function, dynamic properties, missing return types). Running it on a modern stack is not a config problem — it's a rewrite.
• FOSUserBundle version conflicts. The bundle's composer.json pins an old FOSUserBundle range. If any other dependency wants a newer FOSUserBundle, resolution fails or, worse, silently installs a mismatch that breaks at runtime in UserManager.
• Security config is easy to misconfigure. The bundle assumes a front firewall exists. Forgetting it, or naming it differently, produces confusing "no user provider" errors at login rather than at boot.
• Doctrine mapping errors are the #1 debugging pain. Duplicate column mappings between your subclass and the MappedSuperclass base show up as ORMException at schema-tool time, not at request time — always run doctrine:schema:validate after adding fields.
• Debugging: use the Symfony profiler's Security panel to see which firewall handled a request and which provider resolved the user; this bundle's front/admin split makes it very easy to be on the wrong one.
• Templates: override via app/Resources/PrestaCMSUserBundle/views/, not by forking the bundle — forks make future (hypothetical) upgrades impossible and hide your changes.
• Extension points worth borrowing even in Laravel:
  • A dedicated user provider abstraction (so you can later add OAuth without touching controllers).
  • Events fired around registration/profile update (hook points for emails, analytics).
  • A voter/policy-style authorization check for "can this user edit this profile".

Bottom line for a Laravel developer: this is a historical Symfony bundle, archived and effectively unmaintained. There is no day-to-day Laravel use case — you cannot meaningfully install or leverage it in a Laravel app today. The value is architectural: it's a clean, small reference for separating front-end site users from admin users, which translates neatly into two Laravel guards and a User/Admin model split. If you need this functionality in Laravel, build it natively (laravel/breeze or laravel/jetstream plus a policy-gated profile) rather than trying to bridge Symfony 2 code.