Doctrine Extensions Bundle Laravel Package

Product Decisions This Supports

• Feature delivery shortcuts for commodity data-model behavior. The bundle is thin Symfony configuration glue for FSI's Doctrine extensions (a Gedmo-derived family), so it directly enables features teams repeatedly rebuild: audit trails (Loggable/Blameable), soft deletes (SoftDeleteable), created/updated timestamps (Timestampable), URL slugs (Sluggable), hierarchical content (Tree/NestedSet), and per-locale content (Translatable).
• Build vs. buy on configuration, not architecture. The underlying behavior is commodity; what you're "buying" is ~dozens of lines of service/listener wiring. The real decision is which config layer to standardize on — this bundle, the de facto community standard (stof/doctrine-extensions-bundle), or a small in-house bundle — not whether to adopt Doctrine extensions.
• Roadmap input for CMS/admin-style backends. If the roadmap includes content management, audit/compliance logging, or soft-delete-based recovery, this is a legitimate accelerator for an existing Symfony + Doctrine ORM stack. It is not a strategic bet and shouldn't anchor a platform decision.
• Ecosystem-fit signal. Low adoption (3 stars, 0 dependents) and no release since July 2021 make this a signal about the surrounding ecosystem more than a product choice: if the org is already inside the FSI Open stack or inheriting a codebase that depends on it, this is a compatibility/migration decision rather than a greenfield selection.

When to Consider This Package

Consider it when:

• You are on an older Symfony (3/4/5-era) + Doctrine ORM application and need Gedmo-style extensions auto-configured without manually registering Doctrine event subscribers.
• You are maintaining or migrating a codebase already built on FSI Open packages, where switching config layers adds risk without user-visible benefit.
• The scope is one or two extensions and you want a minimal config surface, and you can accept pinning a specific version.

Look elsewhere when:

• You are starting greenfield on Symfony 6/7 — verify PHP/Symfony constraints first; a 2021 last release is a strong hint of stale compatibility and unpatched behavior.
• You need active maintenance, security response, or community support — stof/doctrine-extensions-bundle is the safer default, and even Gedmo itself warrants a maintenance check.
• The need is a single behavior (e.g., timestamps or soft delete) — Doctrine lifecycle callbacks or a small custom subscriber will often be less total risk than an unmaintained dependency.
• Procurement or platform standards require a minimum adoption/maintenance bar (stars, dependents, release cadence); this package fails those gates.

How to Pitch It (Stakeholders)

To executives: A low-cost MIT-licensed Symfony bundle that speeds up common data-model features — audit logs, soft deletes, timestamps, slugs, translations — by configuring existing Doctrine extensions instead of writing custom code. The trade-off is maintenance risk: negligible community adoption (3 stars, zero dependents) and no release since July 2021. Position it as a tactical accelerator with a documented fallback, not a long-term platform commitment.

To engineering: It's a thin container-configuration layer over FSI's Gedmo-derived Doctrine extensions, wiring listeners such as SoftDeleteable, Timestampable, Sluggable, and Loggable. Benefits are reduced boilerplate and consistency across entities. Before adoption: confirm Symfony/PHP version compatibility, pin the dependency, wrap usage behind our own interfaces so we can swap to stof/doctrine-extensions-bundle or Doctrine-native patterns, and validate the extension set we actually need rather than pulling the whole family.