Uhm, what is a command that exists in php 4.1 or greater, that doesn't exist in 4.0 or less? can you query the ini to determine if register globals is off?
Do HTTP_*_VARS have the same structure without regisered globals or throughout older versions of php?
Im trying to make my application portable to multiple server configs. (with/without register_globals, older/newer versions of php)
Also trying to work on the best way to do the session id handling, but that's another post
-flif any server is still running pre-4.1, they should promptly be kicked in the shins. i really doubt that many people have it.
you should always code as if register globals were off, and if you are doing it for a wide release, you should code it as if all errors, warnings, and notices are displayed.
if you are that worried about backwards compatibility with the superglobals, you could probably do something like this
if (!isset($_POST)) {
$_POST = $HTTP_POST_VARS;
$_GET = $HTTP_GET_VARS;
//etc...
}funny you should say that n8. my host still uses 4.0.1 and yes I have told them to upgrade but they said unless there is a security problem or something disasterous they will not update. I even tried them to update mysql a few revision just so I can use a few commands not in 3.23. same attitude there.
but yes forlamp, what n8 said should be the way you look at things. don't code for anything less than 4.1 and always expect register_globals are off.
HTTP_*_VARS are deprecated and shouldn't be used. they are trying to phase them out now that we have the superglobals.funny you should say that n8. my host still uses 4.0.1 and yes I have told them to upgrade but they said unless there is a security problem or something disasterous they will not update. I even tried them to update mysql a few revision just so I can use a few commands not in 3.23. same attitude there.
you should kick them in the shins, and then shake your finger at themso if i code as if register_globals were always off, it will still work on older verions correct?
if (!function_exists("import_request_variables") &&
!ini_get("register_globals")) // 4.1+
{
import_request_variables("CGP", "");
$HTTP_COOKIE_VARS = $_COOKIE;
$HTTP_GET_VARS = $_GET;
$HTTP_POST_VARS = $_POST;
$PHP_SELF = $_SERVER["PHP_SELF"];
$SEVER_NAME = $_SERVER["SERVER_NAME"];
// and so on and so on...
}
that would work for the register globals part wouldn't it?
-fldo you understand what register globals is?
register globals just makes a variable out of whatever is int the superglobals. say you had a query string that was "?foo=bar", instead of having to do $_GET['foo'], you would only have to do $foo if register globals was on. it doesnt have anything to do with using $HTTP_GET_VARS as opposed to $_GET. $HTTP_GET_VARS is jsut the old version of $_GET. you should use $_GET, not $HTTP_GET_VARS. i would be more worried about forward compatibility than backwards compatibility.when dealing with newer version of php, the $HTTP_*_VARS doesn't exist anymore (deprecated), and i know, the vars aren't automagically allocated into the global scope, however, if you do a check against a function/var that exists in post 4.1, and create a single variable name entity to use throughout the rest of the script that works with both naming schemes, and you have a function further down your script that globalizes the variables anyway (after some validation), then creating a pointer of HTTP_POST_VARS to point to $_POST is not breaking the compatability. cuz then you can run a singular extract() or whichever method you like to do on the portable variable name... cuz if its an older version of php the $_POST doesnt exist, so you can safely use the HTTP_POST_VARS the same was as the _POST, just with a single name. makes things easier doesn't it? i belive so. and narrowing out backwards compatability is utterly foolish when creating a portable codebase.
-fl
i just want to know if import_request_variables is only post php 4.1...the manual is your best friend (<!-- m --><a class="postlink" href="http://us4.php.net/import_request_variables">http://us4.php.net/import_request_variables</a><!-- m -->)
its only available 4.1+this is how I look at it. you can disagree if you want.
anything below 4.1 is a security hazard. I do not code for anything below that. if you run it you should be shot. also if you run some function in the newer version of php that is faster and more effiecent then the old function then you really can't make it backwards compatible can you?
the whole purpose to move forward is the security and ease of usability. if you keep going back then how are we suppose to be getting out of that era? just like the brwosers, we can't get rid of the old browsers Netscape 4.x or IE 5 because people still use them. if you stop then we can move on and make it better.valid point, however some clients who invest large amounts of money in things think otherwise
-flif they invest a lot of money then they should have gotten a host that has better equipment.
Do HTTP_*_VARS have the same structure without regisered globals or throughout older versions of php?
Im trying to make my application portable to multiple server configs. (with/without register_globals, older/newer versions of php)
Also trying to work on the best way to do the session id handling, but that's another post
-flif any server is still running pre-4.1, they should promptly be kicked in the shins. i really doubt that many people have it.
you should always code as if register globals were off, and if you are doing it for a wide release, you should code it as if all errors, warnings, and notices are displayed.
if you are that worried about backwards compatibility with the superglobals, you could probably do something like this
if (!isset($_POST)) {
$_POST = $HTTP_POST_VARS;
$_GET = $HTTP_GET_VARS;
//etc...
}funny you should say that n8. my host still uses 4.0.1 and yes I have told them to upgrade but they said unless there is a security problem or something disasterous they will not update. I even tried them to update mysql a few revision just so I can use a few commands not in 3.23. same attitude there.
but yes forlamp, what n8 said should be the way you look at things. don't code for anything less than 4.1 and always expect register_globals are off.
HTTP_*_VARS are deprecated and shouldn't be used. they are trying to phase them out now that we have the superglobals.funny you should say that n8. my host still uses 4.0.1 and yes I have told them to upgrade but they said unless there is a security problem or something disasterous they will not update. I even tried them to update mysql a few revision just so I can use a few commands not in 3.23. same attitude there.
you should kick them in the shins, and then shake your finger at themso if i code as if register_globals were always off, it will still work on older verions correct?
if (!function_exists("import_request_variables") &&
!ini_get("register_globals")) // 4.1+
{
import_request_variables("CGP", "");
$HTTP_COOKIE_VARS = $_COOKIE;
$HTTP_GET_VARS = $_GET;
$HTTP_POST_VARS = $_POST;
$PHP_SELF = $_SERVER["PHP_SELF"];
$SEVER_NAME = $_SERVER["SERVER_NAME"];
// and so on and so on...
}
that would work for the register globals part wouldn't it?
-fldo you understand what register globals is?
register globals just makes a variable out of whatever is int the superglobals. say you had a query string that was "?foo=bar", instead of having to do $_GET['foo'], you would only have to do $foo if register globals was on. it doesnt have anything to do with using $HTTP_GET_VARS as opposed to $_GET. $HTTP_GET_VARS is jsut the old version of $_GET. you should use $_GET, not $HTTP_GET_VARS. i would be more worried about forward compatibility than backwards compatibility.when dealing with newer version of php, the $HTTP_*_VARS doesn't exist anymore (deprecated), and i know, the vars aren't automagically allocated into the global scope, however, if you do a check against a function/var that exists in post 4.1, and create a single variable name entity to use throughout the rest of the script that works with both naming schemes, and you have a function further down your script that globalizes the variables anyway (after some validation), then creating a pointer of HTTP_POST_VARS to point to $_POST is not breaking the compatability. cuz then you can run a singular extract() or whichever method you like to do on the portable variable name... cuz if its an older version of php the $_POST doesnt exist, so you can safely use the HTTP_POST_VARS the same was as the _POST, just with a single name. makes things easier doesn't it? i belive so. and narrowing out backwards compatability is utterly foolish when creating a portable codebase.
-fl
i just want to know if import_request_variables is only post php 4.1...the manual is your best friend (<!-- m --><a class="postlink" href="http://us4.php.net/import_request_variables">http://us4.php.net/import_request_variables</a><!-- m -->)
its only available 4.1+this is how I look at it. you can disagree if you want.
anything below 4.1 is a security hazard. I do not code for anything below that. if you run it you should be shot. also if you run some function in the newer version of php that is faster and more effiecent then the old function then you really can't make it backwards compatible can you?
the whole purpose to move forward is the security and ease of usability. if you keep going back then how are we suppose to be getting out of that era? just like the brwosers, we can't get rid of the old browsers Netscape 4.x or IE 5 because people still use them. if you stop then we can move on and make it better.valid point, however some clients who invest large amounts of money in things think otherwise
-flif they invest a lot of money then they should have gotten a host that has better equipment.