- What does the dejwcake/advanced-logger package actually do?
- Advanced Logger is a Laravel-native package that extends the framework's built-in logging with configurable channels, richer request context, and structured output. It ships a request logger, a hash-based log customizer, a service class, and a framework listener handler that hooks into the request lifecycle. The goal is to make application events easier to capture, organize, and review in both development and production with minimal setup. It does not replace Laravel's logging stack so much as layer structured, request-aware logging on top of it.
- How do I install advanced-logger in a Laravel application?
- Install it with Composer, then publish the package configuration and register the listener or middleware it provides. After that you define your hashing rules and channel settings in the published config file. The integration effort is low: there is no service provider gymnastics required and no non-PHP runtime dependencies are introduced. Most teams will be running within a few minutes of the first composer require.
- What PHP and Laravel versions does advanced-logger 2.0.1 require?
- Version 2.0.1 declares its core classes as final readonly, which raises the effective minimum to PHP 8.2. If any environment in your fleet still runs PHP 8.0 or 8.1, Composer will silently resolve you back to an older tag instead of failing loudly, which can create version skew between environments. Check your minimum supported PHP across all environments before rolling this out. Confirm the package's own composer.json constraints against your Laravel version as part of that check.
- Can I extend RequestLogger or RequestLoggerService in my own code?
- No. As of 2.0.1 the RequestLogger, RequestLoggerService, HashLogCustomizer, and RequestLoggerListenerHandler classes are final and readonly, so subclassing them will fatal on upgrade. You should treat all four as internal implementation details and consume the package through configuration, container bindings, or events instead. If you need a stable extension point, bind against an interface in the container rather than depending on the concrete class. Grep your codebase for extends on those names before you upgrade.
- Why did my PHPUnit or Mockery tests break after upgrading advanced-logger?
- Mockery and PHPUnit cannot mock final classes, so any test double built with Mockery::mock(RequestLogger::class) or createMock(RequestLogger::class) will fail after 2.0.1. The failure surfaces as a test error rather than as a Composer upgrade error, which makes it the most likely upgrade incident for typical consumers. The fix is to depend on an interface or to fake at the boundary of your own code instead of mocking the package class directly. Audit your test suite for mocks of the four newly-final classes before bumping the version.
- Does the hash-based log customizer handle PII and redaction requirements?
- HashLogCustomizer hashes configured fields before they reach your log output, driven by the rules you set in the published config. Whether that satisfies your compliance obligations depends on your specific PII and redaction requirements, so review the hashing behavior against them rather than assuming it is sufficient. The 2.0.1 release notes state there is no behavioral change to hashing, but confirm that yourself if redaction is a regulated concern. Hashed values are generally not reversible, so plan for how you will correlate entries if you need the original data elsewhere.
- Is upgrading from advanced-logger 2.0.0 to 2.0.1 really a no-op?
- The release notes say there is nothing to do when upgrading, and for the median consumer that is probably accurate. But the move to final readonly is arguably a major-version change delivered in a patch release, so you cannot rely on the version number alone to signal risk. Consumers who subclass or mock the affected classes will break, and PHP 8.0 or 8.1 environments will silently resolve to an older tag. Verify the upgrade in your own pipeline and pin the version explicitly.
- Is advanced-logger safe to run on the request critical path in production?
- The package logs requests through a listener handler or middleware that sits in your request lifecycle, so whether a logging failure can affect a response depends on how you register it and how exceptions are handled. Confirm whether the integration is fire-and-forget or blocking before enabling it on high-traffic routes. Because it captures request context and hashes configured fields, you should also measure the overhead on your hot paths rather than assuming it is negligible. Start by enabling it on a subset of routes and reviewing both latency and log volume.
- How is advanced-logger different from Laravel's built-in logging channels?
- Laravel already lets you define multiple channels in config/logging.php and format output through Monolog, so if channel configuration is all you need, the framework covers it without an extra dependency. Advanced Logger adds request-scoped context capture, structured output, and a configurable hash-based customizer on top of that baseline. Choose it when you want consistent per-request structured records and redaction rules without writing your own listener. If your requirements are simple, stick with the built-in stack to keep your dependency surface small.
- How actively maintained is advanced-logger and how should I pin it?
- The 2.0.1 release is primarily internal hardening and packaging hygiene, including final readonly class modifiers, export-ignore rules for tests and Docker files, and CI and phpmd updates, which indicates an actively tightened codebase. Because those object-model changes landed in a patch release, pin an explicit version in composer.json rather than relying on a caret range to protect you. Treat the concrete classes as internal and depend on configuration or interfaces so future hardening does not break your integration. Review each release note manually, since the version number alone will not tell you when a breaking change has shipped.