- How do I install kikwik/doctrine-entity-logger-bundle?
- Install it with Composer using composer require kikwik/doctrine-entity-logger-bundle, then register the bundle in your Symfony bundles.php if Flex does not do it automatically. Confirm the package composer.json constraints against your PHP, Symfony, and Doctrine versions before installing, because the opt-in attribute requires PHP 8.0 or later. Clear the cache after registration and again after adding attributes to entities. Finish with a quick integration test that persists an annotated entity and checks that a log record is written.
- Does kikwik/doctrine-entity-logger-bundle work with Laravel and Eloquent?
- No. This is a Symfony bundle that hooks Doctrine ORM entity events, so Eloquent models are not covered and the LoggableEntity attribute will not attach to Eloquent persistence. Laravel teams needing audit trails should use an Eloquent model-event package such as spatie/laravel-activitylog. If your project mixes frameworks, isolate the Doctrine side and confirm the bundle is only booted in the Symfony kernel.
- How does the LoggableEntity attribute opt-in work in version 0.2.0?
- In v0.2.0 a log record is written only for entity classes that carry the LoggableEntity attribute, so scope is declared next to the domain model instead of in a central allowlist. That is idiomatic PHP 8 attribute design and makes audit coverage reviewable in code review. The evidence for the exact mechanics is thin, though, so validate inheritance, caching, and event-time resolution in a short spike before relying on it. Treat any unannotated model as unlogged.
- Why did my audit logs stop after upgrading to 0.2.0?
- The most likely cause is the new opt-in gate: models that previously produced records now write nothing unless their class carries the LoggableEntity attribute, and the failure is silent. There is no exception, warning, or failed health check to alert you. Pin the version, capture baseline log volume and distinct-entity coverage before upgrading, and annotate all audit-required entities first. Then upgrade and diff coverage against the baseline.
- Is the LoggableEntity attribute inherited by subclasses or applied to join and pivot entities?
- This is unverified in the available release notes and should be tested directly. Write fixtures for a base entity, a subclass, a many-to-many join entity, and a polymorphic-style association, then assert which ones produce log rows. Also check whether the attribute is read via reflection at boot or at event time, because that changes both deploy steps and failure modes on queue and console workers.
- Does the bundle log bulk updates, DQL deletes, or force-deletes?
- Doctrine lifecycle events fire for entity-level persist, update, and remove operations, so bulk DQL UPDATE or DELETE statements and raw DBAL queries typically bypass them. Soft deletes and force-deletes depend on how the bundle maps Doctrine events, so test those paths explicitly. If you rely on audit completeness, route bulk changes through entity-level operations or add a separate database-trigger or binlog-based control.
- What is the performance cost of attribute resolution on every write?
- The release notes do not confirm whether attribute resolution is cached per class or performed per instance, and the difference matters at high write volume. Benchmark a representative persist and update workload with and without the attribute, and profile reflection cost. If resolution is cached, plan to run cache:clear or optimize:clear on every deploy that adds or removes the attribute. Treat the result as a capacity input rather than a micro-optimization.
- How do I test that entity change logging actually works?
- Write integration tests that persist, update, and delete an annotated entity and assert the expected log rows, then do the same for an unannotated entity and assert that nothing is written. Cover soft deletes, force deletes, subclass entities, and join entities if you use them. Run these tests in CI on the exact PHP, Symfony, and Doctrine matrix you deploy. A passing test suite is the only reliable guard against the silent-gap failure mode.
- What is the migration path from 0.1.x to 0.2.0?
- Inventory every Doctrine entity and classify it as audit-required, audit-optional, or explicitly excluded; that inventory is the real deliverable and the artifact auditors will ask for. Capture seven days of log volume and distinct-entity coverage on 0.1.x as your baseline. Add the LoggableEntity attribute to audit-required entities on the current version, verify coverage, then bump the dependency and re-diff. Treat the upgrade as breaking in your changelog regardless of the 0.x semver convention.
- What alternatives exist for Doctrine audit logging in PHP?
- Gedmo DoctrineExtensions Loggable and custom Doctrine event subscribers are the common alternatives, and both give you explicit control over which entities are tracked. For Laravel and Eloquent, spatie/laravel-activitylog is the usual choice. Compare them on attribute or annotation scope, storage model, bulk-operation coverage, and maintenance activity. At v0.2.0 the kikwik bundle has an immature API surface, so avoid deep extensions until it stabilizes.