# [RFC] Removal of deprecated features - Thread: https://externals.io/message/47839 - Original archive: https://news-web.php.net/php.internals/47839 - Started by Kalle Sommer Nielsen on 2010-04-08T22:48:11+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47839 — Kalle Sommer Nielsen — 2010-04-08T22:48:11+00:00 URL: https://externals.io/message/47839#47839 Hey Everyone I've put together a simple RFC[1] that lists features thats been deprecated in 5.3, someone of them which I propose we remove in the next version of PHP, depending on the version number. Most of the features, which is listed below are taken from the old 6.0 NEWS[2] file, and items from the old PHP6 TODO[3]. safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference - Something we have long time been wanted to remove from PHP, I don't see a big reason to keep those in the next version, even if its going to be a 5.4, since we already removed things like zend.ze1_compatibility_mode. See the magic quotes RFC[4]. define_syslog_variables and its associated function - Originally agreed to be removed in PHP6 during the 5.3 development, if there is no objects then I will remove by the end of this weekend. asp_tags - Proposed to be removed aswell, Tony had a patch for this[5]. sql_safe_mode - Theres currently an RFC in the works about this by Johannes[6]. session_register/session_is_registered/session_register - Only needed for register_globals, Hannes removed those in PHP6. enable_dl - Is this really worth keeping, since `dl()` was disabled on almost all SAPIs except for CLI/CGI/Embed? Support for Freetype 1 and GD 1 - Removed by Pierre in PHP6 Support for "continue" and "break" operators with non constant operands - Removed by Dmitry in PHP6. Undocumented and incomplete support for strings in list() operator - Removed by Dmitry in PHP6 aswell. detect_unicode/highlight_bg - Two ini values thats been marked as removed features from PHP6 in the manual. Not sure about detect_unicode, but highlight_bg is pretty pointless. y2k_compliance - From the manual "Enforce year 2000 compliance (will cause problems with non-compliant browsers)", we are in 2010, we should remove this option and enable it by default and remove the checks. Perhaps Derick got an insight here? Class named constructors - A feature thats been marked in the manual as something that would be removed in a future version of PHP6. It was not to be knowing ever decided to be kept or not, but now with the recent removal of them in namespaces then I don't see a big point in keeping them. If there is anything I forgot then let me know and I will add it to the RFC, else discussions away! [1] http://wiki.php.net/rfc/removal-of-deprecated-features [2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup [3] http://wiki.php.net/todo/php60 [4] http://wiki.php.net/rfc/magicquotes [5] http://marc.info/?l=php-internals&m=117640641605813&w=2 [6] http://wiki.php.net/rfc/drop_sql.safe_mode -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47840 — Stanislav Malyshev — 2010-04-08T23:03:02+00:00 URL: https://externals.io/message/47839#47840 · In reply to: #47839 Hi! > asp_tags > - Proposed to be removed aswell, Tony had a patch for this[5]. IIRC last time we discussed it there was no solid reason found to do it and some reasons not to. Could you remind why would it be useful to do it? > Class named constructors > - A feature thats been marked in the manual as something that would > be removed in a future version of PHP6. It was not to be knowing ever > decided to be kept or not, but now with the recent removal of them in > namespaces then I don't see a big point in keeping them. I don't feel good with removing these for non-NS classes... BC break would be big, though it would be relatively easy to write a script to fix that. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #47844 — Brian Moon — 2010-04-09T13:41:56+00:00 URL: https://externals.io/message/47839#47844 · In reply to: #47839 > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference > - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. +1 > asp_tags > - Proposed to be removed aswell, Tony had a patch for this[5]. -1. Widely used, not a drain on the language. Better in some cases than regular PHP tags. > sql_safe_mode > - Theres currently an RFC in the works about this by Johannes[6]. +1 Brian. --- ## #47845 — Keisial — 2010-04-09T14:54:27+00:00 URL: https://externals.io/message/47839#47845 · In reply to: #47839 Kalle Sommer Nielsen wrote: > enable_dl > - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? > Although it is not the most widespread use of PHP, people using things like PHP-GTK probably take advantage of it. --- ## #47846 — johannes@php.net — 2010-04-09T15:21:23+00:00 URL: https://externals.io/message/47839#47846 · In reply to: #47839 Hi, > session_register/session_is_registered/session_register > - Only needed for register_globals, Hannes removed those in PHP6. regiter_globals should be removed. It still exits, removing these is the logical consequence after removing r_g. > enable_dl > - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? It's a good thing to be able to disable `dl()` with (Fast)CGI. For CLI this setting shouldn't really matter, as long as `dl()` exists there. > y2k_compliance > - From the manual "Enforce year 2000 compliance (will cause problems > with non-compliant browsers)", we are in 2010, we should remove this > option and enable it by default and remove the checks. Perhaps Derick > got an insight here? This is related to setcookie, not the date stuff and can be safely removed. > Class named constructors > - A feature thats been marked in the manual as something that would > be removed in a future version of PHP6. It was not to be knowing ever > decided to be kept or not, but now with the recent removal of them in > namespaces then I don't see a big point in keeping them. I personally would remove them, but I read the discussion about namespaced classes and ctor names in a way hat there was no conesus for removing it. johannes --- ## #47852 — Mike Robinson — 2010-04-09T22:38:10+00:00 URL: https://externals.io/message/47839#47852 · In reply to: #47839 Hi, Respectfully, FWIW... > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_ca > ll_time_pass_reference +1 > asp_tags > - Proposed to be removed aswell, Tony had a patch for this[5]. -1 No way. While I abhor there use, _many_ people do not. > sql_safe_mode > - Theres currently an RFC in the works about this by Johannes[6]. +1 > session_register/session_is_registered/session_register > - Only needed for register_globals, Hannes removed those in PHP6. +1 > enable_dl > - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? +1 > Support for Freetype 1 and GD 1 > - Removed by Pierre in PHP6 +1 (With my sincere gratitude to Thomas for his work all those years) > Class named constructors -1 Not in 5.x - the BC break here is huge. Best Regards Mike Robinson --- ## #47853 — Philip Olson — 2010-04-10T05:04:23+00:00 URL: https://externals.io/message/47839#47853 · In reply to: #47839 > If there is anything I forgot then let me know and I will add it to > the RFC, else discussions away! There are a couple more that were documented as being removed from PHP 6: - pdo_odbc.db2_instance_name - session.bug_compat_42 Should these be added to this list? And I suppose session.bug_compat_warn goes along with session.bug_compat_42. Regards, Philip --- ## #47862 — Kalle Sommer Nielsen — 2010-04-10T14:04:14+00:00 URL: https://externals.io/message/47839#47862 · In reply to: #47840 2010/4/9 Stanislav Malyshev : > Hi! > > > […] > > IIRC last time we discussed it there was no solid reason found to do it and > some reasons not to. Could you remind why would it be useful to do it? > I spend sometime reading archives and I should problably have written in the initial post; Im just wondering about how many that actually use it, and activate it since its disabled by default. So I guess the question should have been about its usage statistics, since overall it doesn't really cover anything that short_open_tags except the PI collision. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47863 — Kalle Sommer Nielsen — 2010-04-10T14:05:20+00:00 URL: https://externals.io/message/47839#47863 · In reply to: #47853 2010/4/10 Philip Olson : > > […] > > There are a couple more that were documented as being removed from PHP 6: > > - pdo_odbc.db2_instance_name > - session.bug_compat_42 > > Should these be added to this list? And I suppose session.bug_compat_warn goes along with session.bug_compat_42. Feel free to add them if they were listed as things that was supposed to be removed in PHP6 on. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47864 — Kalle Sommer Nielsen — 2010-04-10T14:06:17+00:00 URL: https://externals.io/message/47839#47864 · In reply to: #47839 2010/4/9 Kalle Sommer Nielsen : > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference >  - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. > I've updated the RFC with a patch for removing register_long_arrays if there is any objections agains this. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47960 — Patrick ALLAERT — 2010-04-15T09:32:14+00:00 URL: https://externals.io/message/47839#47960 · In reply to: #47839 2010/4/9 Kalle Sommer Nielsen : > Hey Everyone > > I've put together a simple RFC[1] that lists features thats been > deprecated in 5.3, someone of them which I propose we remove in the > next version of PHP, depending on the version number. Most of the > features, which is listed below are taken from the old 6.0 NEWS[2] > file, and items from the old PHP6 TODO[3]. > > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference >  - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. > > define_syslog_variables and its associated function >  - Originally agreed to be removed in PHP6 during the 5.3 development, > if there is no objects then I will remove by the end of this weekend. > > asp_tags >  - Proposed to be removed aswell, Tony had a patch for this[5]. > > sql_safe_mode >  - Theres currently an RFC in the works about this by Johannes[6]. > > session_register/session_is_registered/session_register >  - Only needed for register_globals, Hannes removed those in PHP6. > > enable_dl >  - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? > > Support for Freetype 1 and GD 1 >  - Removed by Pierre in PHP6 > > Support for "continue" and "break" operators with non constant operands >  - Removed by Dmitry in PHP6. > > Undocumented and incomplete support for strings in list() operator >  - Removed by Dmitry in PHP6 aswell. > > detect_unicode/highlight_bg >  - Two ini values thats been marked as removed features from PHP6 in > the manual. Not sure about detect_unicode, but highlight_bg is pretty > pointless. > > y2k_compliance >  - From the manual "Enforce year 2000 compliance (will cause problems > with non-compliant browsers)", we are in 2010, we should remove this > option and enable it by default and remove the checks. Perhaps Derick > got an insight here? > > Class named constructors >  - A feature thats been marked in the manual as something that would > be removed in a future version of PHP6. It was not to be knowing ever > decided to be kept or not, but now with the recent removal of them in > namespaces then I don't see a big point in keeping them. > > > If there is anything I forgot then let me know and I will add it to > the RFC, else discussions away! > > > [1] http://wiki.php.net/rfc/removal-of-deprecated-features > [2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup > [3] http://wiki.php.net/todo/php60 > [4] http://wiki.php.net/rfc/magicquotes > [5] http://marc.info/?l=php-internals&m=117640641605813&w=2 > [6] http://wiki.php.net/rfc/drop_sql.safe_mode > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > > -- > > > > Hi! I think we should also keep an eye on removing dead code. Removing the useless: main/mergesort.c for example (Patch in attachment). I think I don't have enough karma to commit this. Regards, -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor --- ## #47961 — Kalle Sommer Nielsen — 2010-04-15T09:48:33+00:00 URL: https://externals.io/message/47839#47961 · In reply to: #47960 Hi Patrick 2010/4/15 Patrick ALLAERT : > Hi! > > I think we should also keep an eye on removing dead code. > Removing the useless: main/mergesort.c for example (Patch in attachment). I agree we should remove dead code, like Johannes commit to remove php3_compat.h. As for the mergesort patch, is it used anywhere in PECL or something? If not then I think we should remove it. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47962 — Patrick ALLAERT — 2010-04-15T10:01:05+00:00 URL: https://externals.io/message/47839#47962 · In reply to: #47961 2010/4/15 Kalle Sommer Nielsen : > Hi Patrick > > 2010/4/15 Patrick ALLAERT : > > […] > > I agree we should remove dead code, like Johannes commit to remove > php3_compat.h. As for the mergesort patch, is it used anywhere in PECL > or something? If not then I think we should remove it. It's not, checked with http://php-og.mgdm.net/ and grep. Patrick --- ## #47965 — Derick Rethans — 2010-04-15T11:01:34+00:00 URL: https://externals.io/message/47839#47965 · In reply to: #47839 > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference > - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. +0 > session_register/session_is_registered/session_register > - Only needed for register_globals, Hannes removed those in PHP6. +1 > enable_dl > - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? -1 > Support for "continue" and "break" operators with non constant operands > - Removed by Dmitry in PHP6. -1 — unless there is a very good reason for removing them. > y2k_compliance > - From the manual "Enforce year 2000 compliance (will cause problems > with non-compliant browsers)", we are in 2010, we should remove this > option and enable it by default and remove the checks. Perhaps Derick > got an insight here? +1 — It's a switch, much like "make_it_faster". Can be safely removed. > Class named constructors > - A feature thats been marked in the manual as something that would > be removed in a future version of PHP6. It was not to be knowing ever > decided to be kept or not, but now with the recent removal of them in > namespaces then I don't see a big point in keeping them. -1 Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47989 — johannes@php.net — 2010-04-15T22:51:23+00:00 URL: https://externals.io/message/47839#47989 · In reply to: #47839 Hi, on my previous mail I missed one thing: > magic_quotes_* > - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. Removing magic_quotes would be soooooooooooo great. BUT the issue is that most users don't know about it. Many applications are more or less secure due to its existence. The apps aren't fully secure but a few less vectors. I'm - for a while - thinking whether there is a way to notify application developers about applications which run with m_q=On but no check for it. As unless they are aware of it this will break many things where people don't read the upgrading guides. With the old PHP 6 I hoped the break was big enough. Now I'm not sure. johannes --- ## #47990 — Arvids Godjuks — 2010-04-16T08:43:57+00:00 URL: https://externals.io/message/47839#47990 · In reply to: #47989 You must have been flying somethere in the Andromeda galaxy all this time! magic_quotes, safe_mode and other stuff was announced depricated now for a few years, there is big buzz going on about it and these features are allready marked as depricated and throw warnings as of 5.3, some even as off 5.2. It's hard to miss articles, announce, conferences and numerous blog entries literally from any PHP developer who has a blog that these features are to be droped. Please rewind from the past to the present day! :) People, just drop all this stuff once and for all and forget it. 2010/4/16 Johannes Schlüter > Hi, > > on my previous mail I missed one thing: > > > > […] > > Removing magic_quotes would be soooooooooooo great. BUT the issue is > that most users don't know about it. Many applications are more or less > secure due to its existence. The apps aren't fully secure but a few less > vectors. > > I'm - for a while - thinking whether there is a way to notify > application developers about applications which run with m_q=On but no > check for it. As unless they are aware of it this will break many things > where people don't read the upgrading guides. > > With the old PHP 6 I hoped the break was big enough. Now I'm not sure. > > johannes --- ## #47991 — johannes@php.net — 2010-04-16T09:01:59+00:00 URL: https://externals.io/message/47839#47991 · In reply to: #47990 > You must have been flying somethere in the Andromeda galaxy all this time! > > magic_quotes, safe_mode and other stuff was announced depricated now for a > few years, there is big buzz going on about it and these features are > allready marked as depricated and throw warnings as of 5.3, some even as off > 5.2. It's hard to miss articles, announce, conferences and numerous blog > entries literally from any PHP developer who has a blog that these features > are to be droped. Go to a random hosting site and look at there configuration - magic quotes will be enabled. Look at some (not all) distributor packages - magic quotes will be on. Many of them won't see it as it's "hidden" in an error log which barely anybody read. Yes you do. You also read this list. But that's a minority of our users. Most don't follow the development closely. Most don't read blogs. Most don't know about php.ini. Most don't know about security. The people we interact with are just the tip of the iceberg. Most PHP users are hidden on the internet. I would love to get rid of this "feature" but I fear that many users won't notice and i don't know how to tell them. johannes --- ## #47992 — Ferenc Kovacs — 2010-04-16T10:23:42+00:00 URL: https://externals.io/message/47839#47992 · In reply to: #47991 2010/4/16 Johannes Schlüter > > > […] > time! > > […] > a > > […] > off > > […] > features > > […] > > Go to a random hosting site and look at there configuration - magic > quotes will be enabled. Look at some (not all) distributor packages - > magic quotes will be on. Many of them won't see it as it's "hidden" in > an error log which barely anybody read. Yes you do. You also read this > list. But that's a minority of our users. Most don't follow the > development closely. Most don't read blogs. Most don't know about > php.ini. Most don't know about security. > > The people we interact with are just the tip of the iceberg. Most PHP > users are hidden on the internet. > > I would love to get rid of this "feature" but I fear that many users > won't notice and i don't know how to tell them. > > johannes > > I think that the hosting providers will do notice, and either not migrate, or send a mail to their users, warning to check their settings because if they are depending on the magic quotes, they will be in danger. So I think we don't have to wait for the shared hosting providers, because they will catch up as slow or fast as we go. Plus we don't know what will be the next version, so go ahead, commit into the trunk, and when the release is coming, it will be decided whether or not include this into it. Tyrael --- ## #47993 — Pierrick Charron — 2010-04-16T15:15:10+00:00 URL: https://externals.io/message/47839#47993 · In reply to: #47839 I've added the patch to remove magic quotes from trunk on the RFC. Is there any comments/objection against this patch ? Pierrick 2010/4/8 Kalle Sommer Nielsen : > Hey Everyone > > I've put together a simple RFC[1] that lists features thats been > deprecated in 5.3, someone of them which I propose we remove in the > next version of PHP, depending on the version number. Most of the > features, which is listed below are taken from the old 6.0 NEWS[2] > file, and items from the old PHP6 TODO[3]. > > safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference >  - Something we have long time been wanted to remove from PHP, I don't > see a big reason to keep those in the next version, even if its going > to be a 5.4, since we already removed things like > zend.ze1_compatibility_mode. See the magic quotes RFC[4]. > > define_syslog_variables and its associated function >  - Originally agreed to be removed in PHP6 during the 5.3 development, > if there is no objects then I will remove by the end of this weekend. > > asp_tags >  - Proposed to be removed aswell, Tony had a patch for this[5]. > > sql_safe_mode >  - Theres currently an RFC in the works about this by Johannes[6]. > > session_register/session_is_registered/session_register >  - Only needed for register_globals, Hannes removed those in PHP6. > > enable_dl >  - Is this really worth keeping, since `dl()` was disabled on almost all > SAPIs except for CLI/CGI/Embed? > > Support for Freetype 1 and GD 1 >  - Removed by Pierre in PHP6 > > Support for "continue" and "break" operators with non constant operands >  - Removed by Dmitry in PHP6. > > Undocumented and incomplete support for strings in list() operator >  - Removed by Dmitry in PHP6 aswell. > > detect_unicode/highlight_bg >  - Two ini values thats been marked as removed features from PHP6 in > the manual. Not sure about detect_unicode, but highlight_bg is pretty > pointless. > > y2k_compliance >  - From the manual "Enforce year 2000 compliance (will cause problems > with non-compliant browsers)", we are in 2010, we should remove this > option and enable it by default and remove the checks. Perhaps Derick > got an insight here? > > Class named constructors >  - A feature thats been marked in the manual as something that would > be removed in a future version of PHP6. It was not to be knowing ever > decided to be kept or not, but now with the recent removal of them in > namespaces then I don't see a big point in keeping them. > > > If there is anything I forgot then let me know and I will add it to > the RFC, else discussions away! > > > [1] http://wiki.php.net/rfc/removal-of-deprecated-features > [2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup > [3] http://wiki.php.net/todo/php60 > [4] http://wiki.php.net/rfc/magicquotes > [5] http://marc.info/?l=php-internals&m=117640641605813&w=2 > [6] http://wiki.php.net/rfc/drop_sql.safe_mode > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net --- ## #47994 — Philip Olson — 2010-04-16T15:32:02+00:00 URL: https://externals.io/message/47839#47994 · In reply to: #47991 > > > […] > > Go to a random hosting site and look at there configuration - magic > quotes will be enabled. Look at some (not all) distributor packages - > magic quotes will be on. Many of them won't see it as it's "hidden" in > an error log which barely anybody read. Yes you do. You also read this > list. But that's a minority of our users. Most don't follow the > development closely. Most don't read blogs. Most don't know about > php.ini. Most don't know about security. > > The people we interact with are just the tip of the iceberg. Most PHP > users are hidden on the internet. > > I would love to get rid of this "feature" but I fear that many users > won't notice and i don't know how to tell them. And a related issue is that magical quotes are still enabled by default in PHP, and removing a security feature that was enabled by default is not a simple matter. Not sure if disabling it by default (in trunk) is a preferred intermediate step, but it's possible. Regards, Philip --- ## #47995 — Pierrick Charron — 2010-04-16T15:40:25+00:00 URL: https://externals.io/message/47839#47995 · In reply to: #47991 +1 to remove magic_quotes from trunk Most of us want to get rid of this feature. I agree with you that some people probably don't know php.ini and magic_quotes but i'm not sure that even if we wait we'll find a better way to tell them about those. People (not all) on shared hosting don't really pay attention to PHP upgrades on their server even if it's a major release and it's sadly not going to change. Pierrick 2010/4/16 Johannes Schlüter : > > > […] > > Go to a random hosting site and look at there configuration - magic > quotes will be enabled. Look at some (not all) distributor packages - > magic quotes will be on. Many of them won't see it as it's "hidden" in > an error log which barely anybody read. Yes you do. You also read this > list. But that's a minority of our users. Most don't follow the > development closely. Most don't read blogs. Most don't know about > php.ini. Most don't know about security. > > The people we interact with are just the tip of the iceberg. Most PHP > users are hidden on the internet. > > I would love to get rid of this "feature" but I fear that many users > won't notice and i don't know how to tell them. > > johannes --- ## #47996 — Larry Garfield — 2010-04-16T20:38:23+00:00 URL: https://externals.io/message/47839#47996 · In reply to: #47992 On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote: > I think that the hosting providers will do notice, and either not migrate, > or send a mail to their users, warning to check their settings because if > they are depending on the magic quotes, they will be in danger. > > So I think we don't have to wait for the shared hosting providers, because > they will catch up as slow or fast as we go. Given how long it took them to catch up to PHP 5 in the first place I don't think we can count on that. Such breakage should come in large chunks so that hosts only have to wring their hands once every so often. Otherwise they just won't upgrade ever. Most run on very thin margins. --Larry Garfield --- ## #47997 — Ferenc Kovacs — 2010-04-17T05:39:38+00:00 URL: https://externals.io/message/47839#47997 · In reply to: #47996 On Fri, Apr 16, 2010 at 10:38 PM, Larry Garfield wrote: > On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote: > > > […] > migrate, > > […] > because > > […] > > Given how long it took them to catch up to PHP 5 in the first place I don't > think we can count on that. > > Because PHP4 was supported for a long time. This is what I'm saying. If you support 5,3 at least with security updates for years, they won't upgrade because they don't have to. > Such breakage should come in large chunks so that hosts only have to wring > their hands once every so often. Otherwise they just won't upgrade ever. > Most run on very thin margins. > > I disagree, from the point of the coder who has to port the application from one version to other, it's easier, if there is only a few changes, which has to be taken care of. From the point of shared hosting providers, they don't want to change anything from the BC perspective, so if you turn off some default value, or throw deprecate warning, they will turn it back on, and ignore the errors. When this is not possible (because you removed some feature), they won't upgrade, as long as there is security support for the old version. Tyrael --- ## #47998 — pasthelod@gmail.com — 2010-04-17T12:34:17+00:00 URL: https://externals.io/message/47839#47998 · In reply to: #47997 > On Fri, Apr 16, 2010 at 10:38 PM, Larry Garfieldwrote: > > > […] > support 5,3 at least with security updates for years, they won't upgrade > because they don't have to. > > > > […] > I disagree, from the point of the coder who has to port the application from > one version to other, it's easier, if there is only a few changes, which has > to be taken care of. > From the point of shared hosting providers, they don't want to change > anything from the BC perspective, so if you turn off some default value, or > throw deprecate warning, they will turn it back on, and ignore the errors. > When this is not possible (because you removed some feature), they won't > upgrade, as long as there is security support for the old version. > > Tyrael > Just some anecdotal evidence regarding this issue: http://it.slashdot.org/story/10/04/16/1646244/ClamAV-Forced-Upgrade-Breaks-Email-Servers The 2 year old version of the ClamAV daemon (0.94) is incompatible with the new signature updates (for the also free 0.95 and 0.96 versions), so the old version crashed. The funny part is ClamAV was announcing this for at least 6 months. On mailing lists, their homepage, plus the daemon was flooding the server log every day with warnings. Still, some admins did not care about a product that couldn't be more explicitly a factor of their network security. Therefore, in my opinion, waiting for admins to upgrade is futile, useless, and just keeps users in security-fairyland for more time. Pas --- ## #48009 — Daniel Convissor — 2010-04-19T13:37:05+00:00 URL: https://externals.io/message/47839#48009 · In reply to: #47989 > > Removing magic_quotes would be soooooooooooo great. BUT the issue is > that most users don't know about it. Many applications are more or less > secure due to its existence. The apps aren't fully secure but a few less > vectors. One way to remove magic_quotes without opening massive quantities of security holes would be implementing taint mode support (http://wiki.php.net/rfc/taint) and having the default taint_error_level be E_FATAL. Yes, this creates a painful upgrade path for the multitudes using insecure coding practices. But it will hurt a lot less than having their applications inadvertently subverted by hackers/crackers/spammers/etc due to upgrading PHP. --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