xcentric/soft-deleteable-extension-bundle
Xcentric SoftDeleteable Extension Bundle adds soft-delete support for Doctrine entities in Symfony, marking records as deleted instead of removing them and enabling filtered queries, restore, and permanent purge workflows.
Architecture fit. Despite the "Laravel/PHP" framing, this is a Symfony bundle, not a Laravel package. It registers a Doctrine event listener that extends Gedmo's SoftDeleteableListener to cascade soft-deletes from a parent entity to its associations. That places it squarely in the Doctrine ORM + Gedmo ecosystem (gedmo/doctrine-extensions), with a DI extension, a bundle class, and service wiring. There is no service provider, facade, config stub, or Eloquent integration — nothing a Laravel application can consume without adopting laravel-doctrine/orm and Gedmo wholesale, which is a stack-level decision, not a package-level one. Architecture fit for a typical Laravel codebase: poor. Fit for a Symfony/Doctrine codebase already using Gedmo SoftDeleteable: reasonable, because it fills a genuine gap — Gedmo cascades hard deletes but does not cascade soft deletes to associations.
Integration feasibility. Mechanically simple in the right host: add the bundle to bundles.php, ensure the listener priority places it ahead of the stock Gedmo listener, and annotate/attribute associations that should cascade. The complexity is not installation but semantics: cascade-on-delete has no symmetric cascade-on-restore, so a soft-deleted parent with soft-deleted children is recoverable only in one direction. Any "undelete" workflow, admin recycle bin, or restore endpoint must be designed and implemented separately. That asymmetry is the dominant integration cost.
Technical risk. High, concentrated in supply chain and version drift:
xcentric) — effectively unvalidated in production anywhere public.E-vence/SoftDeleteableListenerExtensionBundle, which means the maintenance burden is likely inherited but not necessarily improved; upstream activity and the fork's divergence both need checking.UnitOfWork behavior; a small fork pinned to an older combination will silently break on upgrade.onFlush, where re-entrant UnitOfWork computation is fragile — entity changes made during flush can be missed or double-flushed. This is the classic failure point for listener-based cascade implementations.Key questions. (1) Which Gedmo and Doctrine ORM versions are actually supported — is there a composer.json constraint matrix and CI proving it? (2) Does the cascade cover OneToMany, ManyToMany, and ManyToOne, and does it honor Gedmo's soft-delete on the target entity only? (3) Is the listener transaction-safe under batch deletes and flush() inside a larger unit of work? (4) What is the restore story — is one provided, or explicitly out of scope? (5) Is the vendor prepared to support this, or is it an extracted internal dependency published for convenience? (6) Can the same behavior be achieved in ~50 lines of in-house listener code we control?
Stack fit. Only viable where the stack is Symfony (or framework-agnostic PHP) + Doctrine ORM + Gedmo SoftDeleteable. In Laravel, the realistic alternatives are: Eloquent's native SoftDeletes with an explicit application-level cascade in a model observer or deleting hook, or a laravel-doctrine migration. Given the zero-adoption signal, do not introduce laravel-doctrine + Gedmo solely to use this bundle. Treat the package as a reference implementation for the cascade pattern, not a dependency.
Migration path. Two honest options:
Compatibility. Pin Gedmo and Doctrine ORM explicitly in composer.json; do not rely on the fork's constraints. Add a CI job that runs the cascade tests against the minimum and maximum supported versions, because this is precisely the package that breaks on a minor bump.
Sequencing. (1) Confirm stack is Doctrine-based; if not, stop and use native Eloquent soft deletes with an explicit cascade. (2) Audit the actual entity graph for cascading associations and decide which should cascade — cascade-by-default is a data-loss footgun. (3) Build the restore path or explicitly declare soft-deleted children unrecoverable. (4) Contract tests on a real schema: parent delete → children soft-deleted; partial failure rolls back; soft-deleted children excluded from parent queries. (5) Only then, roll out per-entity.
Maintenance. This is the decisive factor. A single-vendor fork with no stars and no dependents has an expected maintenance half-life measured in months. Assume you will own this code within a release cycle or two. Budget for a fork-and-vendor strategy from day one — copy into an internal package repository rather than depending on the GitLab URL, so an upstream deletion or namespace rename cannot break your build.
Support. No community, no issue-tracker signal, no documented SLA. Escalation path is "read the source." That is acceptable for a 100-line listener; it is not acceptable for anything in a regulated or high-availability path without internal ownership.
Scaling. Cascade deletes amplify write volume: deleting one parent can touch thousands of rows in a single onFlush cycle, holding locks and inflating transaction size. For large graphs, prefer asynchronous cascades (queued job walking the association graph in batches) over listener-driven synchronous cascade. Also watch query-path impact — soft-deleted children must be filtered everywhere, and poorly indexed deleted_at columns plus cascading predicates degrade read performance as tables grow.
Failure modes. (1) Silent no-op when listener priority is misconfigured relative to Gedmo's listener — children remain live and queries return orphaned rows. (2) Partial cascade inside a failed transaction leaving inconsistent visibility states. (3) Unique-constraint collisions when soft-deleted rows still occupy unique indexes on child tables. (4) UnitOfWork re-entrancy errors or missed entities during large flushes. (5) Breakage on Gedmo/Doctrine upgrade with no upstream fix forthcoming. (6) Irreversible data states from an over-broad cascade configuration.
Ramp-up. Low for a Doctrine-fluent engineer — a few hours to understand the listener and its extension points. Higher for the team overall, because the concept (soft-delete cascade plus its restore asymmetry) needs to be understood by anyone writing queries or admin tooling, not just the person who wired the bundle. Plan a short design note documenting which associations cascade, what restore guarantees exist, and how to query around soft-deleted children.
Verdict. Score it as a pattern reference, not a dependency. The opportunity score reflects a real gap in Gedmo's feature set, not the maturity of this artifact. On a Symfony/Doctrine codebase, adopt only with internal ownership and pinned versions. On Laravel — the stated context — do not integrate; implement the equivalent cascade explicitly and keep the dependency graph clean.
How can I help you explore Laravel packages today?