Hey there folks, one quick question:
When creating my error handling pages, in the documentation there’s a parameter for a debug mode:
request.params.debug
However, this debug mode is never mentioned in the documentation.
Where can I set this debug mode to false?
Does it impact something on the performance of the server? Our production server has this set to true.
Thanks!
There is no debug mode. But maybe the example for error handling is misleading.
The check for request.params.debug in the script just checks for a standard parameter in the request. The idea was that you can set a custom error page for the users visiting the site, in case something goes wrong. So that they don’t get the ugly stacktrace red-background error page. But by adding ?debug=true at the end of the request URL, the developer can skip the custom page and see the stacktrace, for debugging purposes.
But all this is just an example of error.js script, there is nothing built in XP that supports a debug mode.
XP does have a Development mode, but that is something else. It’s a running mode in which the developer does not need to re-deploy the app so often during development time. This development mode actually has an impact on performance, so it must not be enabled on production. But as mentioned above, it has nothing to do with the debug parameter in the error handling example.
I see. The problem is that, request.params.debug is always true, even when no debug parameter is set. That’s why I asked about a debug mode. But anyway, thanks making it clear 
Strange. We at least don’t set any “debug” param in XP.
Maybe it is set from a filter script in your app, or another app configured for the site?
I initially made debug using url parameters. I have since moved to http headers and a more granular approach.
Now I can choose to only log the request, the page model, trace the layout body, profile some filter, debug a specific part config, etc…
Or just slap all into the header and log everything.
No filters, and only a single app there. I wanted to use it as a way to distinguish the logs between our production server and our development server (where usually a debug mode is available), and it returns true to all kinds of errors enonic is trowing.