Gedmo Twig Softdeleteable Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. Despite the "PHP package" framing, this is a Symfony bundle, not a Composer library that drops into Laravel. It ships a Bundle class, a DI extension, and depends on Symfony's Twig bundle wiring plus Doctrine's Gedmo SoftDeleteable filter. Laravel's persistence layer is Eloquent, where soft deletes are a trait (SoftDeletes) resolved through query scopes (withTrashed(), onlyTrashed()), not a global Doctrine filter that can be toggled at runtime. The package's entire value proposition — flipping the SoftDeleteable filter on and off from inside a Twig template — has no direct analog in the Laravel stack.

The narrow case where it is technically relevant: a Laravel app using laravel-doctrine/orm for entities and twigbridge for templating, with Gedmo extensions installed. That is a rare combination, and even then the Symfony bundle packaging works against you — you would be bootstrapping Symfony bundle infrastructure inside an Laravel service container.

Integration feasibility — low, and the cost/benefit is inverted. The functional core is roughly 20–30 lines: fetch the Doctrine FilterCollection, disable softdeleteable, render the block, re-enable. A TPM should treat "vendor the logic" as the realistic integration path rather than "install the dependency." There is no Laravel service provider, no config publishing, no facade, no published compatibility matrix.

Technical risk — high.

• Abandonment risk: 0 stars, 0 dependents, single maintainer, no visible test suite or CI. No downstream consumers means breakage goes undetected upstream.
• Layering violation: a template controlling persistence visibility inverts the normal dependency direction. Presentation should receive already-scoped data; it should not mutate global ORM state mid-render.
• State leakage: Doctrine filters are effectively global/request-scoped state. In a Laravel Octane worker, queue worker, or any long-lived process, a missed re-enable leaks soft-deleted rows into subsequent, unrelated queries — a data-exposure and data-integrity risk, not just a cosmetic one.
• Version drift: bundles of this vintage typically pin older Symfony (2.x/3.x) and Gedmo releases; compatibility with modern PHP 8.2+ and current Gedmo is unverified.

Key questions for the team:

1. Does this application actually use Doctrine entities and Gedmo, or is this assessment hypothetical? If Eloquent, the package is out of scope entirely.
2. What is the real requirement — rendering an audit/admin view of soft-deleted records? If so, an explicit repository method or a pre-fetched, explicitly-authorized collection passed to the view is strictly safer.
3. Who owns the fork when upstream goes quiet (it already has)?
4. If we do toggle filters, is every code path wrapped in try/finally and is state reset guaranteed at request/worker boundary?
5. Is exposure of soft-deleted content gated by authorization, or is the tag itself the only control?

Integration Approach

Stack fit — none for a standard Laravel app. Laravel 10/11 + Eloquent + Blade: no fit, no partial fit. Laravel + Doctrine via laravel-doctrine/orm + Twig via twigbridge: the behavior is relevant but the artifact is not — you would be hand-registering a Symfony bundle in a Laravel kernel.

Migration path — don't migrate; reimplement. Recommended sequence:

1. Spike (1–2 days): build the equivalent as a Twig function or block tag inside the app: resolve EntityManager → getFilters() → disable softdeleteable → render block → re-enable in a finally. Register via twigbridge's extension registration, not a bundle.
2. Prefer the non-toggle design: add an explicit repository/query method (e.g., findWithTrashed($id)) and pass the result into the template. This keeps filter state constant and puts the "show deleted" decision in the domain layer where it can be authorized.
3. If the tag is retained, restrict it to admin routes, wrap it in authorization checks, and add a test asserting filter state is restored after both normal and exceptional render paths.

Compatibility. Unverified against PHP 8.x, current Gedmo (gedmo/doctrine-extensions), Symfony 5/6/7, and Twig 3. Treat any adoption as "vendor the source and own it." Do not add it as a floating Composer constraint — pin to a commit and review on upgrade of Doctrine or Twig.

Sequencing dependencies. Confirm the ORM question first; everything downstream is wasted effort under Eloquent. Then confirm whether any soft-deleted rendering requirement exists at all — if the answer is "audit screens only," this package is solving a problem a query scope already solves.

Verdict: score of 0 with 0 stars and 0 dependents is consistent with the package's actual position — a small, single-purpose Symfony helper with no adoption. Recommend reject as a dependency, adopt as a pattern, and budget the 1–2 day spike rather than a dependency-review cycle.

Operational Impact

Maintenance. No upstream maintenance signal. No release cadence, no dependents to surface regressions, no security disclosure path. Any use implies fork ownership: your team becomes the maintainer of a component it did not write, for roughly 30 lines of behavior. The carrying cost is disproportionate to the value.

Support. Documentation appears limited to a README describing tag syntax. No issue triage, no LTS, no commercial backing. Internal onboarding documentation must be written from scratch.

Scaling. The toggle itself is cheap — it is a flag on a filter collection, not a query rewrite. The risk is scoping, not throughput: in Octane, Swoole, queue workers, or any resident process, request-scoped filter state can survive the request that set it. Under concurrency this becomes nondeterministic visibility of deleted rows rather than a crash. Horizontal scaling amplifies the blast radius because more requests share longer-lived workers.

Failure modes, ranked:

1. Filter not restored (exception in the template block, early return, nested tag, killed request) → soft-deleted rows silently appear in later, unrelated queries across the app. Highest severity; a data-exposure class of bug.
2. Broad disable → toggling around a block that triggers lazy-loaded relations pulls deleted rows into nested hydration; N+1 and correctness issues compound.
3. Authorization bypass → if the tag is the only gate on showing deleted content, any template that uses it exposes content the requester should not see.
4. Silent no-op on upgrade → a Gedmo or Doctrine upgrade renames the filter; the tag stops working and deleted records reappear or disappear with no error.
5. Install-time breakage → Symfony bundle registration fails under modern PHP/Symfony constraints.

Ramp-up. Mechanically trivial — one tag, one behavior. But it presumes Doctrine filter internals and Twig extension registration knowledge that a typical Laravel/Blade team does not carry. Effective ramp-up is a half-day for a Laravel engineer if the Doctrine bridge is already in place, and a multi-day investigation if it is not.

Recommendation. Do not adopt. If the underlying requirement (displaying soft-deleted records in a template) is real, implement it as an authorized, explicit query path in the domain layer and pass the data to the view. Keep filter state immutable during rendering.