>> If the bug #48583 can't be accepted through bugs.php.net, I think it >> makes >> sense to discuss it here. > > It's not a bug but "chicken'n'egg'" issue. Errors are displayed by default > (IIRC) so if the ini file does not get parsed an error is outputted which > IS > --Jani
I don't agree, absolutely. Settings are more important and should be parsed/loaded first. If any error happens before this phase is complete, they should be captured and buffered for later processing, unless the error is fatal. After the settings are loaded, all buffered errors should be processed and handled according to the settings. Nothing else. Do you see any problems with this approach? Where is the promissed chicken&egg issue? :) > really good thing. Just fix that damn ini file. :) Sorry, but seems you do not understand the situation. How would an admin fix that damn ini file if the errors are not appearing in the log????? Say, I'm a hosting company admin. I install packages, php in particular, make changes to configs, etc. I do not know what web sites are running and do not want to see if anything related to my work appear in their pages. Never. What steps am I supposed to do to see that php.ini contains bogus #? Take in to account that some of the errors do not appear in the output at all. They are crashing php because passed to the handler too early. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
