At the moment the library always returns an HtmlResponse for the Whoops handler. I made a workaround which sets a default content type for the response but this is a bit of a hack as it should probably insert best fit according to the request accept header. Please consider handling, but if you want a PR in the meantime let me know.

https://github.com/MrHash/whoops-middleware/commit/e4f65776719a1ca66d8a3df1cadc3406cd1a3602

I am interested in support for PSR15 middleware.

Despite the fact that PSR 15 is not yet finished I already started on an approach to support version ^0.4.

Have a look at timtegeler/whoops-middleware@47c18c1ca85b2bc9b5ad4d14c2f2d8146fb9e800

Perhaps you can review my approach and share your thoughts with me. :)

…, using WhoopsRunFactory for creating WhoopsRun instance, added unit tests

I know this is a major change to your library and comes out of the blue, but I think this could gain some benefits. I'm curious about what you're saying. :)

In the last days I realized, that if I want to integrate franzliedke/whoops-middleware in one of my projects I would have some problems. My desire is to use franzliedke/whoops-middleware on development and production environment.

Because of that, I would need the ability to manipulate the creation of Whoops\Run like in this code example from one of Whoops issues:

error_reporting(E_ALL);
$run = new \Whoops\Run;
if ($debug) {
    $run->pushHandler(new \Whoops\Handler\PrettyPageHandler);
    assert_options(ASSERT_ACTIVE, true);
} else {
    $run->pushHandler(function($e){
        $myApp->outputFriendlyError();
        $myApp->sendDevEmail();
    });
}
$run->register();

But this logic is inside of WhoopsRunner and cannot be manipulate because of the static call of getWhoopsInstance from the Middlewares.

So I started to rewrite a little bit to proof my ideas. More and more ideas came into my mind and I came up with a major refactoring. Here is the list of changes I made:

• Using dependency injection to inject components e.g. WhoopsRunner instead of calling static methods. This has the advantage to decouple the logic and simpler unit testing.

/**
* @param WhoopsRunner $whoopsRunner
*/
public function __construct(WhoopsRunner $whoopsRunner)
{
	$this->whoopsRun = $whoopsRunner;
}

• To circumvent the dependency hell - if a library user wants to use the Middleware without worrying about the creation of Whoops\Run and doesn't use a DI-Framework - I added factory methods.

/**
* @return Middleware
*/
public static function createNewInstance()
{
	return new Middleware(WhoopsRunner::createNewInstance());
}

• I splitted WhoopsRunner into to two sperate components WhoopsRunner and WhoopsRunFactory. WhoopsRunFactory implements WhoopsRunFactoryInterface which is now a dependency of WhoopsRunner. WhoopsRunFactory is responsible for creating instances of Whoops\Run. Because of that a library user has the possibility to implement WhoopsRunFactoryInterface on his own, to alter the creation of Whoops\Run.

interface WhoopsRunFactoryInterface
{
    /**
     * @param ServerRequestInterface $request
     * @return Run
     */
    public function getWhoopsInstance(ServerRequestInterface $request);

}

• I wrote unit tests for every component and achieved a 100% code coverage. This needed a little bit of refactoring which is highly related to my the first item of this list. E.g. I implemented a CliDetector which is a dependency of WhoopsRunFactory. It detects if the server api is equal to 'cli'. This gave me the ability to mock CliDetector and test lines of code in WhoopsRunFactory which otherwise I could't reach.

class CliDetector
{
    /**
     * @return bool
     */
    public function isCli()
    {
        return php_sapi_name() === 'cli';
    }
}

• To 'hide' components from the library user that are not part of the library interface I moved them into a insides directory.

I didn't add more than autogenerated PHPDoc and also didn't adjust the README. Before I would do that, I await your response.

Handle method return HtmlResponse instead of StringResponse which does not exist anymore in Zend/Diactoros : https://github.com/zendframework/zend-diactoros/pull/61

The ErrorMiddleware (that is designed to work with Stratigility) needs to have 4 required parameters if we want it to be detected as an error middleware by Stratigility. Otherwise, it is detected as a normal middleware and breaks.

It is because of these lines of code:

https://github.com/zendframework/zend-stratigility/blob/61adbe76af9a3a1f5d2e5df7b5182daa0cf472d4/src/Dispatch.php#L61-L70

I simply removed the "= null" from the 4th parameter to make it required.