php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #54537 production value for html_errors should be On
Submitted: 2011-04-15 12:18 UTC Modified: 2011-12-04 23:23 UTC
From: tyra3l at gmail dot com Assigned: tyrael (profile)
Status: Closed Package: *Configuration Issues
PHP Version: 5.3.6 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tyra3l at gmail dot com
New email:
PHP Version: OS:

 

 [2011-04-15 12:18 UTC] tyra3l at gmail dot com 
Description:
------------
I've noticed, that we suggest setting the html_errors in production to Off, which 
is an odd thing: in production one should display errors, but if he does, then I 
can't see why would be more appropriate not to use html errors.
could you elaborate on this please?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-04-15 17:04 UTC] derick@php.net 
I agree. There is no reason why html_errors should be off in any case. Especially because the reasoning is non-sense.
 [2011-04-15 21:47 UTC] dtajchreber@php.net 
Is a dynamic plain text web page that hard to imagine? What about non browser 
output? I know the CLI SAPI has html_errors = 0 hard coded in but why force people 
to turn off an option that provides little to no benefit...
 [2011-04-15 22:16 UTC] tyra3l at gmail dot com 
sorry, I can't follow you.
"Is a dynamic plain text web page that hard to imagine?"
no, but the majority of the php sites out there use html as the primary output 
type.
you can turn off the html_errors if you are dealing with plain text files.

"I know the CLI SAPI has html_errors = 0 hard coded in but why force people 
to turn off an option that provides little to no benefit..."
so only the apache SAPI would be affected, where the majority of the users use 
html output.

but I think that this option should affect anything in a production system, 
because you turn off the error_reporting in production (and PHP also suggests 
that, so any distribution which follows the suggestions of the php.ini-* files 
wouldn't be affected by this change. at all)

and both error_reporting and html_errors is enabled in the php.ini-development, 
so for the text/plain people that would be a problem also.

Tyrael
 [2011-04-15 22:31 UTC] tyra3l at gmail dot com 
probably you know, but you can re-enable html_errors for cli via ini_set:
http://www.php.net/manual/en/features.commandline.differences.php
for example:
php -d display_errors=1 -d error_reporting=-1 -r 'ini_set("html_errors", 
1);trigger_error("foo", E_USER_NOTICE);'

Tyrael
 [2011-12-04 23:23 UTC] tyrael@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: tyrael
 [2011-12-04 23:23 UTC] tyrael@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

fixed in 5.4:
https://wiki.php.net/rfc/error-formatting-for-developers
http://svn.php.net/viewvc?view=revision&revision=314761
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Oct 08 21:01:27 2024 UTC