Parabol Doctrine Behaviors Bundle Laravel Package

Getting Started

Before writing any code, do the honest triage. This package has 0 stars, 0 dependents, and an unknown maintenance status, so treat it as unvetted third-party code rather than an established dependency. Open the repository and check three things first:

1. composer.json — PHP and doctrine/orm version constraints, plus whether it targets Symfony 5/6/7.
2. src/ — which behaviors actually ship (timestampable, blameable, soft-deletable, sluggable, etc.) and whether they're trait-based or listener/attribute-based.
3. Resources/config/ (or config/) and the bundle's DependencyInjection/…Extension.php — confirms the config alias and how services are wired.

Framework reality check: despite the Laravel framing, this is a Symfony bundle, not a Laravel package. If you're in Laravel you are off the happy path: you need Doctrine installed (doctrine/orm or laravel-doctrine/orm) and the bundle's service/event subscribers registered manually, because Symfony bundles don't auto-discover in Laravel. Budget for that glue.

Install into a Symfony app:

composer require parabol/parabol-doctrine-behaviors-bundle

Then register in config/bundles.php and create config/packages/<alias>.yaml (verify the alias from the Extension class — see Gotchas). Pin an exact version and commit composer.lock; assume no maintainer will respond.

First use case: adopt one behavior on one entity — Timestampable (createdAt/updatedAt). It's the smallest surface area, trivially testable, and confirms the bundle's wiring, config alias, and event subscribers all work before you trust it with soft-deletes or slug generation. Write a single test that persists an entity and asserts the timestamps populate, then expand.

Implementation Patterns

• Pick one mapping style and stay consistent. These bundles typically support PHP attributes/annotations, YAML, or XML. Mixed styles produce silent no-ops where a listener doesn't find its metadata.
• Trait-per-behavior vs. listener-per-behavior. Trait-based (Knp-style) is more readable in the entity; listener/attribute-based (Gedmo-style) is easier to toggle per-model. Prefer traits unless you need conditional behavior.
• Blameable needs an identity source. In Symfony, wire security.token_storage; in Laravel, provide a user resolver bound to the auth guard. The bundle's listener usually reads from a specific interface — implement it on your User entity.
• Soft delete requires query awareness. Enable the Doctrine filter (e.g. $em->getFilters()->enable(...)) or use scoped repositories consistently. Put this in a base repository, not scattered across controllers.
• Sluggable + unique constraint: generate on flush, but keep a unique DB index and handle collisions. Prefer a strategy that appends suffixes rather than throwing on duplicate.
• Migrations: behaviors change schema (nullable columns, indexes). Run doctrine:schema:validate and diff schema in CI before deploying — don't let behavior-generated columns surprise a production migration.
• Day-to-day workflow: add trait → doctrine:schema:validate → persist-and-assert feature test → only then touch the entity's existing tests. This catches listener-registration failures immediately.

Gotchas and Tips

• The Symfony/Laravel mismatch is the #1 pitfall. The bundle assumes Symfony's container and event dispatcher. In Laravel you'll likely get "service not found" or listeners never firing. If you're on Laravel, seriously consider the better-supported gedmo/doctrine-extensions (with standalone listener config) or stof/doctrine-extensions-bundle for Symfony instead of adopting an unmaintained fork.
• Zero dependents = zero community signal. Audit the event subscribers for hardcoded new \DateTime() (timezone bugs and untestable code), unbounded loops in onFlush, and any behavior that mutates other entities.
• Config alias silent failure. If your config/packages/*.yaml uses the wrong root key, the config is ignored without error. Confirm the alias against the Extension class and check services load via debug:container.
• Double-updating timestamps. Manually calling setUpdatedAt() alongside an automatic timestamp listener produces confusing values and extra UPDATE statements. Choose one owner.
• Soft-delete leaks. Forgetting to enable the filter returns deleted rows in admin/report queries — a security-adjacent bug. Centralize filter activation.
• Blameable is null in CLI/queue/seeders. No token = no user. Decide explicitly whether that's allowed (nullable column) or throws.
• Bulk operations bypass listeners. DQL UPDATE/DELETE and raw DBAL skip prePersist/onFlush entirely — no timestamps, no slugs, no soft-delete. Handle bulk paths manually.
• Debugging: enable Doctrine SQL logging and watch for extra UPDATEs on flush (listeners recomputing). Use doctrine:schema:validate in CI; use debug:event-dispatcher to confirm subscribers register.
• Extension point: if a behavior you need is missing, write your own EventSubscriber on prePersist/onFlush rather than forking — you keep upgrade freedom and avoid inheriting an unmaintained branch.