RE: [PHP] Re: tutorial on global variables
Just CPU time to make all of the new variables. ---John Holmes... -Original Message- From: John Hughes [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 9:58 PM To: Philip Olson; [EMAIL PROTECTED] Subject: Re: [PHP] Re: tutorial on global variables After reviewing http://www.php.net/manual/en/function.import-request-variables.php I was wondering if simply including this line at the top of all scripts import_request_variables(gP, ); would eliminate the potential problem I would have if register_globals gets turned off unexpectedly? Other than the security reasons, is there any disadvantage to adding this line? John Hughes --- Philip Olson [EMAIL PROTECTED] wrote: 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 Okay, so they depend on the behavior that register_globals provides. Will these scripts fail when my commercial Web host upgrades from PHP 4.1.x to 4.2? It's not a matter of PHP versions, it's a matter of a simple PHP directive. PHP 4.2.0 defaults to register_globals = off, this does not mean a host has to go by this default. Ask them if it will be changing, odds are it will not without a warning. 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? Yes you can. I eluded to import_request_variables() and extract(), two functions that will allow you to do such things. Please look them up in the manual (links below). Also consider $_REQUEST, see the manual for details. Also note that if you really want register_globals = on and the host has it off, you _may_ (depending on the hosts configurations) be able to use .htaccess (or equivalent) with something like: php_flag register_globals on Yes there are a lot of options, variety is the spice of life. Regards, Philip Olson __ 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: tutorial on global variables
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
Re: [PHP] Re: tutorial on global variables
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
Re: [PHP] Re: tutorial on global variables
On Sunday 28 April 2002 04:39, Henrik Hansen wrote:
[EMAIL PROTECTED] (John Hughes) wrote:
Can someone point me toward a tutorial on the proper use of global
references under PHP4.
The manual has very good information.
I have been declaring
function something()
{
global $foo, $bar;
/* some actions */
}
in functions and I understand that this is not the way I'm supposed
to be doing this. Or there is a new way that is preferred.
That is a perfectly valid declaration, but without knowing your intent one
cannot say whether it is 'right' or 'wrong'.
The thing you need to remember with PHP is that unlike many other languages,
by default variables are not global in nature. Thus in order to use a
variable that is defined outside of a function you need to declare it like
you have above.
you can do it that way, but if you want to avoid calling global all
the time you might consider this approach:
$GLOBALS[foo] = 123;
$foo = 123; # No need to use the $GLOBALS array when outside of a function
function something()
{
echo $GLOBALS[foo];
}
--
Jason Wong - Gremlins Associates - www.gremlins.com.hk
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
/*
...if the church put in half the time on covetousness that it does on lust,
this would be a better world. - Garrison Keillor, Lake Wobegon Days
*/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
