Hi!
I've created a voting page for the features in 5.4 TODO list for which
we need to find consensus. Please go there:
https://wiki.php.net/todo/php54/vote
and vote!
See also links to relevant RFCs on the TODO page:
https://wiki.php.net/todo/php54
If something is unclear or you notice a mistake, please write me.
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi:
can we add "Foreach supporting T_LIST token" into this vote?
RFC: https://wiki.php.net/rfc/foreachlist
thanks
2011/7/9 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
I've created a voting page for the features in 5.4 TODO list for which we
need to find consensus. Please go there:
https://wiki.php.net/todo/php54/vote
and vote!See also links to relevant RFCs on the TODO page:
https://wiki.php.net/todo/php54
If something is unclear or you notice a mistake, please write me.Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi!
Hi:
can we add "Foreach supporting
T_LISTtoken" into this vote?
If the author thinks it's mature enough he can put it up to the vote.
One aspect I see that is not covered is if the references would work in
the list and if so - how.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi:
okey,
I have updated the vote wiki page.
thanks
2011/7/11 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
Hi:
can we add "Foreach supporting
T_LISTtoken" into this vote?If the author thinks it's mature enough he can put it up to the vote.
One aspect I see that is not covered is if the references would work in the
list and if so - how.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi Stas,
Do you feel this is the somewhat final list for 5.4 or is will there be
some room for new RFCs (I¹m thinking of Annotations, were an updated RFC
was promised).
With regards,
Lars
Am 09.07.11 08:30 schrieb "Stas Malyshev" unter smalyshev@sugarcrm.com:
Hi!
I've created a voting page for the features in 5.4 TODO list for which
we need to find consensus. Please go there:
https://wiki.php.net/todo/php54/vote
and vote!See also links to relevant RFCs on the TODO page:
https://wiki.php.net/todo/php54
If something is unclear or you notice a mistake, please write me.Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I've created a voting page for the features in 5.4 TODO list for which we need to find consensus. Please go there:
https://wiki.php.net/todo/php54/vote
and vote!See also links to relevant RFCs on the TODO page: https://wiki.php.net/todo/php54
If something is unclear or you notice a mistake, please write me.
Greetings,
I removed the "remove magic quotes" RFC link from this todo/vote page because
this previously accepted RFC is not about removing magic quotes. And I'm the
author of said RFC. It deals with PHP 5.3 which removed get_magic_quotes_*()
so this old RFC restored them into both PHP 5.3+ and PHP 6.
Regards,
Philip
Hi!
this previously accepted RFC is not about removing magic quotes. And I'm the
author of said RFC. It deals with PHP 5.3 which removed get_magic_quotes_*()
so this old RFC restored them into both PHP 5.3+ and PHP 6.
Yes, it's not exactly what is being talked about here. It's more like
this RFC:
https://wiki.php.net/rfc/removal-of-deprecated-features
slightly modifying the patch there according to your proposal (not emit
E_DEPRECATED on gets).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
this previously accepted RFC is not about removing magic quotes. And I'm the
author of said RFC. It deals with PHP 5.3 which removed get_magic_quotes_*()
so this old RFC restored them into both PHP 5.3+ and PHP 6.Yes, it's not exactly what is being talked about here. It's more like this RFC:
https://wiki.php.net/rfc/removal-of-deprecated-features
slightly modifying the patch there according to your proposal (not emitE_DEPRECATEDon gets).
But this topic (removing magic quotes from 5.4) was not proposed on this list, so the vote feels premature. The only related RFC on the matter involves PHP 6, and it isn't specific to MQ. Granted we all don't like MQ, but this "security" feature is enabled by default today so skipping discussion to a simple vote for removal feels wrong.
Regards,
Philip
Hi!
But this topic (removing magic quotes from 5.4) was not proposed on
this list, so the vote feels premature. The only related RFC on the
matter involves PHP 6, and it isn't specific to MQ. Granted we all
don't like MQ, but this "security" feature is enabled by default
today so skipping discussion to a simple vote for removal feels
wrong.
It was proposed 2 weeks ago, along with other items. If you have
anything to add now, please do so.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
But this topic (removing magic quotes from 5.4) was not proposed on
this list, so the vote feels premature. The only related RFC on the
matter involves PHP 6, and it isn't specific to MQ. Granted we all
don't like MQ, but this "security" feature is enabled by default
today so skipping discussion to a simple vote for removal feels
wrong.It was proposed 2 weeks ago, along with other items. If you have anything to
add now, please do so.
for the record, we had a lenghtly discussion back in november:
internals@lists.php.net/msg48407.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg48407.html
the general reception was toward removing it for 5.4, but there were
serious concerns about removing it also.
I would also change my vote, I would go with keeping it deprecated,
but turning it off by default (currently it isn't done, but the
suggested development/production inis have this turned off), and
remove it with the next minor version bump.
if we have minor releases in the same timeframe as between 5.3 and
5.4, I'm fine with this.
hopefully the security documentation will be in the better shape and
we can figure out how to communicate such changes better to minimalize
the impact.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
I would also change my vote, I would go with keeping it deprecated,
but turning it off by default (currently it isn't done, but the
suggested development/production inis have this turned off), and
remove it with the next minor version bump.
Which basically means doing nothing, as the effective default is the
recommended INIs, where it's off. So what would change before now and
then that makes it inacceptable to remove it now but acceptable to
remove it then?
hopefully the security documentation will be in the better shape and
we can figure out how to communicate such changes better to minimalize
the impact.
Our abilities to communicate will probably be in 1 year exactly as they
are now, unless there's some big project to improve it that I'm not
aware of.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I would also change my vote, I would go with keeping it deprecated,
but turning it off by default (currently it isn't done, but the
suggested development/production inis have this turned off), and
remove it with the next minor version bump.Which basically means doing nothing, as the effective default is the
recommended INIs, where it's off. So what would change before now and then
that makes it inacceptable to remove it now but acceptable to remove it
then?
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1
tyrael@chronos:~/checkouts/php/src/php/php-src/branches/PHP_5_4$
./sapi/cli/php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.4.0alpha2-dev
1
it's still on by default (if you don't use a php.ini which disables
it), so you won't get the deprecated message, as it is only ommited
when you change that ini, or call the magic_quotes methods.
AFAIK
hopefully the security documentation will be in the better shape and
we can figure out how to communicate such changes better to minimalize
the impact.Our abilities to communicate will probably be in 1 year exactly as they are
now, unless there's some big project to improve it that I'm not aware of.
where did you get the 1 year? I mentioned the next minor version, I
thinks thats about 2-3 years from now.
I talked with a few people about the improvement of the current
security docs, and it was brough up also, that we would need a better
way to introduce our suggested/introduced changes before rolling out
an RC or a golden release.
the new php.net will be there also, so I'm positive about that we will
have more channels to communicate with the community.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1
Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.
I do in many situations while testing and debugging and that's why the
default values exist.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
tyrael@thor:~/checkouts$ php -n -r 'echo PHP_VERSION."\n";echo
ini_get("magic_quotes_gpc")."\n";'
5.3.6-6~dotdeb.1
1Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.I do in many situations while testing and debugging and that's why the
default values exist.Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
and our own tools use that also: pear and run-tests.php at least.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.I do in many situations while testing and debugging and that's why the
default values exist.and our own tools use that also: pear and run-tests.php at least.
run-tests.php does not use -n by default, there is even a run-tests.php
switch to enabled it specifically.
Derick
Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.I do in many situations while testing and debugging and that's why the
default values exist.and our own tools use that also: pear and run-tests.php at least.
run-tests.php does not use -n by default, there is even a run-tests.php
switch to enabled it specifically.Derick
we are both right, see
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l266
of course this isn't an issue, as we only fetch the PHP_VERSION there.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Nobody runs PHP with -n, who would you do that? INIs are the recommended
setting, if you ignore that, you do it at your own peril.I do in many situations while testing and debugging and that's why the
default values exist.and our own tools use that also: pear and run-tests.php at least.
run-tests.php does not use -n by default, there is even a run-tests.php
switch to enabled it specifically.Derick
we are both right, see
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l266
of course this isn't an issue, as we only fetch thePHP_VERSIONthere.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
oh, I've just read the irc conversation, Philip spotted that we do use
and pass the '-n' to the tests for running the tests.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
I do in many situations while testing and debugging and that's why the
default values exist.
Can't we keep it on topic? Do you need magic quotes when you're
debugging? Do you expect it to have the same value with and without -n?
Does your code rely on magic quotes being on?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I do in many situations while testing and debugging and that's why the
default values exist.Can't we keep it on topic? Do you need magic quotes when you're debugging?
Do you expect it to have the same value with and without -n? Does your code
rely on magic quotes being on?
Stas, you are also guilty in the offtopic charge.
I just answered you what would I change about the current code.
you don't have to agree with me, albeit it is weird, because I was in
the impression that we do turn off the default values for the
deprecated features, but whatever.
sorry for partially hijacking the thread, I expressed what I wanted,
can we move along?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I'm sure this has been discussed, but I'm new here, and uncertain as to
where to go to get caught up.
What's so wrong with magic quotes that they need to be removed from the
language entirely?
Links of advice would be helpful.
Thanks.
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, July 13, 2011 2:40 PM
To: Pierre Joye
Cc: Ferenc Kovacs; Philip Olson; PHP Internals
Subject: Re: [PHP-DEV] [VOTE] 5.4 features vote
Hi!
I do in many situations while testing and debugging and that's why the
default values exist.
Can't we keep it on topic? Do you need magic quotes when you're
debugging? Do you expect it to have the same value with and without -n?
Does your code rely on magic quotes being on?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
To unsubscribe,
visit: http://www.php.net/unsub.php
Am 13.07.2011 21:50, schrieb Moshe, Sam:
What's so wrong with magic quotes that they need to be removed from the
language entirely?
they are idiotic because useless for escaping database inputs
and you need to find out this setting to remove them by
stripslashes() if enabled from some dumb administrator
that is why get_magic_quotes-functions are must not removed to avoid
breaking clean code - but they magic quotes would never be implemented
with a little more thoughts long time ago
if you not remove them and they are enabled you get " in your webpage
output, with open eyes you see permanently sites where this happens
Great responses, all of them.
Thanks everybody for the insight.
Apologies if I veered off topic.
-----Original Message-----
From: Reindl Harald [mailto:h.reindl@thelounge.net]
Sent: Wednesday, July 13, 2011 2:56 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] 5.4 features vote
Am 13.07.2011 21:50, schrieb Moshe, Sam:
What's so wrong with magic quotes that they need to be removed from
the language entirely?
they are idiotic because useless for escaping database inputs and you
need to find out this setting to remove them by
stripslashes() if enabled from some dumb administrator
that is why get_magic_quotes-functions are must not removed to avoid
breaking clean code - but they magic quotes would never be implemented
with a little more thoughts long time ago
if you not remove them and they are enabled you get " in your webpage
output, with open eyes you see permanently sites where this happens
Hello,
Is it possible to add Weak References to this todo list?
https://bugs.php.net/bug.php?id=52318
I've been waiting over a year now for this feature. It's a critical part of
object relational layer mapping and my framework will be broken until it
exists. One of our important customer projects also broke down because my
current work around (simply using an array) leaks huge amounts of memory due
to automatic instance caching similar to the one in the example I typed down
below. I'm also considering switching language since PHP lacks this
important OOP concept.
There does not yet seem to be an RFC for it so I typed down an example that
attempts to look like real-word usage here:
I esteimate that it's pretty simple to implement the theoretical
"SplWeakArray" in the example I wrote if you have a bit of knowledge about
the internals of PHP referencing and garbage collection.
See the Java "WeakReference" for conceptual reference.
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/ref/WeakReference.html
A copy of WeakReference would be a partial solution for me since I rather
need a dictionary of id's mapped to objects. I don't want to go trough an
array all the time and look for indexes that has been set to NULL. That's
the GCs job. Hence the SplWeakArray class.
~Hannes
Hi!
Hello,
Is it possible to add Weak References to this todo list?
https://bugs.php.net/bug.php?id=52318
Probably not for 5.4.0. This looks like a thing that needs an RFC and
discussion (and implementation of course ;).
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I really
need this feature and apparently others feel the same way.
- It would benefit MVC framework design - one of the most common design
pattern for web development. - The ticket has been open for over a year now and it has a lot of votes and
high score. (High priority.) - It's not especially complex. (Easy to implement.)
- It's not a language construct. (Non-controversial.)
- It's already implemented in other OOP languages and has been extensivly
researched. (Non-controversial.) - It could be implemented by adding a single additional Spl class. (Easy to
implement.)
~Hannes
Probably not for 5.4.0. This looks like a thing that needs an RFC and
discussion (and implementation of course ;).Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I
really need this feature and apparently others feel the same way.
We don't even have an RFC on it, let alone consensus & implementation,
and we'd have a beta in a little more than a month. This makes timeframe
for it very hard. There will be other releases, this is not the last one ;)
If we could have RFC and have it agreed upon and have reasonably good
implementation in a month, then we could talk about it. But I wouldn't
rush it. If it's a stand-alone class, it can also got into .1 etc.
release maybe. But I'd start with trunk first.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I really
need this feature and apparently others feel the same way.
- It would benefit MVC framework design - one of the most common design
pattern for web development.- The ticket has been open for over a year now and it has a lot of votes and
high score. (High priority.)- It's not especially complex. (Easy to implement.)
- It's not a language construct. (Non-controversial.)
- It's already implemented in other OOP languages and has been extensivly
researched. (Non-controversial.)- It could be implemented by adding a single additional Spl class. (Easy to
implement.)~Hannes
To expand on Stas's statement, you need to start a practical
discussion of the feature. This should give examples, show where it
will fit in the PHP eco-system, what it will do, and where it will
take the language. Once you have received feedback then create an RFC
with examples (aka future testcases). And somewhere during this
process create a patch or find someone willing to make one.
Also see http://news.php.net/php.internals/52812 and
https://wiki.php.net/rfc/voting
If you're lucky and the idea's good, then you might find it all
happens quickly with minimal effort. Otherwise you will need patience
and perseverance.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Maybe it could be implemented as a PECL package and then on a future version
added to the core of PHP?
2011/7/14 Hannes Landeholm landeholm@gmail.com
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I really
need this feature and apparently others feel the same way.
- It would benefit MVC framework design - one of the most common design
pattern for web development.- The ticket has been open for over a year now and it has a lot of votes
and
high score. (High priority.)- It's not especially complex. (Easy to implement.)
- It's not a language construct. (Non-controversial.)
- It's already implemented in other OOP languages and has been extensivly
researched. (Non-controversial.)- It could be implemented by adding a single additional Spl class. (Easy to
implement.)
I'm sure this has been discussed, but I'm new here, and uncertain as to
where to go to get caught up.
What's so wrong with magic quotes that they need to be removed from the
language entirely?Links of advice would be helpful.
Thanks.
for starters:
http://php.net/manual/en/security.magicquotes.whynot.php
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
there are 3 major problems:
- magic_quotes is magic, it is implicit, you didn't know or care about
it, but if your code depends on it, but you didn't check that it is
turned on or not, your code will be vulnerable in the new environment. - magic_quotes gives you a false sense of security, as it is uses
addslashes, and that doesn't prevent the xss injections for example - addslashes can save you from the sql injection related
vulnerabilities, but as it doesn't care about encodings and couldn't
possibly know what are you using for you db connection, it can be
circumvented: http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
so it is better that nothing, but isn't a 100% safe solution but it
prevents the users from learning the proper way to secure their
applications.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi Stas:
Nobody runs PHP with -n, who would you do that? INIs are the
recommended setting, if you ignore that, you do it at your own
peril.
I've seen many servers that run with php.ini files that have only a few
lines in them, relying on the defaults for most of the behavior.
--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 17 July 2011 02:04, Daniel Convissor
danielc@analysisandsolutions.com wrote:
Hi Stas:
Nobody runs PHP with -n, who would you do that? INIs are the
recommended setting, if you ignore that, you do it at your own
peril.I've seen many servers that run with php.ini files that have only a few
lines in them, relying on the defaults for most of the behavior.--Dan
Why bother having defaults if you don't use them.
My local ini file is 6 lines long. Works perfectly.
If I should be setting an option a certain way every time, then the
default has to be considered incorrect.
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
Hi!
Why bother having defaults if you don't use them.
Err, well, the way PHP ini system works you always have defaults -
something is always stored in the hash.
My local ini file is 6 lines long. Works perfectly.
And you rely on magic_quotes being on, right? Then you have peculiar
definition of "working perfectly".
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Why bother having defaults if you don't use them.
Err, well, the way PHP ini system works you always have defaults - something
is always stored in the hash.My local ini file is 6 lines long. Works perfectly.
And you rely on magic_quotes being on, right? Then you have peculiar
definition of "working perfectly".Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
Stas, could we change the default value?
pretty please?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
Stas, could we change the default value?
pretty please?
We could, but what's the point if we're removing it altogether?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Why bother having defaults if you don't use them.
Err, well, the way PHP ini system works you always have defaults - something is always stored in the hash.
His point was that you consider the distributed php.ini-* files to define the default values,
as opposed to the actual defaults. Defaults are defaults for a reason, and they should not be
dismissed.
My local ini file is 6 lines long. Works perfectly.
And you rely on magic_quotes being on, right? Then you have peculiar definition of "working perfectly".
Nobody here said they rely on magic quotes, and that is not related to what a default value means,
or how they are handled.
Regards,
Philip
Hi!
And you rely on magic_quotes being on, right? Then you have peculiar definition of "working perfectly".
Nobody here said they rely on magic quotes, and that is not related to what a default value means,
or how they are handled.
We're discussing magic quotes. The quote was "My local ini file is 6
lines long. Works perfectly.". So either one of these 6 lines resets
magic_quotes to 0 - which proves my point - or Richard considers
application relying on default of magic quotes - which is on - "working
perfectly", which is just wrong.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
And you rely on magic_quotes being on, right? Then you have peculiar definition of "working perfectly".
Nobody here said they rely on magic quotes, and that is not related to what a default value means,
or how they are handled.We're discussing magic quotes. The quote was "My local ini file is 6 lines long. Works perfectly.". So either one of these 6 lines resets magic_quotes to 0 - which proves my point - or Richard considers application relying on default of magic quotes - which is on - "working perfectly", which is just wrong.
What is the proven point? That people shouldn't use magic quotes? Nobody here is arguing
with that. But dismissing the fact that magic quotes is still enabled by default, because
we distribute php.ini files that disable it, doesn't help. Now, saying it's worth killing
despite it being enabled by default because it's bad and has been throwing E_DEPRECATED
errors since PHP 5.3.0, and that our distributed php.ini files disable it, now that's an
entirely different story. Such an argument would also look up our old php.ini-recommended
settings and see it was disabled there as well. But fact is, nobody has done that, nor has
there been a proper discussion or RFC on this topic for 5.4. The vote was premature. Would
it have turned out differently had we done it properly? Probably, but at least we'd have a
proper reference point for why we removed a security feature that was still enabled by
default.
And to be clear, I am not arguing for or against its removal, but rather, am arguing against
how it was handled. Throwing 10 separate topics (some with and without RFCs) into one thread
is a recipe for non-discussion. That's what happened here, with magic quotes removal being a
part of it.
Regards,
Philip
Hi!
there been a proper discussion or RFC on this topic for 5.4. The vote
was premature. Would it have turned out differently had we done it
properly? Probably, but at least we'd have a proper reference point
for why we removed a security feature that was still enabled by
default.
Magic quotes isn't a security feature. It's a pseudo-security
misfeature. That's exactly why it needs to be gone.
And to be clear, I am not arguing for or against its removal, but
rather, am arguing against how it was handled. Throwing 10 separate
topics (some with and without RFCs) into one thread is a recipe for
non-discussion. That's what happened here, with magic quotes removal
being a part of it.
Nobody prevented anybody from discussing any topic, and removal of magic
quotes was on the agenda since forever. If it's too hard to look at todo
page and read the RFC emails on the list - no problem, but I don't see
what else can be done. If there wasn't enough discussion, maybe because
not enough people cared to discuss it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Why bother having defaults if you don't use them.
Err, well, the way PHP ini system works you always have defaults - something
is always stored in the hash.My local ini file is 6 lines long. Works perfectly.
And you rely on magic_quotes being on, right? Then you have peculiar
definition of "working perfectly".
Currently working really only encompasses running PhD on Windows (new
setup for the new home laptop).
But, in essence, the inability to rely on one default setting
inescapably leads to the inability to rely on any of the defaults. So,
the default values are flawed. And therefore relying on them is
flawed. So bugger me.
So, I HAVE to maintain an INI file that, for the most time, will
have the same values as the built-in defaults, but then having to
constantly maintain it for every release of PHP, rather than just
accepting the defaults.
So why bother having defaults at all? Just store NULLS for everything
and force all settings to be made via the ini file. Hmmm. Overkill?.
So set the default values to appropriate safe/secure values. Hmm. Dev
or Production?
It would seem that my relying on the default values is my fundamental
mistake because the defaults cannot be meaningful for all environments
or are counter to the currently perceived best value (magic_quotes is
still enabled by default? JHC - why? PHP5.3.0 is nearly 3 years old
and yet the default value is still to have them enabled? So the
documentation is clearly incorrect. "This feature has been DEPRECATED
as of PHP 5.3.0.". Nope. The feature is alive and well and if you
don't read alter your ini file to go against the current default value
you are leaving yourself wide open).
A big fuss was made on PHP Classes over the recent announcement of the
plan to deprecate ext/myql. One of the issues raised was about shared
hosting. Do shared hosters set the INI files a certain way? Do they
just rename php.ini-production? Do they just leave things as the
default/built-in? Do they care?
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
hi,
Currently working really only encompasses running PhD on Windows (new
setup for the new home laptop).But, in essence, the inability to rely on one default setting
inescapably leads to the inability to rely on any of the defaults. So,
the default values are flawed. And therefore relying on them is
flawed. So bugger me.So, I HAVE to maintain an INI file that,
I agree, I agree now and I agreed in the past that default values
should reflect our policies or changes.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org