[Laravel] Debugbar not reset after request

[barryvdh]

So from https://github.com/php-pm/php-pm

Laravel's debugger isn't working yet perfectly since it's still needed to reset some stuff after each request.

I'm assuming you mean my Laravel Debugbar?

If so, I've tried a couple of thing today with PHP-PM, with regards to not setting the config during the request, using different time sources (because the LARAVEL_START can't be re-defined) and not disabling after a request. This resulted in at least having a debugbar every time, but it was the same every time.

I saw the Symfony profiler has a similar issue (https://github.com/symfony/symfony/issues/18244), so based on that, I made an initial implementation: https://github.com/maximebf/php-debugbar/pull/268 That adds a reset() function to the debugbar + collectors, so they can be re-used.

Does that work for you guys? Or should I change something else?

Possible implementation could be:

    /**
     * @param \Illuminate\Contracts\Foundation\Application $app
     */
    public function postHandle($app)
    {
        $app = app();
        if ($app->resolved('debugbar')) {
            $app['debugbar']->reset();
        }
    }

(I used $app = app() because the parameter seems incorrect, it's an HttpKernel, not the Laravel app?)

Note: this isn't perfect yet, not all collectors are implementing the Resettable interface yet, and some collectors are added twice, but it should be a good starting point.

[marcj]

Yes, exactly. In Laravel's Bootstrap class is $this->app, this is probably what you want to use in postHandle instead of the $app argument. If your implementation works, then we should definitely land it :)

I have not much experiences with Laravel, but I guess that should do the trick for the moment so people can use PHP-PM also with Laravel completely. Maybe @taylorotwell has more insights.

[barryvdh]

I haven't really tested yet, but wouldn't it be easier to reset the Container or something? Don't a lot of classes have this problem, or is that kind of intended/the purpose?

[marcj]

Resetting the container is a drastically performance decreasement which makes php-pm almost useless. Symfony's HttpKernel has a terminate event, which should be used to clean stuff up. However, since PHP normally "cleans" everything up after each requests, almost nobody used the event. Nonetheless this is the way to go.

[barryvdh]

So should I terminate in my Debugbar middleware then?

[marcj]

I don't know what you mean. You need to reset stuff that needs to be resetted in the terminate event.

[barryvdh]

I meant that if I put the cleanup, in the middleware from the debugbar, we don't need to change the postHandle() function here. And the same goes for Laravel itself, if I need to reset some stuff (like user etc), we can just put it in a middleware with terminate method?

[marcj]

Yes, if you have the necessary events in your middleware, then you should place the cleanup there.

[hernandev]

@barryvdh any toughs on the current state of this?

[barryvdh]

Yeah not really, haven't looked in it much because I haven't found a use-case yet. Does it work with Laravel out-of-the-box yet?

[hernandev]

@barryvdh Just tested, yes, looks like working really well, only that debugbar settings are ignored and it only gets activated if php-pm --debug=1 otherwise it will not load.

Thanks!

[hernandev]

Sorry, it's not.

It's actually loading, but showing repetively the first request results intead of refreshing.

[cmizzi]

laravel-debugbar works only for the first request. Next, collectors are not refreshed. Your PR will made a lot of things better to handle reset directly from a middleware in Laravel. You could reset data collectors in the generic middleware (https://github.com/barryvdh/laravel-debugbar/blob/master/src/Middleware/DebugbarEnabled.php)