Hi,
i would once more vote for removing this nasty @s
if it is really a problem for you we could disable displaying of errors in common.lib.php
or using ob_*() function to catch all output till and of common.lib.php and
@ does not only hide error messages from being displayed but also hides them from being logged
just disabling display errors can also lead to the same problem if logging of errors is also disabled
if using ob_*() we can catch all output (where no output should happen) and check this - and than can present the user that there are some errors occurred and they should check there error log file and/or enable it and/or tell the administrators about this
ob_*() is fine till no 'official' output is happening - but later this is not possible - so we could also use our own error-handler
any opinions?
Sebastian Mendel a écrit :
Hi,
i would once more vote for removing this nasty @s
if it is really a problem for you we could disable displaying of errors in common.lib.php
or using ob_*() function to catch all output till and of common.lib.php and
@ does not only hide error messages from being displayed but also hides them from being logged
just disabling display errors can also lead to the same problem if logging of errors is also disabled
if using ob_*() we can catch all output (where no output should happen) and check this - and than can present the user that there are some errors occurred and they should check there error log file and/or enable it and/or tell the administrators about this
ob_*() is fine till no 'official' output is happening - but later this is not possible - so we could also use our own error-handler
any opinions?
Hi Sebastian, I have an opinion ... and facts :)
Opinion: I agree with you ... in theory.
Facts: Nexen Services are doing a poll of servers running PHP and they were able to sample 11000 of them. This is not a large percentage over the millions of servers, but it's a rather large population. Look what they found in November 2006:
http://www.nexen.net/images/stories/phpinfos/display_errors.png
So, what would happen for users of these 80% servers if we remove the @'s ?
Remember that in many cases, the user of phpMyAdmin does not control his server's settings.
Marc
Marc Delisle wrote:
So, what would happen for users of these 80% servers if we remove the @'s ?
Remember that in many cases, the user of phpMyAdmin does not control his server's settings. n-devel
display_errors is not server dependent at all:PHP_INI_ALL of course you have to take measures that no unwanted errormessages clutter the screen. the user/admin desired display_errors level could easily be set in config.inc.php.
just my 2 cent
Jürgen Wind a écrit :
Marc Delisle wrote:
So, what would happen for users of these 80% servers if we remove the @'s ?
Remember that in many cases, the user of phpMyAdmin does not control his server's settings. n-devel
display_errors is not server dependent at all:PHP_INI_ALL
PHP_INI_ALL does not automatically imply that end users can do the change. A server can be configured to ignore .htaccess and to disable ini_set() command.
This is why I wrote "in many cases, the user...".
Marc
of course you have to take measures that no unwanted errormessages clutter the screen. the user/admin desired display_errors level could easily be set in config.inc.php.
just my 2 cent
Marc Delisle wrote:
Jürgen Wind a écrit :
Marc Delisle wrote:
So, what would happen for users of these 80% servers if we remove the @'s ?
Remember that in many cases, the user of phpMyAdmin does not control his server's settings. n-devel
display_errors is not server dependent at all:PHP_INI_ALL
PHP_INI_ALL does not automatically imply that end users can do the change. A server can be configured to ignore .htaccess and to disable ini_set() command.
This is why I wrote "in many cases, the user...".
Marc
of course you have to take measures that no unwanted errormessages clutter the screen. the user/admin desired display_errors level could easily be set in config.inc.php.
just my 2 cent
i *think* you are mistaken. I 'm not talking of .htaccess, display_errors level is not only changable by "PHP_INI_SYSTEM" but on *any* level, especially from the php script itself.
plz show me where i can be convinced by the opposite.
Jürgen Wind a écrit :
Marc Delisle wrote:
Jürgen Wind a écrit :
Marc Delisle wrote:
So, what would happen for users of these 80% servers if we remove the @'s ?
Remember that in many cases, the user of phpMyAdmin does not control his server's settings. n-devel
display_errors is not server dependent at all:PHP_INI_ALL
PHP_INI_ALL does not automatically imply that end users can do the change. A server can be configured to ignore .htaccess and to disable ini_set() command.
This is why I wrote "in many cases, the user...".
Marc
of course you have to take measures that no unwanted errormessages clutter the screen. the user/admin desired display_errors level could easily be set in config.inc.php.
just my 2 cent
i *think* you are mistaken. I 'm not talking of .htaccess, display_errors level is not only changable by "PHP_INI_SYSTEM" but on *any* level, especially from the php script itself.
If the sysadmin allows it. A sysadmin might use this in php.ini:
disable_functions = error_reporting, ini_set
plz show me where i can be convinced by the opposite.
Marc Delisle wrote:
i *think* you are mistaken. I 'm not talking of .htaccess, display_errors level is not only changable by "PHP_INI_SYSTEM" but on *any* level, especially from the php script itself.
If the sysadmin allows it. A sysadmin might use this in php.ini:
disable_functions = error_reporting, ini_set
plz show me where i can be convinced by the opposite.
thank you! I was not aware of that, it was not mentioned on the manual/en/ini.php#ini.list page. But this is not what was checked by www.nexen.net/images/... Before trying to set the error_reporting level one could check by "if function exists" or any probing; if true: use Sebastian's suggested method, old "@" style else.
but it's up to you :)
-
Jürgen Wind -
Marc Delisle -
Sebastian Mendel