register globals --> SUPER globals problem

[Parham]

I'm in the process of changing a HUGE program from using register globals (icky yes i know) to super globals.  I came across a problem where several portions of the script relied both on GET and POST request methods (thus using register globals really made it easy).  I'm now tempted to use $_REQUEST, but it includes cookies (pgc).  I was wondering how the rest of you dealt with variables that came from more than one request type.  I was going to use if statements to set up the variables depending on which one of GET or POST was set, but that's a pain.  Should I just give into $_REQUEST?

[[Unknown]]

Just do this:

$_REQUEST = $_POST + $_GET;

SMF does it .

-[Unknown]

[Parham]

HOLY COW...!!!!!!!!!!!!!!!!!!!!!!!

[Parham]

ok goodie... use $_POST where i know i'll get POST requests... use $_GET where i know i'll get GET requestions, use $_REQUEST where i might get both type of requests.  unknown, post this as a comment in the tutorials, this is a great tip

[David]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

[Parham]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

but then you'd have to globalize it.  I wanted to ignore that whole aspect.  I just realized what if $_POST and $_GET ahve overlapping values?

[David]

True.

[Jack.R.Abbit™]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

but then you'd have to globalize it.  I wanted to ignore that whole aspect.  I just realized what if $_POST and $_GET ahve overlapping values?

you could use $GLOBALS['GETPOST'] since $GLOBALS is already "globalized".  You just have to deal with the extra array element.  Not a big deal.

[Parham]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

but then you'd have to globalize it.  I wanted to ignore that whole aspect.  I just realized what if $_POST and $_GET ahve overlapping values?

you could use $GLOBALS['GETPOST'] since $GLOBALS is already "globalized".  You just have to deal with the extra array element.  Not a big deal.

isn't GLOBALS deprecatd?  plus globals still has everything in it from all the superglobals

Code Select Expand


<?php

$_GET['a'] = 'hello';
$_GET['b'] = 'hi';
$_POST['b'] = 'bonjour';
$_POST['c'] = 'salam';

//$_REQUEST = $_POST + $_GET; //post will override get with duplicate values
$_REQUEST = $_GET + $_POST; //get will override post in duplicate values

something();

function something() {

print_r($_GET);
print "\n\n";
print_r($_POST);
print "\n\n";
print_r($_REQUEST);

}

?>


[Jack.R.Abbit™]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

but then you'd have to globalize it.  I wanted to ignore that whole aspect.  I just realized what if $_POST and $_GET ahve overlapping values?

you could use $GLOBALS['GETPOST'] since $GLOBALS is already "globalized".  You just have to deal with the extra array element.  Not a big deal.

isn't GLOBALS deprecatd?  plus globals still has everything in it from all the superglobals

http://us4.php.net/manual/en/language.variables.predefined.php doesn't say anything about it being depricated... and its listed first.  True it contains everything and its available everywhere... but it would regardless if you use it or not.  I was simply offering a solution that solves both "issues"... 1) It won't confuse devs that expect $_REQUEST to have cookie data and 2) Its does not need to be "globalized".  I guess I'm not sure what you are trying to achieve.  So what if $_REQUEST includes cookies?

[Parham]

Seems like it makes more sense to like use $_GETPOST or something so not to confuse devs who understand $_REQUEST as including cookie data.

but then you'd have to globalize it.  I wanted to ignore that whole aspect.  I just realized what if $_POST and $_GET ahve overlapping values?

you could use $GLOBALS['GETPOST'] since $GLOBALS is already "globalized".  You just have to deal with the extra array element.  Not a big deal.

isn't GLOBALS deprecatd?  plus globals still has everything in it from all the superglobals

http://us4.php.net/manual/en/language.variables.predefined.php doesn't say anything about it being depricated... and its listed first.  True it contains everything and its available everywhere... but it would regardless if you use it or not.  I was simply offering a solution that solves both "issues"... 1) It won't confuse devs that expect $_REQUEST to have cookie data and 2) Its does not need to be "globalized".  I guess I'm not sure what you are trying to achieve.  So what if $_REQUEST includes cookies?

it just bugged me that's all.  I also find it funny how the documentation labels $_REQUEST as unsecure ("it can't be trusted") while $GLOBALS has no such warning.  You're right though Jack.R.Abbit, my mind completely slipped on $GLOBALS.  I guess I was just looking for something which resembled the rest of the superglobals .

[Jack.R.Abbit™]

Well, its up to you since you're the dev.  I don't know if there even is just one right answer to this.


hmmm... why didn't that url parse?

[[Unknown]]

You put it immediately after a ].  It can't parse those URLs automatically. ([url ]http://www....[/ url])

Anyhow, imho cookies don't belong in $_REQUEST.  I don't even see why you'd have them there.  They aren't "request" variables because, unlike get and post, they are not used to *request* anything.

-[Unknown]

[Jack.R.Abbit™]

Anyhow, imho cookies don't belong in $_REQUEST.  I don't even see why you'd have them there.  They aren't "request" variables because, unlike get and post, they are not used to *request* anything.

I'd have to agree with that... but the question is not really "should they be there?"... but rather, "does being there cause enough harm that it is worth the step to take them out?"

[[Unknown]]

SMF has to refill it because GET is wrong with ; on 99% of all servers.

-[Unknown]