- Can I install kricha/doctrine-audit-bundle in a Laravel application?
- You can require it with Composer, but it will not work out of the box. It is a Symfony bundle that registers itself through config/bundles.php plus a DependencyInjection extension and Configuration tree, none of which Laravel provides. Making it run means writing a Laravel service provider that registers its Doctrine event subscriber and binds the auditor yourself. For a standard Eloquent app it is effectively unusable.
- Does this package work with Laravel Eloquent models?
- No. The bundle hooks Doctrine ORM lifecycle events such as onFlush, postPersist, postUpdate and postRemove, while Eloquent emits a completely different event surface. There is no Eloquent adapter or bridge in the package. Use owen-it/laravel-auditing or spatie/laravel-activitylog instead.
- Which PHP and Doctrine versions does kricha/doctrine-audit-bundle support?
- The last release was February 2022, so expect constraints built around PHP 7.x/8.0 and Doctrine ORM 2.x. Compatibility with PHP 8.2/8.3 and Doctrine ORM 3.x is unverified and likely to break. Check composer.json before assuming it installs, and budget time to widen or patch constraints.
- How do I use this bundle if my Laravel app already runs Doctrine ORM?
- You extract the logic rather than consume the bundle wholesale. Register its audit event subscriber on Doctrine's EventManager inside an AppServiceProvider, bind the auditor as a singleton, and publish the audit table schema as a Laravel migration instead of relying on the bundle's console commands. Map the Symfony Configuration options to a config/audit.php file. Vendoring or forking is strongly recommended so you control patching.
- How is kricha/doctrine-audit-bundle different from owen-it/laravel-auditing?
- owen-it/laravel-auditing is Eloquent-native, actively maintained, and installs as a normal Laravel package with a publishable config and migration. This bundle is Symfony plus Doctrine only, last released in 2022, with roughly 9 GitHub stars and no dependents. For an Eloquent application the maintained Laravel options are strictly better.
- How do I configure which entities get audited?
- In Symfony you declare audited entities, a global ignore list and a table prefix through the bundle's Configuration tree using YAML, XML or PHP config. In a Laravel port you would translate those same options into a config/audit.php file and read them from your own service provider. The core auditor logic also drives the ignore rules, so keep that mapping intact when extracting.
- Does it record which user made each change?
- Yes, the bundle supports blameable users so revisions can be attributed to the actor responsible for the change. You supply the current user through its blameable integration. In a Laravel port you would bind Auth::user() into the auditor from a service provider or middleware.
- Is kricha/doctrine-audit-bundle actively maintained?
- No. The last release was 2022-02-05 with no activity since, around 9 stars and zero dependents on Packagist. It is a single-maintainer project with a bus factor of one and no upstream to escalate to. Adopting it means you own patching, security review and Doctrine version tracking.
- What data does the audit trail actually store?
- It stores audit revisions containing entity snapshots plus change metadata: entity type, identifier, changed fields, before and after values, actor and timestamp. That supports compliance, debugging and reconstructing history. Verify the exact schema and column types against your retention, tamper-evidence and JSON/JSONB requirements before committing.
- How do I test that the audit logging actually fires?
- Write an integration test that persists, updates and deletes a Doctrine entity inside a transaction, then assert the expected audit rows exist with the right diff and actor. In Laravel, run it against a real database connection rather than SQLite in-memory if you depend on JSON column behaviour. Delete tracking deserves its own test because postRemove ordering often surprises people.