User Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony 2 bundle, not a Laravel package. There is no composer.json service provider, no facade, no artisan command, and nothing here will autoload into a Laravel app without essentially re-implementing it. If you are evaluating this from a Laravel codebase, the correct first step is to treat it as reference material, not a dependency.

For a Symfony 2.x project that is already running Symfony2Admingenerator and FOSUserBundle:

1. Look at composer.json and README.md first. The project now publishes a 2.0 beta line (latest: 2.0.0-beta.6, contents: minor translation updates). That does not make it stable — it is still a pre-release — but it does mean you can pin a tag (2.0.0-beta.6) instead of a raw commit hash. Pin explicitly either way and record it in your own composer.lock; do not use a floating dev-master or ^2.0@beta.
2. Check the Resources/config/ directory. This is where the bundle ships its admin generator YAML (the generator.yml/*.yml module definitions) and form type configuration. This is effectively the documentation — there is very little else.
3. Confirm your versions match. It targets Symfony 2.3–2.6 era, FOSUserBundle ~1.3, and Symfony2Admingenerator 1.x. Modern FOSUserBundle (2.x) renamed namespaces and dropped the base User model layout this bundle configures. Verify the shipped YAML against the 2.0 branch specifically — the tag you pin may not match the 1.x-era tree this assessment describes.
4. Register the bundle in app/AppKernel.php alongside FOSUserBundle and Symfony2AdmingeneratorBundle (or the specific generator-bundle variant you use).
5. First use case: generate the admin CRUD module for the FOSUserBundle:User entity so you get list/filter/form/new/show screens for users (and optionally Group) in the admin backend without hand-writing the generator config. Run the generator command (php app/console admin:generate-admin ..., exact name depends on your Admingenerator version) after the bundle's config is picked up.

If you are on a modern Symfony or on Laravel, the realistic starting point is: do not install it. Read the generator YAML to see what a FOSUserBundle-integrated admin module looks like, then reproduce that config yourself.

Implementation Patterns

The day-to-day workflow is entirely driven by the admin generator's YAML, so usage patterns centre on configuration overrides rather than code.

Baseline CRUD generation. Point the generator at the FOSUserBundle user model (or your concrete subclass) and let this bundle supply the default fields, filters, and form panels. Typical generated module: username, email, enabled, lastLogin, roles, groups, timestamps.

Subclass the user entity first. The standard pattern is to extend FOS\UserBundle\Model\User into AppBundle\Entity\User, then point the admin generator at your class, not the bundle model. This bundle's defaults assume you have done this; the generator will not work correctly against the mapped superclass.

Override the form type. Do not let the generated admin form edit password directly — the generated form exposes a plain text field that will write an unhashed string into the column. Standard approach: in your generator form config, exclude password and salt, and either provide a custom UserType that delegates to FOSUserBundle's ChangePassword flow or use the generator's form_options.fields to swap in a password-reset field.

Role and group editing. The generator config ships with roles and groups handling — roles usually as a choice/multi-select and groups as a Doctrine association widget. In practice you will override the groups field to use a entity form type with the group class explicitly named, because the shipped default relies on the bundle's naming assumptions.

Extend, don't edit. Copy the bundle's YAML into your application's generator config under the same module name. The bundle's files live under vendor/ and will be wiped on the next composer update; anything you actually rely on should be forked into app/config/ or your own bundle.

Pair it with FOSUserBundle's own tooling. User registration/enabling still belongs to FOSUserBundle forms and controllers. Keep the admin module for administrative actions (toggle enabled, adjust roles, unlock accounts) and leave the self-service password/profile flows to FOSUserBundle — do not try to route registration through the generated admin form.

Use the generator's object actions for lifecycle events. "Enable", "Disable", "Lock", "Unlock" are best expressed as generator object actions that call FOSUserBundle's manager (fos_user.user_manager) rather than direct entity field edits, so the canonical fields and any events stay consistent.

Translations are the only thing being touched upstream. The 2.0-beta series ships translation catalogue updates only — useful if your admin UI must be localised, but it means the labels for the generated user module are now sourced from Resources/translations/. Override any string you care about in your app's translation domain rather than editing vendor files, and check your locale actually exists before assuming a missing label is a config bug.

Gotchas and Tips

• The bundle is effectively unmaintained. Two stars, zero dependents, and the only recent activity is a 2.0 beta series whose sole content is translation string changes — no functional work, no Symfony version bump, no test coverage added. Treat every piece of it as untested against anything you'd run today. Assume you are the maintainer if you adopt it.
• Password hash exposure is the big one. The admin list view will happily render the password column, and the default form will let an admin type a raw password that gets persisted unhashed. Explicitly remove password and salt from the list/grid config, and route all password changes through FOSUserBundle's UserManager::updateCanonicalFields/updatePassword path.
• Version pinning is mandatory. Pin 2.0.0-beta.6 (or the exact commit behind it). A beta tag is not a stability guarantee and the 2.0 line is not API-frozen — there is no stable tag to fall back to. Be prepared to fork into a local path repository or private mirror, because the upstream repo may disappear and your composer.lock alone won't save you.
• Tag vs. branch drift. You are now reading release notes from the 2.0 line while almost all community knowledge and the bundle's own 2015-era YAML examples come from 1.x. Diff the tagged tree against whatever documentation you find before copying config; field names and bundle keys may not line up.
• Namespace and bundle-name drift. Symfony2Admingenerator itself changed bundle names (Symfony2AdmingeneratorGeneratorBundle vs. AdmingeneratorGeneratorBundle vs. AdmingeneratorDoctrineOrmBundle) across versions. The YAML in this bundle references specific bundle keys — if your generator bundle is named differently, the config silently won't be picked up and you'll see the generator's generic defaults instead of user-specific fields.
• YAML config errors are silent. The generator ignores unknown keys rather than throwing. If your fields don't appear, dump the resolved generator config before assuming the YAML is wrong.
• Twig template overrides. This bundle ships templates for the user module. Because they were written for Symfony 2.3-era Twig, {% spaceless %} and older trans filter signatures may break on later Twig — and the recent translation-only releases mean the trans keys changed without any accompanying template audit. Override the templates in your app rather than patching the vendor copy.
• PHP compatibility ceiling. The code is PHP 5.4/5.5-era. Running it on PHP 7.2+ will at best work with deprecation noise and at worst fail on removed syntax. PHP 8 is not viable without a fork.
• No tests, no CI, no support. There is nothing to run and nothing to read beyond the source. Debugging means dump()-ing the generator output and reading the FOSUserBundle source for the model contract.
• The one legitimate use is as a reference. The generator YAML here is a reasonably complete example of wiring a FOSUserBundle entity into an admin generator. If you're building the equivalent in Laravel — say, a Filament or Nova resource for a user model — the field lists, role/group widgets, and the "exclude password, add unlock/enable actions" pattern transfer conceptually even though the code does not.