I'm curious: What would be the implications of having a third option to display a generic "catch-all" error instead of a blank page? For example, something like, "An error has occurred. Please check your server's error log for details." That would significantly reduce the confusion factor for inexperienced devs while, at least presumably, not presenting any security risk because no details are actually being included.
--Kris On Wed, Mar 14, 2012 at 10:27 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 03/14/2012 10:09 AM, Ferenc Kovacs wrote: > > On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling <rquadl...@gmail.com > >wrote: > >> Maybe, and this is right of the top of my head, if PHP is installed > >> for a production environment with no INI file, or if an ini file > >> doesn't alter any of the core settings (maybe a separation of INI > >> files for core and extensions?), it could be labelled/considered as a > >> virgin PHP install. Something which could be marketed / advertised. > >> Essentially, the PHP Group agree that for a production environment, > >> these are the settings that are the safest to use. If there are > >> considerations that need to be made for shared hosters, then maybe > >> some mechanism to set these appropriately. So, for a user coming to an > >> ISP and looking at hosting, they can see "We use Virgin PHP Settings" > >> or something like that and know that they won't be different to a > >> documented "standard". Add this labelling to the phpinfo() page and it > >> makes things very very clear what is in play. > >> > >> Richard. > >> > >> -- > >> Richard Quadling > >> Twitter : EE : Zend : PHPDoc > >> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea > >> > > > > bump > > The biggest problem with the concept of virgin PHP settings being geared > for production is that by definition that isn't very developer friendly. > Keeping the learning curve shallow has always been a goal for PHP which > is why things like display_errors exist. A new developer may not have > any idea where to look for PHP errors and might give up when all he gets > is a blank page. > > The assumption is that by the time you are ready to put something into > production you have spent a little bit of time with PHP and you likely > have stumbled across the suggested production php.ini which is then > trivial to apply. > > -Rasmus > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
