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 +Status: Open Bug Type: PHP options/info functions PHP Version: 4.0CVS-2002-06-14 New Comment: 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". Previous Comments: ------------------------------------------------------------------------ [2002-06-14 03:33:37] mfischer@php.net "too big" I meant ------------------------------------------------------------------------ [2002-06-14 03:33:18] mfischer@php.net Abandoning/Deprecating it is not an option -> the BC impact is too nig. If you take a closer look in the PHP4 distribution you will find a file called php.ini-recommended , magic_quotes_gpc are turned off there. ------------------------------------------------------------------------ [2002-06-14 03:23:49] php.net@odi.ch magic_quotes_gpc is a bad idea and should be abandoned for the following reasons: While the option may look very tempting at the first glance there are some caveats however: 1. Most parameters do not go to a database. In a web application most form field are used internally without the need to store them in a database. Magic quotes cause troubles in these cases. Moreover the data passed to the application is not the data entered by the user if it was processed by magic quotes. This is undesireable. 2. Impedes code reuse. If you feed data from either form parameters or internal data sources into the same function then your function must know if the data was processed by magic quotes or not. 3. Bad surprises at deployment time and code portability. If you do not carefully check if this parameter is set on your development and production system you can run into troubles. Especially if you can not change the settings on one system (because the hoster does not let you). 4. Behaviour can not be controlled at script runtime. The ini_set does not help in this case. Even though the parameter can be modified at runtime the behaviour does not change. Consequently you are bound to the php.ini settings (which may be not under the developer's control). I therefore request that this (and related) option be removed from future versions of PHP and the default behaviour should be FALSE. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=17758&edit=1