Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
Hi Folks: On Wed, Mar 14, 2012 at 10:33:59AM -0700, Christopher Jones wrote: In that case, perhaps the STD_PHP_INI_* values should match those in php.ini-development? Many sites have very small ini files and rely on the default ini values for everything else. This means changing the defaults is a bad idea. Adding another ini file containing the defaults is a possibility. But the two ini files shipped already have notations of what's in production, development and default. So the value of adding a default file doesn't seem worth the maintenance overhead. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On Sun, Apr 1, 2012 at 6:25 PM, Daniel Convissor dani...@analysisandsolutions.com wrote: Hi Folks: On Wed, Mar 14, 2012 at 10:33:59AM -0700, Christopher Jones wrote: In that case, perhaps the STD_PHP_INI_* values should match those in php.ini-development? Many sites have very small ini files and rely on the default ini values for everything else. This means changing the defaults is a bad idea. yeah, and those sites would run with magic_quotes enabled, and not receiving the deprecated message, which is what I'm concerned about. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On Wed, March 14, 2012 12:09 pm, Ferenc Kovacs wrote: On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote: On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. I'm +1 if only for the fact that I wouldn't have to research what's different and re-write my (stupid) RFC about E_ALL being the default in PHP_INI_ENTRY* ... I have always presumed that PHP_INI_ENTRY* matched at least one of the two php.ini-* files shipped, actually. Guess that was naive, but it USED to be that way, back in the day, as far as I know... So in terms of expected behavior this can almost be considered a break in BC... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote: On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: hi. We had a discussion about the magic_quotes removal that it is weird that even though that mq was deprecated in 5.3, we still have/had that enabled by default (if you didn't set it from the command line or through a php.ini, the default value which is set from the source by the PHP_INI_ENTRY_* macros). I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. for one thing, this would be less confusing (what do we mean by default? PHP_INI_ENTRY_* or the php.ini? why are they different? etc.), the second thing would be the principle of the fail-secure principle: usually the production settings are more secure and less verbose(display_errors for example). what do you think? of course, if this keeps traction, a proper RFC would be needed, but for now, I'm just throwing ideas. My preference would be to have the defaults be for a production environment. So, if you do absolutely nothing except copy php.exe and a few DLLs, (no ini file), the defaults work to an agreed safe standard. I would envisage that this standard changes over time if weaknesses are found and exploited (I'm not saying there are any). I would then like 1 ini file that only contains specific changes to the defaults for a development environment. I would also like 1 ini file that exactly matches the defaults and that this file must be maintained in line with the internal macros. It would serve as a one stop place to see all the settings as they are defined by the PHP group and could indicate the preference for production and development. So, for a truly lazy developer, it is 1 ini file rename (activate the development environment) and only the agreed entries are amended from the production safe environment, rather than overriding any defaults from the macros, which could have changed and are now out of sync with the INI file. Of course, what is considered safe is for you guys to decide, but with so many settings in the INI files and, as we have seen, disagreement between the internal macros, a little consensus should go a long way to be able to help ISPs and shared hosters have a more uniform standard. 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 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On 03/14/2012 10:09 AM, Ferenc Kovacs wrote: On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote: 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
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On 03/14/2012 10:27 AM, Rasmus Lerdorf wrote: 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. In that case, perhaps the STD_PHP_INI_* values should match those in php.ini-development? Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
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
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
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
Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: hi. We had a discussion about the magic_quotes removal that it is weird that even though that mq was deprecated in 5.3, we still have/had that enabled by default (if you didn't set it from the command line or through a php.ini, the default value which is set from the source by the PHP_INI_ENTRY_* macros). I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. for one thing, this would be less confusing (what do we mean by default? PHP_INI_ENTRY_* or the php.ini? why are they different? etc.), the second thing would be the principle of the fail-secure principle: usually the production settings are more secure and less verbose(display_errors for example). what do you think? of course, if this keeps traction, a proper RFC would be needed, but for now, I'm just throwing ideas. My preference would be to have the defaults be for a production environment. So, if you do absolutely nothing except copy php.exe and a few DLLs, (no ini file), the defaults work to an agreed safe standard. I would envisage that this standard changes over time if weaknesses are found and exploited (I'm not saying there are any). I would then like 1 ini file that only contains specific changes to the defaults for a development environment. I would also like 1 ini file that exactly matches the defaults and that this file must be maintained in line with the internal macros. It would serve as a one stop place to see all the settings as they are defined by the PHP group and could indicate the preference for production and development. So, for a truly lazy developer, it is 1 ini file rename (activate the development environment) and only the agreed entries are amended from the production safe environment, rather than overriding any defaults from the macros, which could have changed and are now out of sync with the INI file. Of course, what is considered safe is for you guys to decide, but with so many settings in the INI files and, as we have seen, disagreement between the internal macros, a little consensus should go a long way to be able to help ISPs and shared hosters have a more uniform standard. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
hi. We had a discussion about the magic_quotes removal that it is weird that even though that mq was deprecated in 5.3, we still have/had that enabled by default (if you didn't set it from the command line or through a php.ini, the default value which is set from the source by the PHP_INI_ENTRY_* macros). I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. for one thing, this would be less confusing (what do we mean by default? PHP_INI_ENTRY_* or the php.ini? why are they different? etc.), the second thing would be the principle of the fail-secure principle: usually the production settings are more secure and less verbose(display_errors for example). what do you think? of course, if this keeps traction, a proper RFC would be needed, but for now, I'm just throwing ideas. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
