ID: 36739 Updated by: [EMAIL PROTECTED] Reported By: akorthaus at web dot de -Status: No Feedback +Status: Closed Bug Type: Documentation problem Operating System: Gentoo Linux PHP Version: Irrelevant -Assigned To: +Assigned To: philip New Comment:
This has been fixed within the PHP documentation sources and will show up after the next manual build. Here's the commit: http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/ini.xml?r1=1.44&r2=1.45 Thank you for the report, it was a good (very descriptive) one :) Previous Comments: ------------------------------------------------------------------------ [2007-01-29 01:00:00] phpdoc at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2007-01-21 03:16:26] [EMAIL PROTECTED] How does the following look? variables_order string Sets the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing. For example, if variables_order is set to "SP" then PHP will create the superglobals $_SERVER and $_POST, but not create $_ENV, $_GET, and $_COOKIE. Setting to "" means no superglobals will be set. If the deprecated register_globals directive is on (removed as of PHP 6), then variables_order also configures the order the ENV, GET, POST, COOKIE and SERVER variables are populated in global scope. So for example if variables_order is set to "EGPCS", register_globals is enabled, and both $_GET['action'] and $_POST['action'] are set, then $action will contain the value of $_POST['action'] since "P" is after the "G" in the examples directive value. $_REQUEST is also affected by this order. ------------------------------------------------------------------------ [2006-03-15 01:04:09] akorthaus at web dot de Description: ------------ In "Actual Result" I have copied the current "variables_order" description from the manual. It looks if it was copied from the "register_globals - friendly" description of "gpc_order", but AFAIK these two parameters don't do the same! If you set "variables_order" to "GP", PHP will _not_ "overwrite any GET method variables with POST-method variables of the same name" - that's why $_GET etc. have been invented. Since "register_globals" has been removed from CVS-HEAD, I think this description is misleading (at least it was to me). As far as I can see the order of the variables does not matter if you don't have register_globals anymore. It's only a question of which variables will be created at all. Only if you still use register_globals the last sentence makes sense, but this should not be the default anymore (IMO). Expected result: ---------------- Perhaps something like that: variables_order string Set the order of the EGPCS ($_ENV, $_GET, $_POST, $_COOKIE, $_SERVER) variable parsing. The default setting of this directive is "EGPCS". Setting this to "GP", for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to created only the $_GET and $_POST superglobals. If register_globals is still used, variables_order also configures the order ENV, GET, POST, COOKIE and SERVER variables are populated in global scope. Setting this to "GP" with register_globals enabled, will cause PHP to overwrite any GET method variables with POST-method variables of the same name. [REGISTER-GLOBALS-WARNING] [REGISTER-GLOBALS-REMOVED-NOTICE] See also PHP Superglobals. Actual result: -------------- variables_order string Set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". Setting this to "GP", for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to overwrite any GET method variables with POST-method variables of the same name. See also register_globals. http://de3.php.net/manual/en/ini.core.php#ini.variables-order ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=36739&edit=1
