RFC: Change default of XH_debugmode()

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

RFC: Change default of XH_debugmode()

Post by cmb » Thu Jan 23, 2014 3:00 pm

Hello Community,

rather often there are support requests regarding white/blank browser windows. The usual way to track down the problem is to activate debug mode, but many users are not aware of that. It would be best if CMSimple_XH was able to show an appropriate message after the error had occurred, but unfortunately that is not possible for fatal errors (E_ERROR etc.), which are most often the cause of the white screen.

So I suggest that we change the default of XH_debugmode() (i.e. when no file _XHdebug.txt is found) to something that displays such errors. As the errors are displayed in admin mode only, anyhow, this is no potential security issue, and usually users are better of to receive an error message instead of a blank browser window (even if the error message won't help them directly).

I'm not quite sure which error types should be used as default, however something like the following might be appropriate:

Code: Select all

E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | E_RECOVERABLE_ERROR
Maybe it's reasonable to suppress E_RECOVERABLE_ERRORS, because the constant was introduced in PHP 5.2 only (working around won't be hard, though), and because they seem to be very rare (I've never got one of these).

We might consider to revise the current debug levels, BTW.

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

svasti
Posts: 1651
Joined: Wed Dec 17, 2008 5:08 pm

Re: RFC: Change default of XH_debugmode()

Post by svasti » Thu Jan 23, 2014 10:50 pm

Seems to be a good idea.
May have the side effect to force some plugin authors to write plugins that don't produce error notices.
What about the additional long red-brown div [Debug-Mode is enabled!] above the admin menu?

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: RFC: Change default of XH_debugmode()

Post by Holger » Thu Jan 23, 2014 11:26 pm

cmb wrote:As the errors are displayed in admin mode only
:?:
Parse_Errors are visible to the visitor with default debug-mode enabled. Just checked it again right now.
svasti wrote:May have the side effect to force some plugin authors to write plugins that don't produce error notices.
Or to put a bunch of '@' to their code.
IMO most plugin-devs today have error_reporing enabled while developing a plugin.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: RFC: Change default of XH_debugmode()

Post by cmb » Thu Jan 23, 2014 11:55 pm

Holger wrote:
cmb wrote:As the errors are displayed in admin mode only
:?:
Parse_Errors are visible to the visitor with default debug-mode enabled. Just checked it again right now.
Yes, you're right (E_ERRORs, too, BTW). :oops: Still, I'd be happy if we can find some viable solution here.
Holger wrote:
svasti wrote:May have the side effect to force some plugin authors to write plugins that don't produce error notices.
Or to put a bunch of '@' to their code.
IMO most plugin-devs today have error_reporing enabled while developing a plugin.
Defaulting to real errors as suggested wouldn't show notices and warnings, but I agree with Holger that it's likely that most plugin developers already develop in debug mode. It seems to me that most warnings, notices and so on are caused by plugins which are not maintained anymore.

I've already stated my opinion regarding the @ operator in another thread.
svasti wrote:What about the additional long red-brown div [Debug-Mode is enabled!] above the admin menu?
Um, I'm not sure. It wastes some space, but gives useful feedback that debug mode is enabled, even if there are no errors reported.
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: RFC: Change default of XH_debugmode()

Post by Holger » Fri Jan 24, 2014 11:26 am

cmb wrote:Still, I'd be happy if we can find some viable solution here.
Hmm,
IMO error_reporting should be set to E_ALL while developing. But on a production installation display_errors should always be disabled[1]. If a user isn't aware about the built in debug-mode, it's maybe a good idea to provide a "support-request-barebone" here at the board. A lot of other projects have something like that. It could contain all the questions one need to know for support and where/how the user find these informations.

[OT]
cmb wrote:I've already stated my opinion regarding the @ operator in another thread.
Of course. But my comment was not thought just as a joke. I've stumbled last days over an extension under active development, which BTW is thought to deal with sensitive informations, where a lot of warnings about uninitialized GPC variables are suppressed with the @-operator instead of initialize them with safe default values. Too bad that some people still not have understand that many security vulnerabilities are the result of uninitialized variables. Fortunately register_globals is now off by default, otherwise ...
[/OT]
cmb wrote:
svasti wrote:What about the additional long red-brown div [Debug-Mode is enabled!] above the admin menu?
Um, I'm not sure. It wastes some space, but gives useful feedback that debug mode is enabled, even if there are no errors reported.
I think some notification is useful. If we don't want to waste so much space (only while debugging or developing some code) it's maybe an option to put an icon to the admin-menu? But for me the red-brown bar is fine to find the right browser-window while developing or testing with a lot of open tabs/windows :) .
Last edited by Holger on Fri Jan 24, 2014 11:55 am, edited 2 times in total.
Reason: [1] Link to phpsec.org added

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: RFC: Change default of XH_debugmode()

Post by cmb » Fri Jan 24, 2014 12:03 pm

