Three values for a boolean option are always difficult to get right and hard to understand in my opinion. I think all “Whoops-related options” should be together.
Agreed. Some software platforms are unforgiving with errors in production, and it can be a good thing, but the production error page is not a good fit for Kirby (at least not activated by default).
[quote=“ezraverheijen, post:18, topic:5726”]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.
[/quote]
I’m not sure what you mean. I just followed a stack trace in Whoops to understand where things went south in the application flow. That’s not useless information and Whoops is clearly a professional tool.
I don’t understand what “live” means here.
To clarify: I think the “maintenance screen of death” shown by Kirby 2.4.0 when debug is false should be an option, and off by default. If it can also be set with a less strict threshold (like skipping E_NOTICE), that would be great.
Yes i completely forgot about that issue. I am using patterns plugin.
As mentioned by @abroess there is no develop branch :). Ive managed to fix stuff i needed without debug messages :)) and i am looking forward for patterns plugin update.
Btw Patterns/Modules plugins are just the best. Kirby should advertise it more - on kirby site it looks like simple CMS. With user permissions and Modules its very easy to build very sophisticated custom website builders. Combined with patterns if set correctly you also have living style guide while reusing the same code and doing very little additional work. I currently dont know about anything what would allow so fast dev experience (and i try almost every open-source web framework/cms written in php or node i find).
1 Like
I think it’s far to also include the comment from @samnabi
I agree that there should be an option to disable Whoops, and it would also be nice to define different error levels that trigger it (i.e. enable for E_NOTICE on development server only).
[Panel] Save bar contrast · Issue #514 · getkirby/kirby · GitHub
…and here is my suggestion…
Whoops options
c::set('whoops.private', true);
c::set('whoops.public', true);
I agree with @lukasbestle that whoops is a nice prefix. I also think that it can be confusing to mix options at different “levels”. Therefor I suggest having two options on the same level.
whoops.private
When debug is true and we are probably on a private development environment. Only true or false are allowed.
whoops.public
When debug is false and we are probably on a public live environment. Only true or false are allowed.
Trigger options
c::set('whoops.private.trigger', [E_ERROR, E_WARNING, E_NOTICE]);
c::set('whoops.public.trigger', [E_ERROR]);
I also added options for which error codes should trigger Whoops. These options should only work when whoops.private or whoops.public is true.
whoops.private.trigger
It will trigger Whoops to run if there is an error., warning or notice.
whoops.public.trigger
It will only trigger Whoops to run if there is an error. On warnings and notices it will not run.
Maintenance template
Even if the link to getkirby.com is on the maintenance (live error message) screen will be removed, it will still give it away in terms of design and text content. It could be a possible security concern.
With the possibility to disable it completely we can get around it, but maybe we want it for some types of errors. Then I suggest that this screen is a template itself, just like error.php. I would call it:
site/templates/maintenance.php
If it exists, use it, else use the one from the core.
1 Like
IMHO, that results in too many options. I wouldn’t call it private and public, either, but rather development and production/live.
A config option that ‘guesses’ what another setting is, seems very dangerous to me.
How does a config file know if it is on a development or production environment? 
I don’t know the best solution here, but two debug related config options (debug and whoops) is confusing.
Well, the config.php file is probably not yet intelligent enough, but you can have config files for multiple environments.
1 Like
I know about the environment configs, but I don’t understand why you need a ‘whoops.live’ setting if you have environment specific configs.
Or are you suggesting that if the file name is not “config.php”, then it must be production and therefore whoops has to be deactivated? That is also guessing. We work with DTAP environments here and we want debugging activated on the D and the T, but not on the A and the P.
The whoops.live setting is probably wrongly named, as it is supposed to refer to displaying of the error page only, so whoops.errorPage would be a more fitting name.
Ah, I see what you mean now 
the name was indeed confusing to me.
But I guess someone smart still has to come up with a way to ‘merge’ the debug and whoops setting somehow…
In the easiest case, we only need two options:
-
debug - true/false
-
whoops - true/false
-
if debug == true and whoops == true: Show errors using Whoops
-
if debug == true and whoops == false: Show errors without Whoops
-
if debug == false and whoops == true: Show Whoops error page
-
if debug == false and whoops == false: Do not show Whoops error page
11 Likes
That’s a great solution! Not too complex and backwards-compatible.
1 Like
BTW: use the CLI to switch to the dev version in a second:
kirby update --dev
3 Likes