The new Whoops error handling can be nice but in my case it prevents my development. It stops and shows only the error. In my case I wrote something before the error accured. It did not print that out. In order to work I need to make it die;.
Can I disable Whoops?
I must say in 2.4. for some reason i almost never get the Whoops error but only errors of whoops itself. At some places it worked but it was very random. I cant figure out whats going on and why/when is it doing it.
I like pretty errors but now i only get unhelpful error messages about whoops.
I am quite sad about 2.4. - i was excited about permissions. But i quickly ran into some quite major bugs bugs:
Seems like something very harsh has happened between last beta and 2.4. ? Because paradoxically in beta things seemd to work much better.
You don’t seem to be a lucky guy. 
Maybe break it down and ask about every single error independently here in the forum. It will hopefully help you and if it’s a bug or a common problem it will help the rest of us as well.
I hope you don’t give up on Kirby just yet.
Can you provide some more information how to reproduce this?
Have you already reported this? If not, can you provide some code how to reproduce this?
Of course not, ive been using kirby for three years. I dont know anything faster to develop smaller websites with. I dont plan leave kirby.
Errors are tracked on github and they have milestone in 2.4.1 . The only one that is not is connected to whoops. Which i am not sure how to debug. Probably i am doing something wrong but most of the errors are get are of this type (just text, no whoops)
Fatal error: Uncaught Error: Call to undefined method
Whoops\Handler\PlainTextHandler::generateResponse() in
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php:238
Stack trace:
#0
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Run.php(271):
Whoops\Handler\PrettyPageHandler->handle(Object(ParseError))
#1 [internal function]:
Whoops\Run->handleException(Object(ParseError))
#2 {main}
thrown in /Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php on line 238
Fatal error: Uncaught Error: Call to undefined method
Whoops\Handler\PlainTextHandler::generateResponse() in
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php:238
Stack trace:
#0
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Run.php(271):
Whoops\Handler\PrettyPageHandler->handle(Object(Whoops\Exception\ErrorException))
#1
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Run.php(345):
Whoops\Run->handleException(Object(Whoops\Exception\ErrorException))
#2
/Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Run.php(374):
Whoops\Run->handleError(1, 'Uncaught Error:...',
'/Users/krisa/de...', 238)
#3 [internal function]: Whoops\Run->handleShutdown()
#4 {main}
thrown in /Users/krisa/dev/industra.space/webroot/kirby/vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php on line 238
I looked at the vendor folder - i have everything there. Also kirby is instaled through CLI so there should be no problem there.
I don’t think there is an option to disable Whoops. You can try to comment out line 218 (start the error handler) in /kirby/kirby.php but I’m not sure about any side effects this might have.
Alright. I turned it into a suggestion so we can see if anyone agree with me that an option for it could be a good “feature”.
This is also something I would really like. Whoops is currently not of any help during development. It actually makes debugging more difficult.
An even bigger problem is that on production (where debug is set to false), the entire page is going ‘offline’!
Quote from the changelog:
“…on your production site it displays a nice and clean error page that doesn’t tell attackers anything about the error…”
Why tell there is an error in the first place? Errors where previously suppressed. That doesn’ tell attackers anything either.
Even on something silly like an ‘E_NOTICE’, the entire page is going down. For the visitor, it looks like the site is in maintenance mode and this does not help your SEO either. If there is an unexpected error somewhere/somehow and you don’t notice it yourself for days, weeks, months or years, that is going to cost you…
This is the first time in my life I am messing with the core of any software, but untill there is a fix, I see no other option.
Below is a screenshot of the actual error. There is a link that leads to getkirby.com, thus giving away that the site is running on Kirby. That actually makes things easier for attackers.
because usually your site should be error free 
you can also change the template for that error page in
/kirby/views/fatal.php
If you can guarantee a 100% error free site all the time, you will become a millionaire fast…
I messed around with the core already, but this should never have to be done
I added an issue about it here: https://github.com/getkirby/kirby/issues/514 Because of that I set this topic to solved (solved by adding an issue instead).
Thanks for your input on this.
I dont get it. If you turn off debug mode then you will not get any error messages so for production its not problem no?
jenstornell is conserned about different matter - doing more low level stuff where he needs the error messages but whoops makes it difficult.
Yes, correct! 
I just tried what @ezraverheijen already have found out, that E_NOTICE results in a “maintainance” page.
In header.php I put this code (which will generate an E_NOTICE):
<?php
$test .= 'test';
echo $test;
?>
debug set to true Whoops apears.debug set to false I get the message in the screenshot below:(click for better quality)
I agree that if I’m as a developer is unaware of the E_NOTICE, it’s really bad for SEO (Search Engine Optimization) because that whole page will be taken “offline” (and possibly others with the same template).
If it’s possible it could ignore E_NOTICE (and maybe even E_WARNING) and try to render the page anyway. With E_ERROR I think it can be much more acceptable to have a message like this.
If it would be possible to have a custom template we could write an own text and that way remove the link to Kirby (for security concerns). As a nice side effect, it could be used to monitor error pages, save error urls somewhere on request.
I also suggest that the link is removed in the native template as well. Then most people don’t even need to override it.
That is not a real solution.
I’m really curious about the reason behind the decision. And I’m glad you started this topic, because I believe this is a big issue. I always loved the philosophy of Bastian to keep things simple with Kirby. I don’t know how to explain it, but this does not feel simple. It is not a Kirby-ish feature to me. I don’t understand why taking down whole pages on every error seems like a good idea. I’m confused now 
I’m seriously sorry about the issues you are running in.
@krisa would it be possible that you are using the patterns plugin? Because there’s still an issue with an older version of Whoops running there and which produces that error. I’m about to fix that asap. In fact the version on the develop branch of the patterns plugin should already do.
@jenstornell the idea to turn whoops off entirely is probably a good one and is probably not hard to implement
@ezraverheijen we went for whoops, because we feel that it really helps to find bugs faster, especially for beginners. We also used it to discover small issues more quickly. Especially notice bugs are often ignored but can easily turn into bigger issues or even security risks. But I really don’t wanted this to become that painful, so we might need to consider more options to tweak how whoops behaves. Turning it off would be one things (as already mentioned) but having more control over how it behaves is most definitely also a good idea. It does not necessarily always lead to a full fatal error with the “offline” screen.
We already started working on 2.4.1 and I think we will release it next week. Somehow it seems that the beta for 2.4 didn’t uncover enough of the issues as we hoped for. But I’m confident that we can make all of you happy again soon
@bastianallgeier please don’t be sorry. We all know the Kirby team has only good intentions. We just don’t like this new Kirby debug thingy 
It’s a very good thing to help everyone as much as possible with debugging and keeping their Kirby apps safe. Especially beginners. I fully agree with that. Maybe whoops is good for that, I don’t know. I want to use my own debug stuff, and whoops is ‘in my way’.
My opinion is: only activate whoops when debug is set to true. On production I want all errors to be suppresssed and to just have every page rendered as normal as possible. All other software I have ever worked with does exactly the same. Please don’t forget about all developers who use Kirby on a professional level and have no interest in error pages with, for them at least, useless information. An option to fully disable whoops like @jenstornell mentioned would solve it for us if you want to remain the error page even when debug is set to false.
Or we could add two options:
whoops (enable/disable whoops completely); default is true for “enabled”whoops.live (enable/disable the error page when debugging is disabled); default is true for “enabled”That is a good suggestion!
But what about the debug config option then? I think managing two seperate options will be confusing. Maybe different parameters for the debug option?
Something like:
c::set('debug', true); // normal PHP errors on
c::set('debug', false) // no error showing ever
c::set('debug', 'whoops') // default setting
Just to give an idea…