Bug #17758 Updated: magic_quotes_gpc causes more trouble than it helps

ID: 17758 Updated by: php.net@odi.ch Reported By: php.net@odi.ch Status: Closed Bug Type: PHP options/info functions PHP Version: 4.0CVS-2002-06-14 New Comment: Agree with you that PHP can not detect if code relies on this feature. So the actual problem is: How do I tell the developer that the behaviour changed (or will change). Obviously just mentioning the fact in the release notes is not enough, because this is very subtle but quite important to know. -=| This is a problem that needs proper change management |=- So first developers and system managers must be accustomed (this is the hard part) not to use this feature. Workarounds must be provided (functions that reverse the effect). Documentation must be updated. Books must be changed (this is the timey task). Finally the specs can be changed and the feature can be removed safely. This process may take years. It's not possible to change it within two releases or so. Still, all this doesn't mean that you should simply forget about it. As I said this issue need proper change management. It takes the time it needs. But it only starts when you support it. Previous Comments: ------------------------------------------------------------------------ [2002-06-14 05:43:52] hholzgra@php.net the java way of deprecating things does not work here because of the magic used, there is no way (i can think of) how PHP can detect that code relies on this feature at any point, this is *very* different to just deprecating a method, member variable, interface, class or package so turning it of by default in php.ini-recommended is all we can do about it for now, turning it off by default would be a bad idea as the effect would be far less obvious as the problems that arise with register_globals=off, and that move already caused us a lot of trouble, and totaly removing the 'feature' would be even worse ------------------------------------------------------------------------ [2002-06-14 03:57:54] php.net@odi.ch I was never talking about "now". I said "in the future". I do not want to urge anybody. Nobody is forced to use a new PHP release with existing code. Nor can anybody expect to use a new PHP release without touching existing code. Once more may I ask you to reopen this request. Otherwise you will forget it. We want PHP to be of high quality. This includes we have to get rid of poor-quality concepts. ------------------------------------------------------------------------ [2002-06-14 03:46:01] derick@php.net Too much ppl rely on this, this cannot, I repeat CANNOT, be removed now. I agree it's a silly thing, but breaking scripts for a lot of users is not an option. Derick ------------------------------------------------------------------------ [2002-06-14 03:44:14] php.net@odi.ch Recommendations do not help against the unwise and careless. I think deprecation actually is an acceptable option here. The Java API has been using this mechanism from the start on successfully. The developer is given one release time to change his code. The issue should at least be discussed somewhere and not just be closed by an individual. You can't just say "this is design flaw, so we do not change it". ------------------------------------------------------------------------ [2002-06-14 03:33:37] mfischer@php.net "too big" I meant ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17758 -- Edit this bug report at http://bugs.php.net/?id=17758&edit=1