On 11 April 2008 14:45, tedd advised:

> At 10:12 PM -0400 4/10/08, Eric Wood wrote:
>> tedd wrote:
>>>
>>> [1] http://www.webbytedd.com/x/index.php
>>> [2] http://sperling.com/x/index.php
>>>
>>> Both of these demos have the exact same code; and are on the same
>>> server; with exactly the same php-info -- so, why do they behave
>>> differently re sessions?
>>
>> Strange. I've run into issues whenever I use variable names which
>> are the same as session variables. It's as if they step on each
>> others toes. I try to use uniq var names. I've also recently run
>> into customized 401 pages (which you may not see happen, check the
>> logs) start up and the session data gets overwrite due to a lack of
>> session file locking. -eric
>
>
> -eric:
>
> You didn't provide the reason why, but you did provide a solution.
>
> Changing the variable names to be different than the session names
fixed
> the problem.
>
> Now, if any php guru would care to tell me why, I would
> really like to know.

Sounds like a register_globals=On issue....


--
Mike Ford, Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 812 4730 Fax: +44 113 812 3211


To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm

On Fri, Apr 11, 2008 at 10:29 AM, Ford, Mike <M.Ford@leedsmet.ac.uk> wrote:
>
> Sounds like a register_globals=On issue....

It does to me, as well. I know, Tedd, that on the php1.net site
that you mentioned to me off-list, I'm about 99% positive that it's
the reason. Shared hosts generally keep register_globals on and leave
it up to the individual customer to turn it off. On that particular
server, though, since it's mostly developers, I may just send out an
email to get feedback and turn it off at the main, and then allow
ya'all to override it on your individual sites.

The thing that makes me wonder (and I haven't checked myself to
verify) is why two sites, on the same server, having the same
phpinfo() output, would have different results.

--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting @ $59.99/mo., VPS starting @ $19.99/mo.,
and shared hosting starting @ $2.50/mo.
Unmanaged, managed, and fully-managed!

On Fri, Apr 11, 2008 at 5:34 PM, tedd <tedd.sperling@gmail.com> wrote:
> At 11:33 AM -0400 4/11/08, Daniel Brown wrote:
>
> > On Fri, Apr 11, 2008 at 10:29 AM, Ford, Mike <M.Ford@leedsmet.ac.uk>
> wrote:
> >
> > >
> > > Sounds like a register_globals=On issue....
> > >
> >
> > It does to me, as well. I know, Tedd, that on the php1.net site
> > that you mentioned to me off-list, I'm about 99% positive that it's
> > the reason. Shared hosts generally keep register_globals on and leave
> > it up to the individual customer to turn it off. On that particular
> > server, though, since it's mostly developers, I may just send out an
> > email to get feedback and turn it off at the main, and then allow
> > ya'all to override it on your individual sites.
> >
> > The thing that makes me wonder (and I haven't checked myself to
> > verify) is why two sites, on the same server, having the same
> >
>
> Hey!
>
> I found it and you were right.
>
> On my webbytedd.com site, I had a htaccess file that read:
>
> AddDefaultCharset utf-8
>
> php_value register_globals 0
> php_value magic_quotes_gpc 0
> php_value magic_quotes_sybase 0
> php_value magic_quotes_runtime 0
>
> And I didn't have that htaccess file on my sperling.com site. However, what
> fooled me was in both scripts I had:
>
> ini_set( 'register_globals', '0' );
>
> So, I thought that was the same, but apparently it's not. Maybe because my
> server had safe_mode ON it won't allow it -- I don't know. Another question
> for another time.
>
> Thanks a bunch guys!
>
> Cheers,
>
> tedd
>
> PS: I did try the session_write_close and several other suggestions, but
> none worked.


The register_globals value is something that cannot be set at runtime.
If you pass it to ini_set(), it will appear to work -- you won't get
an error and successive calls to phpinfo() will show the new value;
however, by the time PHP gets far enough down the chain to execute
your ini_set() command, PHP has already determined whether it should
register global variables. The manual indicates that this wasn't
always the case, but (not knowing the internals then or now) I don't
understand how. (The table on that page says it was PHP_INI_ALL for
versions up to 4.2.3.)

http://us.php.net/manual/en/ini.core...gister-globals

Andrew