Hello all,
Those of you who are saying things like "forget the idiots using
magic_quotes" need to understand more clearly what is being proposed.
NOBODY is proposing keeping magic_quotes.
As of PHP 5.3 and earlier, all applications worth an ounce of anything
must check for and handle magic_quotes_runtime. If magic_quotes_runtime
is enabled, and you don't handle it, you end up with a bunch of
unnecessary slashes in your input.
This is VERY different from relying upon magic_quotes_runtime to
"safely" escape crap.
If the magic_quotes functions are removed, this will unequivocably break
every decent application written for PHP 5 and PHP 4. As an example,
the PEAR Installer uses a disabling routine even though it doesn't do
any web access at all. Why? Because magic_quotes_runtime affects
file_get_contents(), which is used to read registry files. As such,
even though the magic_quotes functionality is never used, the app still
has to check for and disable it.
If the function magic_quotes_runtime() exists and simply returns false,
the PEAR installer continues to work as written without modification. I
could certainly modify the latest release to use the if
(function_exists()) check that some have proposed, and that would be
fine for me, but it is not a good solution for the hundreds of thousands
of users we have out there.
Why?
First of all, very few people actually upgrade to the latest version
when it is released. The majority have upgraded by approximately a
year after the release date, and a large minority (30% or so) do not
upgrade for up to 4 years.
Now, if Joe Shmoe has a slightly older version of PEAR, and upgrades to
PHP 6 (yes, people DO upgrade PHP and still keep their outdated PEAR
installations in spite of obvious reasons not to do this, and no, we
can't expect to change this from our perch here at php.net), suddenly
Joe gets a fatal error, and can no longer use PEAR either to upgrade to
a newer version or anything of that nature. Joe wastes a ton of time
figuring out what is wrong, and ends up having to manually re-install PEAR.
Who would benefit from having the functions removed? People who don't
use them don't care, people who do would get a fatal error.
Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.
There is never any benefit in making the upgrade path harder for our
users, come on people.
Greg
Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.
It is not plain stupid to remove something when the underlying
features do not exist. It is expected.
Talking about BC in this case is a closed to be a complete non sense.
For two reasons:
- If can't do that between two major versions, let define a rule: we
can't change anything in PHP, no matter when (think: roll back all
these fatal errors) - it is fixable in three lines (with braces). PEAR had much harder
issues already, you can document the upgrade process (upgrade pear
then php, make install will work if you include a full upgrading
solution in go-pear.phar, if it is not the case already)
Finally, I proposed a vote because we did vote about the complete
removal of these features a while back. Back to this time, it was not
decided to keep them but to actually completely remove them. I thought
(and still think) that it was necessary (and it was necessary) to
bring this topic back to the list and to finally have a choice. That's
why this list exists and not whatever IRC channel somewhere on EFNet
:)
Cheers,
Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.It is not plain stupid to remove something when the underlying
features do not exist. It is expected.Talking about BC in this case is a closed to be a complete non sense.
For two reasons:
- If can't do that between two major versions, let define a rule: we
can't change anything in PHP, no matter when (think: roll back all
these fatal errors)- it is fixable in three lines (with braces). PEAR had much harder
issues already, you can document the upgrade process (upgrade pear
then php, make install will work if you include a full upgrading
solution in go-pear.phar, if it is not the case already)Finally, I proposed a vote because we did vote about the complete
removal of these features a while back. Back to this time, it was not
decided to keep them but to actually completely remove them. I thought
(and still think) that it was necessary (and it was necessary) to
bring this topic back to the list and to finally have a choice. That's
why this list exists and not whatever IRC channel somewhere on EFNet
:)
Throw an E_DEPRECATED (means will be removed in the next major
version) in PHP6 and return false for now.
-1
regards,
Lukas
Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.It is not plain stupid to remove something when the underlying
features do not exist. It is expected.Talking about BC in this case is a closed to be a complete non sense.
For two reasons:
- If can't do that between two major versions, let define a rule: we
can't change anything in PHP, no matter when (think: roll back all
these fatal errors)
The change here is to remove magical quotes and then have these
functions always return 0, so yes we can change and keep [some] BC in
one smooth motion.
- it is fixable in three lines (with braces). PEAR had much harder
issues already, you can document the upgrade process (upgrade pear
then php, make install will work if you include a full upgrading
solution in go-pear.phar, if it is not the case already)
But the general problem is with old code working in PHP 6, not new or
updated code working in PHP 6. These functions should remain, and if
not, then PHP 6 should break everything... meaning, be the "make PHP
do what we want it to do with little BC in mind" instead of only
doing that sometimes. Which is it? What is the PHP 6 mission statement?
Regards,
Philip
If those application are written properly, they also have to check for
the existance of the functions even with current PHP version since it is
possible to disable them altogether. So it shouldn't matter if they're
removed for them.. ;)
--Jani
Hello all,
Those of you who are saying things like "forget the idiots using
magic_quotes" need to understand more clearly what is being proposed.
NOBODY is proposing keeping magic_quotes.As of PHP 5.3 and earlier, all applications worth an ounce of anything
must check for and handle magic_quotes_runtime. If magic_quotes_runtime
is enabled, and you don't handle it, you end up with a bunch of
unnecessary slashes in your input.This is VERY different from relying upon magic_quotes_runtime to
"safely" escape crap.If the magic_quotes functions are removed, this will unequivocably break
every decent application written for PHP 5 and PHP 4. As an example,
the PEAR Installer uses a disabling routine even though it doesn't do
any web access at all. Why? Because magic_quotes_runtime affects
file_get_contents(), which is used to read registry files. As such,
even though the magic_quotes functionality is never used, the app still
has to check for and disable it.If the function magic_quotes_runtime() exists and simply returns false,
the PEAR installer continues to work as written without modification. I
could certainly modify the latest release to use the if
(function_exists()) check that some have proposed, and that would be
fine for me, but it is not a good solution for the hundreds of thousands
of users we have out there.Why?
First of all, very few people actually upgrade to the latest version
when it is released. The majority have upgraded by approximately a
year after the release date, and a large minority (30% or so) do not
upgrade for up to 4 years.Now, if Joe Shmoe has a slightly older version of PEAR, and upgrades to
PHP 6 (yes, people DO upgrade PHP and still keep their outdated PEAR
installations in spite of obvious reasons not to do this, and no, we
can't expect to change this from our perch here at php.net), suddenly
Joe gets a fatal error, and can no longer use PEAR either to upgrade to
a newer version or anything of that nature. Joe wastes a ton of time
figuring out what is wrong, and ends up having to manually re-install PEAR.Who would benefit from having the functions removed? People who don't
use them don't care, people who do would get a fatal error.Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.There is never any benefit in making the upgrade path harder for our
users, come on people.Greg
--
Patches/Donations: http://pecl.php.net/~jani/
If those application are written properly, they also have to check for
the existance of the functions even with current PHP version since it is
possible to disable them altogether. So it shouldn't matter if they're
removed for them.. ;)
Function is standard for PHP4-5. get_magic_quotes_gpc() does not change
php settings and only returns status of magic quotes. Any function can be
disabled with disable_functions. If user does that, he or she is
deliberately breaking his setup and he/she is the one that should solve
the issues. If developers follow your advice, they will have to check for
any php function before using it.
In case of magic quotes people just have to check for function or php
version. It is one of those things that make PHP6 different from older PHP
versions. Core written for both versions will check php version or
existence of get_magic_quotes_gpc()
--
Tomas
Jani Taskinen wrote:
If those application are written properly, they also have to check for
the existance of the functions even with current PHP version since it is
possible to disable them altogether. So it shouldn't matter if they're
removed for them.. ;)
It's possible to disable any function. Do you check for the existence
of every function before you use it? Actually, I'm familiar enough with
your code to know that the answer is "no." This is a straw man argument.
Greg