We get this PHP warning intermittently in a shared hosting error log, running PHP 5.2.5 under Linux:
PHP Warning:
Unknown: Your script possibly relies on a session side-effect which existed until PHP 4.2.3.
Please be advised that the session extension does not consider global variables as a source of data,
unless register_globals is enabled. You can disable this functionality and this warning by setting
session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0
There are about a dozen PHP scripts in the folder. They run up to 250 times a day, but never generate
more than 5 or ten of such warnings a day. As you can see, the warning does not identify the script
which generated it.
PHP Designer does not issue these warnings on these scripts. We do not see them where the scripts are developed and tested (under IIS).
How do we find the script(s) responsible for this warning? What should we be looking for?
pzb
PHP warning: global variables as a source of data
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: PHP warning: global variables as a source of data
Thanks. I'd Googled a different part of the warning string and missed the hits you reference.
But I'm still in the dark. One would have thought that "You can disable this functionality" refers to the functionality of assigning globals to session vars, which these scripts do indeed rely upon here and there (skipping the intermediate step of assigning them to ordinary $vars first). Yet when these scripts run under IIS and PHP 5.2.5 where session.bug_compat_42 is _off_, such global-to-session assignment works fine without error or warning. Does "You can disable this functionality" refer to disabling such assignment functionality, or to the functionality of warnings about ?
pzb
But I'm still in the dark. One would have thought that "You can disable this functionality" refers to the functionality of assigning globals to session vars, which these scripts do indeed rely upon here and there (skipping the intermediate step of assigning them to ordinary $vars first). Yet when these scripts run under IIS and PHP 5.2.5 where session.bug_compat_42 is _off_, such global-to-session assignment works fine without error or warning. Does "You can disable this functionality" refer to disabling such assignment functionality, or to the functionality of warnings about ?
pzb
Re: PHP warning: global variables as a source of data
And BTW what's the rationale for omitting script name & line number from the warning?
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: PHP warning: global variables as a source of data
That's probably because the code was running after all that stack frame info was lost (when the script was shutting down and the session was being written).pzbrawl wrote:And BTW what's the rationale for omitting script name & line number from the warning?
I've never seen such an informative error message, but basically your script is using variable like:
Code: Select all
echo $foo;
//instead of
echo $_SESSION['foo'];EDIT | Scrap that, I'm jumping to conclusions too quickly...
Re: PHP warning: global variables as a source of data
Chris,
Thanks for responding. There's no code like your snippet. There are instances of
IF( isset( $_POST['foo'] ))
$_SESSION['foo'] = $_POST['foo'].
We have no more such warnings since we added
ini_set( "session_bug_compat_42", 0 );
to session configuration scripts, but unless that remains the case for a week or so, it's not dispositive: the warnings would typically appear in bunches, then vanish for a few days, even though scripts in that folder run a couple of hundred times a day. What could cause that?
Thanks for responding. There's no code like your snippet. There are instances of
IF( isset( $_POST['foo'] ))
$_SESSION['foo'] = $_POST['foo'].
We have no more such warnings since we added
ini_set( "session_bug_compat_42", 0 );
to session configuration scripts, but unless that remains the case for a week or so, it's not dispositive: the warnings would typically appear in bunches, then vanish for a few days, even though scripts in that folder run a couple of hundred times a day. What could cause that?