Gedmo Twig Softdeleteable Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a ~30-line capability. This package exists to solve one narrow problem: temporarily disabling Doctrine's Gedmo SoftDeleteable filter from inside a Twig template, so that a block of markup can render or query soft-deleted rows (trash bins, audit views, restore screens, "show archived" toggles). That is a try/finally around $em->getFilters()->disable('softdeleteable') wrapped in a Twig tag. Treat the decision as "do we vendor a dependency or write the extension ourselves," not as a platform choice.
• Feature scoping for admin/back-office surfaces. It directly enables "show deleted records," "restore," and "audit history" views without changing controller code. Useful input when estimating these features — but the same outcome is achievable by passing a pre-fetched collection into the template, which is the safer design and should be the default proposal.
• Layering/architecture decision. Adopting it endorses a view-layer template controlling persistence-layer query scope. That is a one-way-ish door: once templates can toggle ORM filters, "why is this row visible?" becomes non-local and hard to review. A PM should push this decision to the query/repository layer and record it as an architectural guardrail.
• Dependency-risk triage. Zero stars, zero dependents, zero score, single-author bundle. This is a maintenance-liability decision, not a capability decision — it belongs in the same conversation as "do we accept an unmaintained transitive dependency in our render path."
• Not a roadmap item. There is no product differentiation here, no user-visible capability that isn't already reachable in the framework. It should never appear on a roadmap; at most it appears as a line item in an implementation note.

When to Consider This Package

Consider it only if all of the following hold:

• The stack is Symfony + Doctrine + Gedmo SoftDeleteable + Twig. Note explicitly: this is not a Laravel package and has no Laravel applicability — Laravel uses Eloquent SoftDeletes with withTrashed() / onlyTrashed() query scopes and Blade templates, none of which this bundle touches.
• You need soft-deleted rows visible for a narrow, well-bounded template region, and you are unwilling to refactor the controller/service to pass that data in.
• You are prepared to vendor or fork it and own the code, since upstream activity cannot be assumed.

Look elsewhere — or write it yourself — when:

• You are on Laravel, or on any non-Doctrine ORM: this package is irrelevant, and the equivalent is a query scope, not a template tag.
• You want a maintained dependency: prefer a short in-house Twig extension (explicitly using try/finally so the filter is always re-enabled) over an unmaintained bundle in the render path.
• Deleted-record visibility is permission-sensitive (e.g., only admins see trashed rows, or multi-tenant scoping applies). Filter toggling inside a template bypasses authorization boundaries and makes access control unauditable — enforce this in the query layer with an explicit policy check.
• The template is rendered in a context with sub-renders, ESI/fragment rendering, or long-running workers. Doctrine filters are mutable state on the shared EntityManager; disabling one mid-render can leak into any query executed during that window. If you cannot guarantee containment, don't adopt.
• You need restore/hard-delete workflows: those are service-layer operations (with transactions and audit logging), not template concerns.

Default recommendation: do not adopt. Have engineering write the equivalent extension in-house, or better, invert the design so controllers/services pass soft-deleted collections into the view. Either path removes the dependency entirely.

How to Pitch It (Stakeholders)

To executives: This is a tiny, unmaintained Symfony-only utility with no adoption (zero stars, zero dependents) that lets a template toggle a database filter. It is not a strategic dependency and carries no product differentiation. The capability it provides — showing archived/deleted records in admin screens — is real and already on our list; we can deliver it without this package. Recommendation: skip the dependency, build the ~30 lines internally, and avoid adding an unowned component to our render path.

To engineering: Scope is one Twig tag that wraps EntityManager::getFilters()->disable('softdeleteable'). Concerns to resolve before any adoption: (1) filter re-enablement must be try/finally-guaranteed; (2) Doctrine filters are shared mutable state on the EntityManager, so the tag's effect can bleed into sub-renders and any query inside the block — it cannot be scoped to "just this template"; (3) it moves a persistence concern into the view layer where it is hard to review and easy to misuse for authorization-sensitive visibility; (4) no observable maintenance. Preferred alternatives, in order: pass a pre-fetched collection into the template; otherwise a first-party Twig extension with explicit containment. If we do adopt, vendor the code and add a test that asserts the filter is restored after an exception.