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
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
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadling@gmail.comwrote:
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 thephpinfo()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
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadling@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 thephpinfo()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/lFnVeabump
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
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.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Hi Folks:
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
On Sun, Apr 1, 2012 at 6:25 PM, Daniel Convissor <
danielc@analysisandsolutions.com> wrote:
Hi Folks:
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
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 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 thephpinfo()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/lFnVeabump
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
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 thephpinfo()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/lFnVeabump
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
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling
rquadling@gmail.comwrote: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-xclick&hosted_button_id=FS9NLTNEEKWBE