Doctrine Extensions Laravel Package

Product Decisions This Supports

• Audit trail & compliance features — build vs. buy. Loggable, Blameable, Timestampable, and IpTraceable cover the "who changed what, when, from where" pattern that shows up in nearly every enterprise/regulated roadmap item (SOC 2 evidence, GDPR data-change records, finance/ops audit logs). In-house versions of this are deceptively expensive: change-set diffing, version numbering, revert-to-version UX, and relation handling. This package makes it a configuration decision rather than a 3–6 sprint project.
• Soft delete and data retention policy. SoftDeleteable (ORM only) underpins "undelete," recycle-bin, and retention/right-to-be-forgotten flows without hand-rolled deleted_at filters leaking into every query. Directly informs whether you can promise customers reversible deletion in a contract.
• Internationalization / multi-language rollout. Translatable is the strongest strategic lever here: it lets you commit to a per-locale content model (translation tables managed by the ORM) with fallback behavior, informing whether localization is a Q3 or Q4 roadmap item and whether it's "content translation" (product-owned) or "UI strings" (separate i18n stack).
• Taxonomy, catalog, and org-hierarchy features. Tree (closure, nested set, materialized path) is the engine for category trees, nested catalogs, comment threads, org charts, and nav menus. This is the decision point for "do we ship a hierarchy UI?" — nested set gives cheap subtree reads; materialized path gives cheap moves. That's a product trade-off (read-heavy nav vs. editor-heavy reorg) expressed as a config choice.
• Content/CMS and merchandising primitives. Sluggable (SEO URLs, deterministic and unique), Sortable (drag-and-drop ordering for merchandising or manual curation), and Uploadable (file fields on entities) are the standard "we need a CMS" checklist — each is a feature you can schedule with confidence rather than estimate.
• Architecture decision: Doctrine vs. Eloquent in a Laravel shop. The package only pays off if the team is running Doctrine ORM under Laravel (or Laminas/Symfony). Its value is largely in not rebuilding behaviors, so it's a forcing function on the stack question: if you standardize on Eloquent, this package is off the table and equivalent scope shifts to a different set of packages.
• Roadmap sequencing. Because behaviors attach at the Doctrine event layer, they compose: introduce Timestampable/Blameable first (cheap, invisible), then SoftDeleteable, then Translatable/Tree when the content features land. That ordering lets you ship audit + retention early and defer the heavier content model.

When to Consider This Package

Consider it when:

• The application already uses Doctrine ORM (directly, or via laravel-doctrine/orm / Symfony / Laminas). Retrofitting Doctrine just for these behaviors is not a justified product decision.
• You need several of these behaviors at once. Adopting it for one tiny need (e.g., a single slug) is fine but the ROI is in the bundle — audit + soft delete + slugs + timestamps is where it pays.
• You want schema-adjacent conventions to be declarative (attributes/XML on entities) so behavior is visible at the model layer, reviewable in code review, and testable — rather than scattered observer/service logic.
• Compliance or enterprise sales is on the roadmap and audit logging needs to be credible and consistent, not per-team.
• You need a mature, MIT-licensed, widely used OSS dependency rather than a bespoke internal trait library. Maturity signals are present: 4.1k stars, docs per extension, changelog, releases, CI/QA/coding-standard badges, and an active 3.0 line (PHP 8 attributes era, modern Doctrine/DBAL). Release cadence (recent tagged releases) supports "safe to depend on."

Look elsewhere when:

• You are an Eloquent-first Laravel team. Eloquent already ships timestamps and SoftDeletes; slugs, translations, sorting, and nested sets have first-class Laravel ecosystem equivalents. Adding Doctrine to a healthy Eloquent codebase to gain these behaviors is a net-negative product decision.
• You need only one behavior and it's trivial (a timestamp, one slug). The integration surface (event subscribers, mapping drivers, config) outweighs the benefit.
• You're on DBAL 4 with Loggable on the roadmap. Compatibility excludes Loggable on DBAL ^4.0. If audit logging is the reason you're here, that's a blocker to sequence around.
• You're annotation-heavy and not ready to migrate. Annotations are deprecated and slated for removal in 4.0; PHP 8 users should be on attributes. Budget the migration explicitly, or defer adoption until you're attribute-ready.
• You need first-class Laravel integration, Artisan tooling, and package-provided migrations. This is framework-agnostic Doctrine tooling; Laravel docs exist but it won't feel native.
• Your audit requirement is event-stream/app-level (Kafka-style change feed, cross-service lineage). Loggable records entity version history inside the ORM — good for admin "history" tabs, insufficient as a system of record for a distributed ledger requirement.
• You need ODM↔ORM cross-references (References, ReferenceIntegrity). These are MongoDB-ODM-specific and niche; only relevant if you're deliberately running a mixed-persistence stack — a heavy architectural commitment for a product team.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship audit history, soft delete/recovery, SEO-friendly URLs, multi-language content, category hierarchies, and manual ordering — the features that most often gate enterprise deals and content launches — on top of a mature, free (MIT), widely adopted open-source component instead of building each one. That converts several multi-sprint custom builds into configuration plus review, reduces maintenance burden and bug surface, and keeps our compliance story (who changed what, when, from where) consistent across the product. The main condition: this pays off only if we're on Doctrine ORM; if we standardize on Eloquent, we get equivalent capability from Laravel-native packages and should not adopt this.

For engineering leads: It's gedmo/doctrine-extensions — Doctrine event-subscriber behaviors declared via PHP 8 attributes (annotations deprecated, removal in 4.0). Mature 3.x line: docs per extension, changelog, releases, CI + QA + coding-standards badges, MIT, ~4.1k stars. Behaviors map directly to known work: Timestampable/Blameable/IpTraceable (audit), Loggable (versioning/history + revert), SoftDeleteable, Sluggable, Translatable, Tree (closure/nested set/materialized path), Sortable, Uploadable, plus ODM-only References/ReferenceIntegrity. Constraints to plan around: DBAL ^3.2 for everything, DBAL ^4.0 for everything except Loggable; ORM ^2.14/^3.0; annotation→attribute migration is on us. Integration cost is one-time: register listeners, enable the mapping extension, document the conventions — after that, behaviors are declarative on entities and reviewable in diffs.

Ask: Approve a short spike (2–3 days) on the current schema to validate the audit + soft-delete + translatable set against real entities, confirm Doctrine is our intended persistence layer, and return with a concrete rollout order (timestamps/blameable → soft delete → slugs → translatable/tree).