Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58931
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F60D511.1050802@lerdorf.com>
References: <CAH-PCH5jJ1ctJy6kZcyMLxSKyJs=+pA8ivB89MEzQtKfJWiHMQ@mail.gmail.com>
	<CAKUjMCW+j=fL4oS1+cQ6QMy1ZGPK-sy=af7gnL2NJq86_yh4Vg@mail.gmail.com>
	<CAH-PCH7WKbvPPU1N0uuFB416Sf_tpG+w++kRgdRgnZRexG=PJw@mail.gmail.com>
	<4F60D511.1050802@lerdorf.com>
Date: Wed, 14 Mar 2012 10:36:23 -0700
Message-ID: <CAKOpQSxv26MtjbWEZw2X+R67mpzD2ZEkOukZ2YXD_e6i5J9hJw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, RQuadling@gmail.com, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044304ec0f2ce104bb376af6
Subject: Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
From: kris.craig@gmail.com (Kris Craig)

--f46d044304ec0f2ce104bb376af6
Content-Type: text/plain; charset=ISO-8859-1

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 <rasmus@lerdorf.com> wrote:

> On 03/14/2012 10:09 AM, Ferenc Kovacs wrote:
> > On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling <rquadling@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
>
>

--f46d044304ec0f2ce104bb376af6--