Re: php 5.04 register_globals aint acting right.

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);
    }

}