Richard Lynch wrote:
On Wed, August 17, 2005 5:21 am, Jochem Maas wrote:
Daniel Baughman wrote:
Its simply a Boolean to indicate whether or not a query should be
ran and
displayed, and further more its for a small intranet.
If it's that small a project/program, it should not be that tricky to
find the variable that needs to change from $foo to $_POST['foo']
Register_globals is the directive I meant to say. But your right
about
globals. Some applications haven't made that change yet... So
stick this in a auto_prepend_file (or at the top of a global include:
<?
extract($_REQUEST);
?>
crude, but not exactly a rewrite.
You might as well just turn register_globals "on"
Because this has ALL the problems of register_globals.
bar 1. namely the problem of not upgrading to recent version of php (i.e.
something beginning with 5 ;-) because 'my code will break'.
I don't think upgrading and then turning on the ini setting is a good idea...
the legacy app is a problem by definition because it uses register globals, but
that doesn't mean one has to keep that door open for new apps, besides changing
ini settings, at least having an app rely on the changes, from the default leads
to less portable code.
Only maybe slightly slower, since it's wrapped up in a PHP function call.
extract($_REQUEST) is like installing a deadbolt on your door, and
then leaving the key in it at all times.
true. I was just pointing out how easy it is to 'fake' register_globals
personally all my code currently runs this on init - because I don't
like reg.globals at all:
function unRegisterGlobals()
{
if (ini_get('register_globals')) {
$SGs = array($_SERVER, $_ENV, $_FILES, $_COOKIE, $_POST, $_GET);
if (isset($_SESSION)) { array_unshift($SGs, $_SESSION); }
foreach ($SGs as $sg) {
foreach ($superglobal as $k => $v) { unset($GLOBALS[ $k ]); }
}
ini_set('register_globals', false);
}
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
