- Is franzl/whoops-middleware a Laravel package?
- No. It is a framework-agnostic PSR-15 middleware that wraps filp/whoops and catches uncaught exceptions in a PSR-7 middleware pipeline. Laravel's HTTP kernel uses a different contract (handle($request, Closure $next)), so using this package in Laravel requires a bridge or adapter layer. Laravel already ships spatie/laravel-ignition for rich development error pages.
- Does franzl/whoops-middleware work with Laravel out of the box?
- Not natively. You would need to convert Laravel's request/response objects to PSR-7 and adapt the middleware into the kernel pipeline, which is meaningful glue for a feature Ignition already provides. It only makes sense if you are already running a PSR-15 stack inside a Laravel app. For a standard Laravel application, Ignition is the simpler and better-supported choice.
- How do I install franzl/whoops-middleware?
- Install it with Composer using composer require franzl/whoops-middleware. Version 2.0.0 requires PHP 7.2 or newer and adds PHP 8 support. Add the middleware to your PSR-15 pipeline, ideally as the outermost layer so it can catch exceptions thrown by everything downstream.
- Which PHP versions does franzl/whoops-middleware 2.0.0 support?
- Version 2.0.0 drops PHP below 7.2 and adds PHP 8 support. Note that a PHP 8 claim in release notes often means 8.0 specifically, not every 8.x minor you may be running. Smoke-test on your actual runtime before relying on it, and do not read the release note as a compatibility guarantee.
- What changed in franzl/whoops-middleware 2.0.0?
- It is a maintenance release, not a feature release: PHP 8 support was added, PHP below 7.2 was dropped, and the hard dependency on a Laminas PSR-7 implementation was replaced with runtime discovery via middleware/utils. There are no API changes to the middleware itself. The new transitive dependency and the discovery behavior are worth vetting in your own app before adopting.
- How do I disable Whoops error pages in production?
- The package does not enforce environment gating, so production safety is entirely your responsibility. Conditionally register the middleware only in local or development environments, or swap in a handler that returns a clean generic response. If you leave it enabled, detailed stack traces and code snippets can be exposed to end users.
- Can I customize the error output format, such as JSON or plain text?
- Yes. Whoops supports pluggable handlers, including its pretty page handler, a JSON response handler, and a plain text handler. You configure the Whoops instance with the handler you want and pass it to the middleware. This is useful when the same pipeline serves both browser and API traffic.
- How does the PSR-7 runtime discovery in 2.0.0 affect my application?
- Version 2.0.0 uses middleware/utils to pick whichever PSR-7 implementation is available at runtime instead of forcing Laminas. That is benign in an app with a single PSR-7 implementation, but ambiguous when several are installed, which is common when Symfony's PSR-7 bridge sits alongside Nyholm or Diactoros. If discovery picks the wrong factory, failures tend to surface as type errors inside the error path, so verify and pin the selection before piloting.
- Is franzl/whoops-middleware actively maintained?
- It has a single maintainer, roughly 28 stars, and no dependents, and there was a multi-year gap before the 2.0.0 release. The release is a positive signal, but treat the project as not dead rather than actively stewarded. If it becomes load-bearing in your stack, vendor or fork it.
- What are the alternatives to franzl/whoops-middleware?
- In Laravel, spatie/laravel-ignition is the first-party answer, and you can also wire filp/whoops directly through a service provider. For PSR-15 stacks, middlewares/whoops or a small custom error middleware around Whoops are common options. For Laravel specifically, redundancy with Ignition is the main reason to skip this package.