User Bundle Laravel Package

Getting Started

plumtreesystems/user-bundle is a Symfony bundle, not a Laravel package — worth stating up front, because the naming and Packagist listing invite the wrong assumption. If you're on Laravel, stop here; there is no service provider, no facade, no Laravel integration.

For a Symfony app:

1. Install and register.

   composer require plumtreesystems/user-bundle
   

   Then add it to config/bundles.php (or app/AppKernel.php on older skeletons):

   PlumTreeSystems\UserBundle\PlumTreeSystemsUserBundle::class => ['all' => true],
   

2. Read the bundle's own source before the README. With zero stars and a last release from March 2020, the README is likely thin and possibly out of sync with the code. The authoritative sources are DependencyInjection/Configuration.php (the full config tree with defaults), Resources/config/ (service definitions and any routing/Doctrine mappings), and the Entity/ or Model/ directory (what the base user class actually looks like).

3. Check version compatibility first. The 2020 release date means the bundle was almost certainly built against Symfony 3.4/4.x. Confirm the composer.json constraints against your Symfony version before you invest time — a Symfony 5/6/7 app will likely need composer conflict overrides or a fork.

4. First use case: wire up the user entity and security provider. The typical first step is extending the bundle's abstract user class (or mapping your own User entity to the bundle's expected interface), running bin/console doctrine:schema:update --dump-sql to see what the bundle expects, and pointing security.yaml's providers at your entity. Get login working end-to-end against a single hard-coded user before touching registration.

5. Verify the bundle actually boots with bin/console debug:container | grep -i plum and bin/console debug:router. If nothing shows up, the bundle registration silently failed or the config tree rejected your YAML.

Implementation Patterns

Extend the base model rather than the shipped entity. Bundles of this vintage usually provide an abstract User model with Doctrine XML/YAML mapping, expecting you to subclass it in your src/Entity. Subclass with @ORM\Entity and, if you need extra columns, use single-table inheritance or attribute overrides. Keep the bundle entity untouched so upgrades (such as they are) don't conflict.

Configure via the bundle's config tree, not by editing vendor code. Typical shape:

# config/packages/plum_tree_systems_user.yaml
plum_tree_systems_user:
    user_class: App\Entity\User
    # plus whatever Configuration.php actually exposes

Read Configuration.php to get the real keys — don't guess from blog posts.

Wire authentication through native Symfony security. This bundle predates Symfony's UserInterface modernization (the getUsername()/getSalt()/eraseCredentials() removal in 5.3). Expect its base class to implement the old interface. If you're on Symfony 5.3+, plan to either override those methods in your subclass or accept deprecation notices.

# config/packages/security.yaml
security:
    providers:
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email
    firewalls:
        main:
            provider: app_user_provider
            form_login:
                login_path: app_login
                check_path: app_login

Use the bundle for its model + repository, roll your own controllers. Registration and login controllers from a 2020 bundle will feel dated (no rate limiting, no CSRF hardening beyond defaults, no email verification flow worth the name). Treat the bundle as a persistence layer and write your own RegistrationController / SecurityController against its repository. This is the lowest-friction integration path and keeps you in control of UX.

Import routes only if you want the stock forms. If the bundle ships Resources/config/routing.xml, import it with a prefix and then override templates by placing copies in templates/bundles/PlumTreeSystemsUserBundle/. Symfony's bundle template override resolution works here as usual, and it's faster than fighting the vendor templates.

Service decoration is your extension point. Rather than forking, decorate whatever services the bundle registers (e.g. a user manager or mailer) via services.yaml:

App\Service\DecoratingUserManager:
    decorates: plum_tree_systems_user.manager
    arguments: ['@App\Service\DecoratingUserManager.inner']

Confirm the service ID from bin/console debug:container first — IDs from this era are often dot-notation with the bundle alias, not FQCNs.

Test with a fixture user, not the registration flow. Get security:hash-generator output into a Doctrine fixture and log in. Registration flows in stale bundles are the most likely place to hit an unmaintained dependency (Swiftmailer, deprecated form types, getSalt() returning null).

Gotchas and Tips

The maintenance signal is the headline risk. Zero stars, zero dependents, last release March 2020, MIT. That combination means: no security patches, no Symfony 6/7 support, and effectively no community to answer questions. Treat it as code you are adopting, not a dependency you are consuming — budget for reading the source and potentially maintaining a fork. For anything user-facing or auth-adjacent, prefer symfony/security-bundle plus symfony/maker-bundle's generated user, or a maintained alternative like FriendsOfSymfony/UserBundle if you specifically need a bundle.

Composer will not warn you about incompatibility at install time in many cases, because 2020-era constraints often allow broad ranges ("symfony/framework-bundle": "^3.4|^4.0"). You may install cleanly and then fail at container compile with a cryptic ServiceNotFoundException or a signature mismatch on UserInterface. Run bin/console cache:clear immediately after install — it surfaces these errors early.

Deprecation noise will be heavy. Expect getUsername(), getSalt(), eraseCredentials() deprecations on Symfony 5.3+, plus Swiftmailer deprecations if the bundle sends mail. Set SYMFONY_DEPRECATIONS_HELPER=max[self]=0 in phpunit.xml.dist so bundle-internal deprecations don't drown out your own.

Config key naming is inconsistent across bundles of this era. The bundle alias might be plum_tree_systems_user, plumtree_user, or pts_user. Confirm with:

bin/console config:dump-reference plum_tree_systems_user

If that command errors, try the alternatives rather than assuming the bundle failed to register.

Doctrine mapping conflicts are the most common breakage. If the bundle ships mapping in Resources/config/doctrine/ and you also define mapping on your subclass, you'll get "table already exists" or duplicate-column errors. The fix is usually to extend the model (unmapped) rather than the entity (mapped). Check whether the base class lives under Entity/ or Model/ — the distinction matters.

No getSalt() return value is a silent security footgun. Old base classes often return null from getSalt(), which is fine with modern password_hash-based encoders but will silently weaken things if you configure a legacy encoder. Audit security.yaml's encoders/password_hashers block and use auto.

Debugging checklist when something is off:

bin/console debug:container --tag=doctrine.orm.entity_manager   # confirm mappings load
bin/console doctrine:mapping:info                               # spot conflicting entities
bin/console debug:event-dispatcher | grep -i user               # bundle hooks, if any
bin/console lint:container                                      # catch arg-type mismatches

If you decide to fork, the cheapest path is to vendor the bundle into src/ as a first-party namespace, strip the DependencyInjection extension and Bundle class, and register the services in your own services.yaml. You lose nothing (there's no upstream to track) and gain full visibility into the auth path — which is exactly where you want visibility.