Holger wrote:IMO error_reporting should be set to E_ALL while developing. But on a production installation display_errors should always be disabled.
ACK
Holger wrote:If a user isn't aware about the built in debug-mode, it's maybe a good idea to provide a "support-request-barebone" here at the board. A lot of other projects have something like that. It could contain all the questions one need to know for support and where/how the user find these informations.
Well, I've set up an article in the Wiki regarding debug mode some time ago. I'm pointing to this article as answer to a lot of support requests. However, this costs always one round-trip. (Q: I've getting a blank screen. A: What reports the debug mode.)

[OT]
Holger wrote:
cmb wrote:I've already stated my opinion regarding the @ operator in another thread.
Of course. But my comment was not thought just as a joke. I've stumbled last days over an extension under active development, which BTW is thought to deal with sensitive informations, where a lot of warnings about uninitialized GPC variables are suppressed with the @-operator instead of initialize them with safe default values. Too bad that some people still not have understand that many security vulnerabilities are the result of uninitialized variables. Fortunately register_globals is now off by default, otherwise ...
I was aware that you were not joking. It's good that you mention potential security issues wrt. to using the @ operator. However, even if register_globals defaults to off since PHP 4.2 and has been removed since PHP 5.4, there might still be issues when the @ operator is used to silence $_GET[], $_POST and other user supplied input.

Currently, we only have a few recommendations for extension developers (wrt. avoiding clashes and general coding style). It seems appropritate to revise and extend these. However, reviewing and enforcing them might not be possible.
[/OT]
Christoph M. Becker – Plugins for CMSimple_XH

svasti
Posts: 1651
Joined: Wed Dec 17, 2008 5:08 pm

Re: RFC: Change default of XH_debugmode()

Post by svasti » Fri Jan 24, 2014 3:01 pm

So I guess we don't change the debug mode for now. It's working fine for me.

Maybe we should put a notice up on cmsimple-xh.org:

... if you are running into problems and a blanc screen show instead of a website, rename downloads/XHdebug.txt to downloads/_XHdebug.txt, read the error message and ask for help at the forum
.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: RFC: Change default of XH_debugmode()

Post by cmb » Mon Jan 27, 2014 10:44 pm

svasti wrote:Maybe we should put a notice up on cmsimple-xh.org:

... if you are running into problems and a blanc screen show instead of a website, rename downloads/XHdebug.txt to downloads/_XHdebug.txt, read the error message and ask for help at the forum.
I have some doubts that this will help much -- often these blank screens appear long after a user has installed CMSimple_XH (e.g. after the provider upgraded to a newer PHP version, or after the user installed a plugin later on). And after all, the more hints and information there is to read, the less will be read, let alone remembered.

Anyway, I noticed several potential quirks of the debug mode, and I'll come up with a thorough analysis ASAP. There might be a viable solution to the problem by separating concerns (quick idea: E_ERROR is never be handled by XH_debugMode(), so we might put it out of debug mode; neither error_reporting() nor display_errors seem to be necessary for XH_debugMode() at all; so we might consider to activate display_errors with an appropriate error_reporting() for admin mode only).
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: RFC: Change default of XH_debugmode()

Post by Holger » Tue Jan 28, 2014 12:25 am

cmb wrote:so we might consider to activate display_errors with an appropriate error_reporting() for admin mode only).
Seems to be reasonable. But I have some doubts:
  • display_errors should be off by default, because there are really some production-servers where warnings/errors are visible by default
  • if there's no chance to turn on display_errors "from outside", and visibility is by default only in admin-mode, how will you get a fatal_error message when calling the page and you can't login anymore? In case of a support request by a user things getting harder than now...
  • if display_errors is always on in admin_mode, developing will get hard if another (old) plugin throws some warnings and e.g. therefore headers are sent. So that must be IMO easy to configure
After all, I can't get what's so bad with the external text-file :?

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: RFC: Change default of XH_debugmode()

Post by cmb » Tue Jan 28, 2014 11:57 am

Holger wrote:After all, I can't get what's so bad with the external text-file :?
IMO nothing. On the contrary, it has been a very good idea and it's very useful. :)
Holger wrote:display_errors should be off by default, because there are really some production-servers where warnings/errors are visible by default
ACK.
Holger wrote:if there's no chance to turn on display_errors "from outside", and visibility is by default only in admin-mode, how will you get a fatal_error message when calling the page and you can't login anymore? In case of a support request by a user things getting harder than now...
Good point! As it seems to be unnecessary for debug mode to have activated display_errors, this activation might be triggered otherwise (maybe by another file: if (XH_ADM || file_existst(...)). However, enabling display_errors while not in admin mode, might not be the best idea, and should be only done for exeptional cases.
Holger wrote:if display_errors is always on in admin_mode, developing will get hard if another (old) plugin throws some warnings and e.g. therefore headers are sent. So that must be IMO easy to configure
Good point again! However, that might force the plugin developers to use the debug mode, in which case such notices and warnings would be caught by the error handler. The impact for end-users would be higher, but in this case error_reporting() should be deliberately set for "real" errors only.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply