Product Decisions This Supports
- Feature scoping for audit history UI. This package exists to answer a single narrow question: how do we render "who changed what, when" for a Doctrine entity inside a Twig template? It bundles a Twig extension over Gedmo's Loggable listener, so it informs the decision of whether to ship a read-only change-history panel as a v1 feature rather than a full audit/versioning platform.
- Build vs. buy for the "history" surface only. It is a template-layer convenience, not an audit backend. The logging, persistence, and entity-change detection come from
gedmo/doctrine-extensions; this bundle contributes presentation helpers. That split is a useful decomposition for our own roadmap: treat capture (listener + storage schema) and presentation (diff rendering) as two separable workstreams with different risk profiles.
- Roadmap input for compliance-adjacent requirements. If a customer or auditor asks for "show the change log on the record detail page," this package is the minimum viable shape of that answer. It helps size the effort as small-to-medium and clarifies that full audit-grade requirements (immutable storage, retention policy, tamper evidence, field-level redaction) are a separate, larger initiative.
- Reference implementation, not a dependency decision. With zero stars and zero dependents, its value to us is as a design reference — how someone else modeled the Twig-to-Loggable bridge — rather than as something we install and inherit.
- Stack-fit check. Despite being catalogued as a PHP package, this is a Symfony bundle depending on Twig, Doctrine ORM, and Gedmo. It is directly relevant only if our stack is Symfony/Doctrine. For a Laravel/Eloquent codebase it does not apply, and its main product value is confirming the pattern (audit log + thin presentation layer) we would implement ourselves.
When to Consider This Package
Consider it only when all of the following hold:
- The application is Symfony with Twig and Doctrine ORM, and Gedmo Loggable is already installed and actively recording entity changes.
- The requirement is display-only history — a "recent changes" list or field diff on a detail page — with no retention, legal-hold, or export obligations.
- The team accepts the risk profile of an unmaintained, effectively unused package (no stars, no dependents, no visible community). Plan to vendor it, fork it, or reimplement the Twig extension in a few dozen lines rather than pin a dependency.
- You have verified compatibility with your Symfony, Twig, and
gedmo/doctrine-extensions versions — bundles this old frequently break on modern Symfony majors.
Look elsewhere — or build it — when:
- You are on Laravel or another non-Symfony framework. There is no path to adoption. The equivalent is
spatie/laravel-activitylog or owen-it/laravel-auditing plus a Blade component for rendering diffs.
- You need audit-grade guarantees. Gedmo Loggable stores changes in a companion table with no immutability, signing, or retention semantics; this package adds nothing there. Consider dedicated audit tooling or an append-only event store.
- You need scale or performance guarantees. Loggable writes on every persist and history rendering is unbatched; there is no pagination or async story here.
- You want a maintained dependency. Zero dependents means near-zero real-world validation; the support cost falls entirely on us.
- You need multi-tenant, field-level redaction, or PII scrubbing in the history view — nothing in this package addresses that.
How to Pitch It (Stakeholders)
To executives: We evaluated an open-source component that displays record change history in a web UI. It is a small, unmaintained, Symfony-specific add-on with no measurable adoption, so we do not recommend taking it as a dependency. Its useful contribution is confirming that "show who changed what" is a thin presentation layer on top of an already-solved logging problem — meaning we can scope this as a small, contained feature rather than a platform investment. If a customer or auditor requires true audit-grade history (immutable, retained, exportable), that is a separate, larger workstream we should decide on explicitly rather than assume this covers.
To engineering: This is a Twig extension over Gedmo Loggable — it renders diffs of Doctrine entity changes. It carries none of the hard parts (capture, storage, retention, redaction). We are on Laravel/Eloquent, so it is not installable; treat it as a reference for the shape of the feature. Recommendation: implement audit capture with an established, maintained package and write a ~50-line presentation layer ourselves, so we own the code path we actually depend on. If we were on Symfony/Doctrine, we would still vendor or reimplement rather than depend on a package with zero dependents.