Thank you for this explanation. I have several scripts that take it for granted PHP will assign variables to the information in the URL as in your example $a from example.com/foo.php?a=apple
Will these scripts fail when my commercial Web host upgrades from PHP 4.1.x to 4.2? If so, can I 'upgrade' my scripts now (again, PHP 4.1.x) to use $food = $_GET['a'] or $food = $_POST['a'] and prevent everything from crashing when PHP 4.2 is installed? (I don't expect to get any warning when the upgrade occurs. This is the same provider that has twice in one week disabled mail() in the PHP build.) John Hughes --- Philip Olson <[EMAIL PROTECTED]> wrote: > An issue/confusion of register_globals, global, and > variable scope exists out there; here are some thoughts: > > a) As of PHP 4.2.0, register_globals defaults to off. > > This is a major change to consider. > register_globals is a PHP directive that lives in > php.ini, the configuration file that controls PHP. > > http://www.php.net/release_4_2_0.php > http://uk.php.net/manual/en/security.registerglobals.php > > Different server setups have different settings, > so not relying on register_globals = on will make > your scripts more portable. > > b) register_globals looks/sounds like global when > really they are very different topics. > > > http://us.php.net/manual/en/configuration.php#ini.register-globals > http://www.php.net/manual/en/language.variables.scope.php > > register_globals will create $a from > example.com/foo.php?a=apple > while when register_globals = off, $a will NOT exist. > One can always use $HTTP_GET_VARS or $_GET for this like so: > > print $_GET['a']; > > Use of import_request_variables() or extract() to act in a > similar fashion as register_globals is possible too. > > http://fr2.php.net/import_request_variables > http://ca.php.net/extract > > c) As of PHP 4.1.0, super/auto global arrays became available. > > The new predefined PHP variables such as $_POST, $_GET, > $_SERVER are identical to their existing counterparts of > $HTTP_POST_VARS, $HTTP_GET_VARS, etc. except that: > > 1) The new autoglobal arrays are automagically global > while their sibling arrays ($HTTP_*_VARS) are not. > http://www.php.net/manual/en/reserved.variables.php > 2) Shorter is better :) > 3) They are different variables, $_GET is not a reference > to $HTTP_GET_VARS but rather they are two seperate > copies, same information. > http://fr2.php.net/release_4_1_0.php > > The manual discusses all the superglobals, others are > $_REQUEST, $_FILES and $_SESSION. > > Being that this is all relativly new, PHP is in sort > of a mild transitional state. The above announcements > explain why. People just starting out with PHP have > slightly more homework to do than before. But, these > same people have less chance for security mistakes now. > > And it's worth noting, register_globals does affect > predefined SERVER variables too. So when off the > variables $DOCUMENT_ROOT, $PHP_SELF, etc. will NOT > exist. Go through $_SERVER or $HTTP_SERVER_VARS instead. > This is something to consider when writing "portable" > scripts (or hacking non-portable scripts to work). A > possible usage is: > > // if register_globals is off, create server vars > if (!ini_get('register_globals')) { > extract($HTTP_SERVER_VARS); > print 'we just created $REMOTE_ADDR because register_globals is > off'; > print "\nREMOTE_ADDR: $REMOTE_ADDR"; > } else { > print 'register_globals is on so $DOCUMENT_ROOT et al already > exists'; > print "\nDOCUMENT_ROOT: $DOCUMENT_ROOT"; > } > > Phew, hope that helps :) > > Regards, > Philip Olson > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
