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
