REPL

[schickling]

I don't know if this is even possible in php but for ruby there exists a Gem (https://github.com/charliesome/better_errors) providing support for a REPL inside the browser for debugging and runtime information. I never saw something like this in PHP but I think that might be great and a huge improvement to the PHP community.

What do you guys think about this feature request?

[filp]

The better_errors gem is actually made by my friend Charlie Somerville, and was a huge inspiration for whoops. Things like the editor support feature were actually 'stolen' from better_errors 😄

I like the idea, and have actually been playing around with the idea of integrating whoops with a REPL like d11wtq/boris...it's a complicated feature, but something I'd like to integrate as optional, further down the road.

[schickling]

Great!

I'm really interessted in this feature and would like to contribute. I'll contact you.

[jrahmy]

+1 would be a really cool feature, I've used frameworks from other languages with this functionality and it was really helpful

[marcioAlmada]

You should definitely take a look at Boris, a PHP REPL: https://github.com/d11wtq/boris

[hason]

You should prefer PsySH: https://github.com/bobthecow/psysh - a PHP REPL also running on windows.

[hason]

The PHP debugger Tracy has this feature - nette/tracy@59d9c81 You can see it in action http://vimeo.com/72138480

[staabm]

👍 for adding psysh as a repl

[barryvdh]

@hason wow that is pretty cool! Would be great to get some values etc after an exception.

[filp]

The problem with integrating something like this is that it's not (currently, and not planned) possible for whoops to call back to itself between multiple requests in a reliable manner - there's no ties to any underlying routing logic. I can see a REPL working but possibly only with adapters for common routers/frameworks that allow whoops to bind its services to certain endpoints.

Thoughts, @denis-sokolov?

[barryvdh]

Looking at the commit mentioned by @hason, Nette also doesn't use any routing but set's up a listener for a socket connection and keeps the active request running, so it can be access through websockets in javascript.
It does look cool, but it would be very dangerous if you leave this accidentally on in production, because someone could access all personal data..

[hason]

Discussion about integration PsySH to Symfony2 symfony/symfony#10094

[filp]

@barryvdh Security obviously cannot be dismissed, but learning from better_error's experience (Ruby's inspiration to whoops), it's something that should be addressed through documentation/education, and a minimal layer in the implementation (i.e, IP whitelists).

@hason Thanks! I'll look into that

[denis-sokolov]

Besides the direct socket creation, we can always act on a $run->register() method.
We would distinguish our own requests from the query using superglobals and then exit after handling it to prevent the user application from running.
This goes beyond the PrettyPageHandler, and of course it's a hack, but the costs are quite low for a major feature.
I have been pondering this in the context of serving static requests (css, js) safely.

[staabm]

Security obviously cannot be dismissed, but learning from better_error's experience (Ruby's inspiration to whoops), it's something that should be addressed through documentation/education, and a minimal layer in the implementation (i.e, IP whitelists).

thats already the case right now... having the PrettyPageHandler installed on a production system as-is, is a security problem because it reveals a lot of app internals.

[denis-sokolov]

A GitHub issue is a poor medium for a wishlist of features. Moved to the wiki. Feel free to continue using this issue for a discussion.

[filips123]

You could collaborate with PsySH and make online REPL for PHP. See #585.