- Is rmzamora/user-bundle a Laravel package?
- No. It is a fork of SonataUserBundle, a Symfony bundle built for the Symfony and Sonata ecosystem. It does not integrate with Laravel's service container, Eloquent, Artisan, or Blade, so it is not a Laravel package despite the repository name. Laravel teams should treat it as out of scope.
- Can I install rmzamora/user-bundle in a Laravel application?
- You should not. The package targets Symfony's bundle system and depends on FOSUserBundle and SonataAdminBundle, none of which are compatible with Laravel. Composer may resolve it, but there is no supported way to wire it into a Laravel app. Use Laravel's native authentication scaffolding or a maintained Laravel user package instead.
- Which Symfony versions does this SonataUserBundle fork support?
- The fork inherits SonataUserBundle's legacy dependencies, which were built around the Symfony 2.x through 4.x era. No maintained composer.json constraints against modern Symfony or PHP versions are evidenced. Modern Symfony 5.4, 6, and 7 applications should not expect it to resolve cleanly. Check the fork's composer.json and run composer why-not before considering it.
- Is rmzamora/user-bundle still maintained?
- No. The repository is archived, has zero stars and no dependents, and shows no tagged release history of its own. It is a single-author fork with no visible upgrade cadence or maintainer succession plan. Treat it as abandoned for planning purposes.
- What dependencies does rmzamora/user-bundle require?
- It carries the SonataUserBundle dependency chain, including friendsofsymfony/user-bundle and sonata-project/admin-bundle plus related Sonata packages. Each of those has its own compatibility ladder and its own maintenance status. FOSUserBundle is deprecated upstream in favor of Symfony's native security features. That transitive stack is the main reason modern Composer resolution is likely to fail.
- Is rmzamora/user-bundle safe to use for authentication in production?
- No. It is an unmaintained user and authentication bundle with no path to CVE patches for the pinned FOSUserBundle and SonataAdminBundle versions. Authentication, password handling, and role management are security-sensitive surfaces that should not depend on an archived personal fork. Use maintained first-party primitives instead.
- How does rmzamora/user-bundle differ from SonataUserBundle upstream?
- The repository describes itself as a fork from Sonata Project, but the exact upstream commit and diff are not documented in the available information. The fork has no tagged release history of its own and no downstream adoption signals. Before any use, diff it against the maintained sonata-project/user-bundle and confirm the pinned upstream version and license.
- Does rmzamora/user-bundle work with PHP 8.1 or Symfony 6 and 7?
- That is not evidenced. The package descends from a Symfony 2.x to 4.x lineage with FOSUserBundle and SonataAdminBundle dependencies, which typically carry PHP 7.x era constraints. PHP 8.1+ and Symfony 5.4, 6, or 7 compatibility would need to be proven with a clean composer update and a working test suite. There are no signs that this fork has been updated for those versions.
- What should I use instead of rmzamora/user-bundle for user management?
- For Symfony, use native security with security.yaml, make:user, PasswordHasher, and UserProvider, or the maintained sonata-project/user-bundle if you specifically need Sonata user features on a supported Symfony version. For Laravel, use Laravel's built-in authentication scaffolding or a maintained Laravel user package. The right move is to remove any dependency on this fork and build on maintained first-party primitives.
- How do I migrate away from rmzamora/user-bundle?
- There is no migration target within this fork's lineage, so migrate away from it. Identify which features you actually use, such as user entities, roles, or admin screens, then re-implement them against Symfony native security or Laravel's auth system as appropriate. For legacy Symfony 3.x or 4.x applications, stabilize and freeze the current dependency set before planning an upgrade path. Do not introduce the fork into new code.