On Wed, Mar 14, 2012 at 6:27 PM, 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 > > imo the average developer will have php installed through some wamp stack or the distribution/package manager of his platform, so he/she will have a php.ini with some sane defaults. another idea coming from Philip is to have a php.ini-default which could match with the hard-coded defaults. either way, I think it would be really nice to have a php.ini which we could refer as default in the documentation, and people shouldn't need to look up the php-src to figure out what are the hard-coded defaults and how those are different from the production/development values. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
