[PATCH] Removal of deprecated 'gpc_order' php.ini option

php.internals

Jani Taskinen

22 years ago
Attached is a patch to FINALLY get rid of the deprecated php.ini option 'gpc_order'. We've had note in the manual also about it not even existing in PHP4 for ages.. Does anyone have any really good reason why it can NOT be removed before PHP 5 goes gold? There is no BC issue, variables_order will default to what it already is defaulting to in php.ini-*, so the behaviour stays the same even without any php.ini. --Jani

Zeev Suraski

22 years ago
There is some BC issue, because if you configured gpc_order for something specific and you rely on it, this setting will be silently ignored... I *think* it's probably not that popular to change it, and that it's becoming less and less of an issue with the autoglobals. But on the other hand, why do you want to remove it if it doesn't cause any problems (or does it?)? Zeev At 12:14 21/01/2004, Jani Taskinen wrote:

Jani Taskinen

22 years ago
On Wed, 21 Jan 2004, Zeev Suraski wrote:
>There is some BC issue, because if you configured gpc_order for something >specific and you rely on it, this setting will be silently ignored...
Well, my patch makes variables_order to default to EGPCS so it wouldn't mean the variables wouldn't be available.. And I would guess it's VERY rare that someone a) even uses gpc_order (given the note about it being deprecated since PHP 4.0.0 was released, afaik) b) if they 'use' it, it's just because they either don't read, or they totally ignore our recommendations gpc_order only lets you control GPC, they'd still have E & S set anyway, right? So the only BC prob would be that someone had changed the order, ie. uses 'gpc_order = CPG' or something similar. In which case they also don't use register_globals where this would have any meaning in the first place.
>I *think* it's probably not that popular to change it, and that it's >becoming less and less of an issue with the autoglobals. But on the other
Right. And that's the point for removing the confusion for people who DO use register_globals.
>hand, why do you want to remove it if it doesn't cause any problems (or >does it?)?
One reason to remove it is that there's no point having two ini options doing the same thing, where one overrides the other. (the confusion :) Other reason to remove it is to cleanup the code. (okay, it's minimal, but still :) Another reason to remove it is that we've said in manual for ages that the option doesn't even exist in PHP 4. :) And last reason, we're gonna release a major version. And that doesn't happen very often so this would be very good time to remove this kind of stuff. (I think it's very, VERY small possibility that this would cause any problems for anyone) --Jani p.s. I actually removed this to clear up php_variables.c when I was trying to figure out what causes bug http://bugs.php.net/bug.php?id=25724