Hello everyone-
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Regards,
Philip
hi Philip,
Hello everyone-
PHP 5.3 is approaching fast, so let's conclude our dealings with magical
quotes... this should be the last time. Please have a look at the following
RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means you're
okay with the RFC being implemented.
We already agreed on restoring them in HEAD but with a warning
(instead of the fatal error introduced by the removals). We still
leave the E_DEPRECATED
in 5.3 as it is actually deprecated.
Cheers,
hi Philip,
On Tue, May 20, 2008 at 9:55 PM, Philip Olson philip@roshambo.org
wrote:Hello everyone-
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical
quotes... this should be the last time. Please have a look at the
following
RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're
okay with the RFC being implemented.We already agreed on restoring them in HEAD but with a warning
(instead of the fatal error introduced by the removals). We still
leave theE_DEPRECATED
in 5.3 as it is actually deprecated.
I disagree that we agreed on this, as our last discussion was murky at
best. Getting and setting are totally different and should be
clarified as such... the RFC does this.
Regards,
Philip
hi Philip,
Hello everyone-
PHP 5.3 is approaching fast, so let's conclude our dealings with magical
quotes... this should be the last time. Please have a look at the
following
RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means you're
okay with the RFC being implemented.We already agreed on restoring them in HEAD but with a warning
(instead of the fatal error introduced by the removals). We still
leave theE_DEPRECATED
in 5.3 as it is actually deprecated.I disagree that we agreed on this, as our last discussion was murky at best.
Getting and setting are totally different and should be clarified as such...
the RFC does this.
You can disagree if you wish, point is that this change is in my todos
as discussed in our last discussions (where Andi and all
participated). Don't get me wrong, the RFC is a good thing, I only try
to avoid yet another FUD about this topic.
Cheers,
Philip Olson wrote:
PHP 5.3 is approaching fast, so let's conclude our dealings with magical
quotes... this should be the last time. Please have a look at the
following
RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means you're
okay with the RFC being implemented.We already agreed on restoring them in HEAD but with a warning
(instead of the fatal error introduced by the removals). We still
leave theE_DEPRECATED
in 5.3 as it is actually deprecated.I disagree that we agreed on this, as our last discussion was murky at
best. Getting and setting are totally different and should be clarified
as such... the RFC does this.
magic quotes goes in PHP6 - if you want it gone get behind PHP6 and lets stop
further delaying tactics by producing yet another unnecessary branch of PHP5!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
+1 here
A summary:
PHP6 MUST not allow setting magic quotes
PHP6 MUST trigger a fatal error when attempting to set magic quotes (php.ini
or set_magic_quotes_runtime())
PHP6 MUST allow getting magic quotes info (always false)
PHP5.3 MUST allow setting magic quotes
PHP5.3 MUST trigger an E_DEPRECATED
warning when setting magic quotes
(php.ini or set_magic_quotes_runtime())
PHP5.3 MUST allow getting magic quotes info
-----Original Message-----
From: Philip Olson [mailto:philip@roshambo.org]
Sent: May 20, 2008 3:56 PM
To: PHP internals
Subject: [PHP-DEV] magic quotes finale
Hello everyone-
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Regards,
Philip
2008/5/20 Jonathan Bond-Caron jbondc@openmv.com:
+1 here
A summary:
PHP6 MUST not allow setting magic quotes
PHP6 MUST trigger a fatal error when attempting to set magic quotes (php.ini
or set_magic_quotes_runtime())
PHP6 MUST allow getting magic quotes info (always false)PHP5.3 MUST allow setting magic quotes
PHP5.3 MUST trigger anE_DEPRECATED
warning when setting magic quotes
(php.ini or set_magic_quotes_runtime())
PHP5.3 MUST allow getting magic quotes info
A small heads-up, with the latest snapshot for windows, 5.3.0-dev
gives a E_DEPRECATED
error for get_magic_quotes_runtime()
.
Richard.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
Well, if silence is void: TAKE IT OFF!!! (+1 ... once again on this subject)
--
Slan,
David
Hi David,
Am Donnerstag, den 22.05.2008, 18:14 -0400 schrieb David Coallier:
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.Well, if silence is void: TAKE IT OFF!!! (+1 ... once again on this #subject)
You've spotted that the proposal is not about the question if they
should be removed? It is about how to remove them :-)
cu, Lars
Lars Strojny wrote:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.Why should we leave
get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
We have covered this a bunch of times already. magic_quotes_gpc are
gone, but we leave in the function that tells userspace code that they
are off. get_magic_quotes_gpc()
will always return false which means
that thousands of applications out there will run unchanged and will
simply take the magic_quotes off code path.
I see absolutely no reason to force people to go through and change:
if(!get_magic_quotes_gpc())
to:
if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc())
when there is no technical reason to force them to do so. It is slower,
more verbose and completely useless.
-Rasmus
Hi Rasmus,
Lars Strojny wrote:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]PHP 5.3 is approaching fast, so let's conclude our dealings with magical
quotes... this should be the last time. Please have a look at the following
RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means you're
okay with the RFC being implemented.Why should we leave
get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.We have covered this a bunch of times already. magic_quotes_gpc are gone,
but we leave in the function that tells userspace code that they are off.
get_magic_quotes_gpc()
will always return false which means that thousands
of applications out there will run unchanged and will simply take the
magic_quotes off code path.
Exactly, what I said in my very first reply to this thread. With all
respects to Philip, this RFC and discussion are pointless, the
solution has been approved and the problem is about to be solved (when
I get two and half mins to apply my patch, probably early next week).
Cheers,
Hi,
Just making sure I understood it well. Get isn't deprecated (good), set is
(good), but what happens if I try to set magic quotes runtime off if it
was on from the config.
I couldn't see anything about the PHP config setting being ignored/removed
or throwing error in the RFC.
For code that must be portable, and I don't have access to server/PHP
config, I often have something like this in init:
if (get_magic_quotes_runtime()) {
set_magic_quotes_runtime(0);
}
if (get_magic_quotes_gpc()) {
include 'a_snippet_that_recursively_strips_slashes_off_gpc.php';
}
Regards,
Stan Vassilev
We have covered this a bunch of times already. magic_quotes_gpc
are gone,
but we leave in the function that tells userspace code that they
are off.
get_magic_quotes_gpc()
will always return false which means that
thousands
of applications out there will run unchanged and will simply take the
magic_quotes off code path.Exactly, what I said in my very first reply to this thread. With all
respects to Philip, this RFC and discussion are pointless, the
solution has been approved and the problem is about to be solved (when
I get two and half mins to apply my patch, probably early next week).
But Rasmus, the patch planned by Pierre will emit errors. Even
E_WARNING
in 6.0. So here's possible upcoming documentation:
"Checking for magic quotes is deprecated, as is setting them, so do
neither in your code; else suffer errors."
And:
"Yes, magic_quotes_gpc is on by default in PHP 5.3 but checking its
value is deprecated. Instead, assume they are always on or off."
Maybe this makes the point clear to everyone? This is my last plea on
the subject.
Regards,
Philip
Rasmus Lerdorf wrote:
I see absolutely no reason to force people to go through and change:
if(!get_magic_quotes_gpc())
to:
if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc())
when there is no technical reason to force them to do so. It is slower,
more verbose and completely useless.
I whole-heartedly agree.
To the others: please examine this from a practical instead of a
philosophical position.
What is the problem that needs solving?
- magic_quotes_gpc escapes input, which is bad.
How to fix it?
- disable magic_quotes_gpc = on, disable set_magic_quotes_gpc(1)
Implicit in this statement is that the problem is not:
- Users use
get_magic_quotes_gpc()
check whether this faulty ini is
enabled, and set_magic_quotes_gpc(off) only if it is enabled.
If we take the step of removing the get_magic_quotes_gpc()
function, or
of adding an E_DEPRECATED, we make upgrading to PHP 5.3 harder, for no
benefit.
As a side note, the silent majority (developers who do not post to this
list) were represented at php|tek, and the few I spoke to about the way
magic_quotes is being handled unequivocally agreed with my assessment
for the exact same reasons.
I strongly encourage everyone to do a realistic tradeoff analysis and
come to understand why Rasmus's solution is the only possible solution
to this problem that both solves the actual problem and has real
benefit to existing well-written applications.
Thanks,
Greg
Gregory Beaver wrote:
Rasmus Lerdorf wrote:
I see absolutely no reason to force people to go through and change:
if(!get_magic_quotes_gpc())
to:
if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc())
when there is no technical reason to force them to do so. It is slower,
more verbose and completely useless.I whole-heartedly agree.
To the others: please examine this from a practical instead of a
philosophical position.What is the problem that needs solving?
- magic_quotes_gpc escapes input, which is bad.
How to fix it?
- disable magic_quotes_gpc = on, disable set_magic_quotes_gpc(1)
Implicit in this statement is that the problem is not:
- Users use
get_magic_quotes_gpc()
check whether this faulty ini is
enabled, and set_magic_quotes_gpc(off) only if it is enabled.If we take the step of removing the
get_magic_quotes_gpc()
function, or
of adding an E_DEPRECATED, we make upgrading to PHP 5.3 harder, for no
benefit.
Right, I guess I wasn't absolutely explicit. There is no point in
spewing an E_DEPRECATED
on get_magic_quotes_gpc()
. Such warnings should
be for people actually using a deprecated feature, not for functions
that check for those features.
-Rasmus
Right, I guess I wasn't absolutely explicit. There is no point in spewing
anE_DEPRECATED
onget_magic_quotes_gpc()
. Such warnings should be for
people actually using a deprecated feature, not for functions that check for
those features.
I guess everyone got confused. The E_DEPRECATED
is only if the ini
setting is used. Obviously not for the getter... (as it is not/will
not be removed).
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.Why should we leave
get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and
@get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
We leave it because it's a developer friendly function that people
use. The checking of this feature is not deprecated, but rather, the
feature itself is deprecated and will be removed. And asking people to
update past and present code because we don't want the string
"magic_quotes" in php-src doesn't sound like much fun.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic
quotes
are considered a bad practice for a long time.
That's why good developers check for it, and why we shouldn't punish
them for that. These E_* errors (and formally proposed removal
outright) equal punishment. Also note that magic_quotes_gpc is enabled
by default... even in PHP 5.3. So people have always checked for it,
and will continue to do so, and we already have get_magic_quotes_*()
so let's keep it with no E_rrors. Of course setting MQ is a totally
different story.
cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
In this case all silence would have done is temporarily move the
conversation to php-cvs@.
Regards,
Philip
+1 for this. Just clean the code once and for all.
2008/5/23 Lars Strojny lars@strojny.net:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.Magic Quotes in PHP 5.3 and beyond
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED
from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.Why should we leave
get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.cu, Lars
P.S.: Silence agrees doesn't work, silence is void.
Why should we leave
get_magic_quotes_gpc()
? If someone wants to be
backwards compatible, just use
Excuse me? The users should change their code to be forward compatible?
We should ofcourse make it easier for our users and keep backwards
compatibility.
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
So you do indeed want to punish the developers who followed the manual
and deployed best practices?
Don't be such a jerk. The people who did in fact follow best practices
and checked if MQ are on/off and dealt with it should NOT be
punished for it.
-Hannes