| Completely stumped [message #185031] |
Mon, 24 February 2014 22:51  |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
Sorry for the vague subject heading but i didn't know what else to put
there. I have a script that works fine on my local server, and that I
am using with no problem on three other production servers.
However, on another production server it is failing in a very weird
way. I get the message "Fatal error: cannot use string as offset in
array" when it gets to this line:
$fname=$_SESSION['to'][$ct]['fname'];
I var_dumped the $_SESSION['to'] array to see what was going on and
got this:
string(23) "dyates(at)salemharvest(dot)org"
So, the error seems to make sense given what is apparently in
$_SESSION[to']. But that is not what is supposed to be in
$_SESSION['to']. On the other servers - with IDENTICAL code - the
script works and the variable dump is like this, as it is supposed to
be:
array (size=2)
0 =>
array (size=3)
'fname' => string 'Dick' (length=4)
'lname' => string 'Yates' (length=5)
'email' => string 'dyates(at)salemharvest(dot)org' (length=23)
1 =>
array (size=3)
'fname' => string 'Benjamin' (length=8)
'lname' => string 'Rasmus' (length=6)
'email' => string 'benjamin(at)harvest(dot)org' (length=25)
The only difference I can find in the servers is that the ones that
work are running php5.3 and the bad one is running php5.2. But I
cannot see how that could account for this error.
At this point I do not even know where to look to track this down.
Does anyone have any ideas?
Richard Yates
|
|
|
|
| Re: Completely stumped (still) [message #185033 is a reply to message #185031] |
Mon, 24 February 2014 23:53  |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Mon, 24 Feb 2014 14:51:23 -0800, Richard Yates
<richard(at)yatesguitar(dot)com> wrote:
> Sorry for the vague subject heading but i didn't know what else to put
> there. I have a script that works fine on my local server, and that I
> am using with no problem on three other production servers.
>
> However, on another production server it is failing in a very weird
> way. I get the message "Fatal error: cannot use string as offset in
> array" when it gets to this line:
>
> $fname=$_SESSION['to'][$ct]['fname'];
>
> I var_dumped the $_SESSION['to'] array to see what was going on and
> got this:
>
> string(23) "dyates(at)salemharvest(dot)org"
>
> So, the error seems to make sense given what is apparently in
> $_SESSION[to']. But that is not what is supposed to be in
> $_SESSION['to']. On the other servers - with IDENTICAL code - the
> script works and the variable dump is like this, as it is supposed to
> be:
>
> array (size=2)
> 0 =>
> array (size=3)
> 'fname' => string 'Dick' (length=4)
> 'lname' => string 'Yates' (length=5)
> 'email' => string 'dyates(at)salemharvest(dot)org' (length=23)
> 1 =>
> array (size=3)
> 'fname' => string 'Benjamin' (length=8)
> 'lname' => string 'Rasmus' (length=6)
> 'email' => string 'benjamin(at)harvest(dot)org' (length=25)
>
> The only difference I can find in the servers is that the ones that
> work are running php5.3 and the bad one is running php5.2. But I
> cannot see how that could account for this error.
>
> At this point I do not even know where to look to track this down.
> Does anyone have any ideas?
>
> Richard Yates
I inserted var_dump successively at each stage in the script to see
where it changes from the (correct) array to a (incorrect) string. I
narrowed it down to ONE statement, but cannot see how that could
possibly change the variable. Here's the section with var_dump, then
the one statement, and then the var_dump repeated exactly.
var_dump($_SESSION['to']);
$to=$_SESSION['to'][$ct]['email'];
var_dump($_SESSION['to']);
The output of the two var_dumps is:
The first:
array(1) { [0]=> array(3)
{ ["fname"]=> string(4) "Dick"
["lname"]=> string(5) "Yates"
["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
}
The second:
string(23) "dyates(at)salemharvest(dot)org"
If I comment out the second line (that sets $to), the second var_dump
comes out correct. Am I losing my mind?
|
|
|
|
| Re: Completely stumped (still) [message #185035 is a reply to message #185033] |
Tue, 25 February 2014 00:11 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Richard Yates wrote:
> I inserted var_dump successively at each stage in the script to see
> where it changes from the (correct) array to a (incorrect) string. I
> narrowed it down to ONE statement, but cannot see how that could
> possibly change the variable. Here's the section with var_dump, then
> the one statement, and then the var_dump repeated exactly.
>
> var_dump($_SESSION['to']);
> $to=$_SESSION['to'][$ct]['email'];
> var_dump($_SESSION['to']);
>
> The output of the two var_dumps is:
>
> The first:
> array(1) { [0]=> array(3)
> { ["fname"]=> string(4) "Dick"
> ["lname"]=> string(5) "Yates"
> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
> }
>
> The second:
> string(23) "dyates(at)salemharvest(dot)org"
>
> If I comment out the second line (that sets $to), the second var_dump
> comes out correct. Am I losing my mind?
$to being a reference to $_SESSION['to'] would explain the behavior.
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185036 is a reply to message #185035] |
Tue, 25 February 2014 00:24 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
<cmbecker69(at)arcor(dot)de> wrote:
> Richard Yates wrote:
>
>> I inserted var_dump successively at each stage in the script to see
>> where it changes from the (correct) array to a (incorrect) string. I
>> narrowed it down to ONE statement, but cannot see how that could
>> possibly change the variable. Here's the section with var_dump, then
>> the one statement, and then the var_dump repeated exactly.
>>
>> var_dump($_SESSION['to']);
>> $to=$_SESSION['to'][$ct]['email'];
>> var_dump($_SESSION['to']);
>>
>> The output of the two var_dumps is:
>>
>> The first:
>> array(1) { [0]=> array(3)
>> { ["fname"]=> string(4) "Dick"
>> ["lname"]=> string(5) "Yates"
>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>> }
>>
>> The second:
>> string(23) "dyates(at)salemharvest(dot)org"
>>
>> If I comment out the second line (that sets $to), the second var_dump
>> comes out correct. Am I losing my mind?
>
> $to being a reference to $_SESSION['to'] would explain the behavior.
Thanks, Christropher. In desperation I changed all instances of $to
in the script to $tomail and it fixed the problem!
But I don't understand how setting the variable: $to can affect the
array: $_SESSION['to']? They are completely different variables.
And why would it all work fine on other servers?
|
|
|
|
| Re: Completely stumped (still) [message #185039 is a reply to message #185036] |
Tue, 25 February 2014 00:49 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Richard Yates wrote:
> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
> <cmbecker69(at)arcor(dot)de> wrote:
>
>> Richard Yates wrote:
>>
>>> I inserted var_dump successively at each stage in the script to see
>>> where it changes from the (correct) array to a (incorrect) string. I
>>> narrowed it down to ONE statement, but cannot see how that could
>>> possibly change the variable. Here's the section with var_dump, then
>>> the one statement, and then the var_dump repeated exactly.
>>>
>>> var_dump($_SESSION['to']);
>>> $to=$_SESSION['to'][$ct]['email'];
>>> var_dump($_SESSION['to']);
>>>
>>> The output of the two var_dumps is:
>>>
>>> The first:
>>> array(1) { [0]=> array(3)
>>> { ["fname"]=> string(4) "Dick"
>>> ["lname"]=> string(5) "Yates"
>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>> }
>>>
>>> The second:
>>> string(23) "dyates(at)salemharvest(dot)org"
>>>
>>> If I comment out the second line (that sets $to), the second var_dump
>>> comes out correct. Am I losing my mind?
>>
>> $to being a reference to $_SESSION['to'] would explain the behavior.
>
> Thanks, Christropher. In desperation I changed all instances of $to
> in the script to $tomail and it fixed the problem!
>
> But I don't understand how setting the variable: $to can affect the
> array: $_SESSION['to']? They are completely different variables.
> And why would it all work fine on other servers?
Frankly, I don't know. If I had to examine the issue, I'd probably
check the value of $to at the start of the script execution and directly
after the session start. If $to is set in either case, that would give
a hint. If $to is null at the start of the script execution, but is set
to the value of $_SESSION['to'] after starting the session, checking the
session handler would be appropriate. And if $to is already set at the
beginning of the script execution, checking the register_globals
setting[1] seems appropriate (even if that wouldn't explain the strange
behavior per se).
[1] <http://www.php.net/manual/en/ini.core.php#ini.register-globals>
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185042 is a reply to message #185033] |
Tue, 25 February 2014 01:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/24/2014 6:53 PM, Richard Yates wrote:
> On Mon, 24 Feb 2014 14:51:23 -0800, Richard Yates
> <richard(at)yatesguitar(dot)com> wrote:
>
>> Sorry for the vague subject heading but i didn't know what else to put
>> there. I have a script that works fine on my local server, and that I
>> am using with no problem on three other production servers.
>>
>> However, on another production server it is failing in a very weird
>> way. I get the message "Fatal error: cannot use string as offset in
>> array" when it gets to this line:
>>
>> $fname=$_SESSION['to'][$ct]['fname'];
>>
>> I var_dumped the $_SESSION['to'] array to see what was going on and
>> got this:
>>
>> string(23) "dyates(at)salemharvest(dot)org"
>>
>> So, the error seems to make sense given what is apparently in
>> $_SESSION[to']. But that is not what is supposed to be in
>> $_SESSION['to']. On the other servers - with IDENTICAL code - the
>> script works and the variable dump is like this, as it is supposed to
>> be:
>>
>> array (size=2)
>> 0 =>
>> array (size=3)
>> 'fname' => string 'Dick' (length=4)
>> 'lname' => string 'Yates' (length=5)
>> 'email' => string 'dyates(at)salemharvest(dot)org' (length=23)
>> 1 =>
>> array (size=3)
>> 'fname' => string 'Benjamin' (length=8)
>> 'lname' => string 'Rasmus' (length=6)
>> 'email' => string 'benjamin(at)harvest(dot)org' (length=25)
>>
>> The only difference I can find in the servers is that the ones that
>> work are running php5.3 and the bad one is running php5.2. But I
>> cannot see how that could account for this error.
>>
>> At this point I do not even know where to look to track this down.
>> Does anyone have any ideas?
>>
>> Richard Yates
>
> I inserted var_dump successively at each stage in the script to see
> where it changes from the (correct) array to a (incorrect) string. I
> narrowed it down to ONE statement, but cannot see how that could
> possibly change the variable. Here's the section with var_dump, then
> the one statement, and then the var_dump repeated exactly.
>
> var_dump($_SESSION['to']);
> $to=$_SESSION['to'][$ct]['email'];
> var_dump($_SESSION['to']);
>
> The output of the two var_dumps is:
>
> The first:
> array(1) { [0]=> array(3)
> { ["fname"]=> string(4) "Dick"
> ["lname"]=> string(5) "Yates"
> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
> }
>
> The second:
> string(23) "dyates(at)salemharvest(dot)org"
>
> If I comment out the second line (that sets $to), the second var_dump
> comes out correct. Am I losing my mind?
>
>
The failing server has register_globals enabled.
This value changed to default to OFF in PHP 4.2, has been deprecated in
PHP 5.3, and removed in PHP 5.4. If your hosting company won't disable
it, find another hosting company.
It sounded like a good idea when it was first implemented many years
ago, but has caused more problems than it has solved. Therefore it has
been removed from current releases.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185044 is a reply to message #185039] |
Tue, 25 February 2014 02:37 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Richard Yates wrote:
>> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
>> <cmbecker69(at)arcor(dot)de> wrote:
>>> Richard Yates wrote:
>>>> I inserted var_dump successively at each stage in the script to see
>>>> where it changes from the (correct) array to a (incorrect) string. I
>>>> narrowed it down to ONE statement, but cannot see how that could
>>>> possibly change the variable. Here's the section with var_dump, then
>>>> the one statement, and then the var_dump repeated exactly.
>>>>
>>>> var_dump($_SESSION['to']);
>>>> $to=$_SESSION['to'][$ct]['email'];
>>>> var_dump($_SESSION['to']);
>>>>
>>>> The output of the two var_dumps is:
>>>>
>>>> The first:
>>>> array(1) { [0]=> array(3)
>>>> { ["fname"]=> string(4) "Dick"
>>>> ["lname"]=> string(5) "Yates"
>>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> }
>>>>
>>>> The second:
>>>> string(23) "dyates(at)salemharvest(dot)org"
>>>>
>>>> If I comment out the second line (that sets $to), the second var_dump
>>>> comes out correct. Am I losing my mind?
>>>
>>> $to being a reference to $_SESSION['to'] would explain the behavior.
>>
>> Thanks, Christropher. In desperation I changed all instances of $to
>> in the script to $tomail and it fixed the problem!
>>
>> But I don't understand how setting the variable: $to can affect the
>> array: $_SESSION['to']? They are completely different variables.
>> And why would it all work fine on other servers?
>
> Frankly, I don't know. If I had to examine the issue, I'd probably
> check the value of $to at the start of the script execution and directly
> after the session start. If $to is set in either case, that would give
> a hint. If $to is null at the start of the script execution, but is set
> to the value of $_SESSION['to'] after starting the session, checking the
> session handler would be appropriate. And if $to is already set at the
> beginning of the script execution, checking the register_globals
> setting[1] seems appropriate (even if that wouldn't explain the strange
> behavior per se).
session_register('to');
<http://php.net/session_register> (deprecated since 5.3, removed in 5.4)
would explain it even if
$to =& $_SESSION['to'];
was missing.
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
| Re: Completely stumped (still) [message #185046 is a reply to message #185042] |
Tue, 25 February 2014 03:00 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
>> I inserted var_dump successively at each stage in the script to see
>> where it changes from the (correct) array to a (incorrect) string. I
>> narrowed it down to ONE statement, but cannot see how that could
>> possibly change the variable. Here's the section with var_dump, then
>> the one statement, and then the var_dump repeated exactly.
>>
>> var_dump($_SESSION['to']);
>> $to=$_SESSION['to'][$ct]['email'];
>> var_dump($_SESSION['to']);
>>
>> The output of the two var_dumps is:
>>
>> The first:
>> array(1) { [0]=> array(3)
>> { ["fname"]=> string(4) "Dick"
>> ["lname"]=> string(5) "Yates"
>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>> }
>>
>> The second:
>> string(23) "dyates(at)salemharvest(dot)org"
>>
>> If I comment out the second line (that sets $to), the second var_dump
>> comes out correct. Am I losing my mind?
>>
>
> The failing server has register_globals enabled.
>
> This value changed to default to OFF in PHP 4.2, has been deprecated in
> PHP 5.3, and removed in PHP 5.4. If your hosting company won't disable
> it, find another hosting company.
>
> It sounded like a good idea when it was first implemented many years
> ago, but has caused more problems than it has solved. Therefore it has
> been removed from current releases.
Thank you, Jerry. You are correct - I checked phpinfo() and found
register_globals enabled. I don't have a choice about the server,
unfortunately. FYI it is at networksolutions.com. Changing the name of
the variable $to has fixed the problem.
Richard Yates
|
|
|
|
| Re: Completely stumped (still) [message #185047 is a reply to message #185044] |
Tue, 25 February 2014 03:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Richard Yates wrote:
>>> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
>>> <cmbecker69(at)arcor(dot)de> wrote:
>>>> Richard Yates wrote:
>>>> > I inserted var_dump successively at each stage in the script to see
>>>> > where it changes from the (correct) array to a (incorrect) string. I
>>>> > narrowed it down to ONE statement, but cannot see how that could
>>>> > possibly change the variable. Here's the section with var_dump, then
>>>> > the one statement, and then the var_dump repeated exactly.
>>>> >
>>>> > var_dump($_SESSION['to']);
>>>> > $to=$_SESSION['to'][$ct]['email'];
>>>> > var_dump($_SESSION['to']);
>>>> >
>>>> > The output of the two var_dumps is:
>>>> >
>>>> > The first:
>>>> > array(1) { [0]=> array(3)
>>>> > { ["fname"]=> string(4) "Dick"
>>>> > ["lname"]=> string(5) "Yates"
>>>> > ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> > }
>>>> >
>>>> > The second:
>>>> > string(23) "dyates(at)salemharvest(dot)org"
>>>> >
>>>> > If I comment out the second line (that sets $to), the second var_dump
>>>> > comes out correct. Am I losing my mind?
>>>>
>>>> $to being a reference to $_SESSION['to'] would explain the behavior.
>>>
>>> Thanks, Christropher. In desperation I changed all instances of $to
>>> in the script to $tomail and it fixed the problem!
>>>
>>> But I don't understand how setting the variable: $to can affect the
>>> array: $_SESSION['to']? They are completely different variables.
>>> And why would it all work fine on other servers?
>>
>> Frankly, I don't know. If I had to examine the issue, I'd probably
>> check the value of $to at the start of the script execution and directly
>> after the session start. If $to is set in either case, that would give
>> a hint. If $to is null at the start of the script execution, but is set
>> to the value of $_SESSION['to'] after starting the session, checking the
>> session handler would be appropriate. And if $to is already set at the
>> beginning of the script execution, checking the register_globals
>> setting[1] seems appropriate (even if that wouldn't explain the strange
>> behavior per se).
>
> session_register('to');
>
> <http://php.net/session_register> (deprecated since 5.3, removed in 5.4)
> would explain it even if
>
> $to =& $_SESSION['to'];
>
> was missing.
>
>
> PointedEars
>
If that were the case, it would fail on all his systems. Note he is
running the same code on 4 different systems, but it only fails on one.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185048 is a reply to message #185046] |
Tue, 25 February 2014 03:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/24/2014 10:00 PM, Richard Yates wrote:
> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
> <jstucklex(at)attglobal(dot)net> wrote:
>
>>> I inserted var_dump successively at each stage in the script to see
>>> where it changes from the (correct) array to a (incorrect) string. I
>>> narrowed it down to ONE statement, but cannot see how that could
>>> possibly change the variable. Here's the section with var_dump, then
>>> the one statement, and then the var_dump repeated exactly.
>>>
>>> var_dump($_SESSION['to']);
>>> $to=$_SESSION['to'][$ct]['email'];
>>> var_dump($_SESSION['to']);
>>>
>>> The output of the two var_dumps is:
>>>
>>> The first:
>>> array(1) { [0]=> array(3)
>>> { ["fname"]=> string(4) "Dick"
>>> ["lname"]=> string(5) "Yates"
>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>> }
>>>
>>> The second:
>>> string(23) "dyates(at)salemharvest(dot)org"
>>>
>>> If I comment out the second line (that sets $to), the second var_dump
>>> comes out correct. Am I losing my mind?
>>>
>>
>> The failing server has register_globals enabled.
>>
>> This value changed to default to OFF in PHP 4.2, has been deprecated in
>> PHP 5.3, and removed in PHP 5.4. If your hosting company won't disable
>> it, find another hosting company.
>>
>> It sounded like a good idea when it was first implemented many years
>> ago, but has caused more problems than it has solved. Therefore it has
>> been removed from current releases.
>
> Thank you, Jerry. You are correct - I checked phpinfo() and found
> register_globals enabled. I don't have a choice about the server,
> unfortunately. FYI it is at networksolutions.com. Changing the name of
> the variable $to has fixed the problem.
>
> Richard Yates
>
Yes, you do have a choice. There are much better (and less expensive)
hosting companies around.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185058 is a reply to message #185048] |
Tue, 25 February 2014 05:09 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Mon, 24 Feb 2014 22:04:47 -0500, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
> On 2/24/2014 10:00 PM, Richard Yates wrote:
>> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
>> <jstucklex(at)attglobal(dot)net> wrote:
>>
>>>> I inserted var_dump successively at each stage in the script to see
>>>> where it changes from the (correct) array to a (incorrect) string. I
>>>> narrowed it down to ONE statement, but cannot see how that could
>>>> possibly change the variable. Here's the section with var_dump, then
>>>> the one statement, and then the var_dump repeated exactly.
>>>>
>>>> var_dump($_SESSION['to']);
>>>> $to=$_SESSION['to'][$ct]['email'];
>>>> var_dump($_SESSION['to']);
>>>>
>>>> The output of the two var_dumps is:
>>>>
>>>> The first:
>>>> array(1) { [0]=> array(3)
>>>> { ["fname"]=> string(4) "Dick"
>>>> ["lname"]=> string(5) "Yates"
>>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> }
>>>>
>>>> The second:
>>>> string(23) "dyates(at)salemharvest(dot)org"
>>>>
>>>> If I comment out the second line (that sets $to), the second var_dump
>>>> comes out correct. Am I losing my mind?
>>>>
>>>
>>> The failing server has register_globals enabled.
>>>
>>> This value changed to default to OFF in PHP 4.2, has been deprecated in
>>> PHP 5.3, and removed in PHP 5.4. If your hosting company won't disable
>>> it, find another hosting company.
>>>
>>> It sounded like a good idea when it was first implemented many years
>>> ago, but has caused more problems than it has solved. Therefore it has
>>> been removed from current releases.
>>
>> Thank you, Jerry. You are correct - I checked phpinfo() and found
>> register_globals enabled. I don't have a choice about the server,
>> unfortunately. FYI it is at networksolutions.com. Changing the name of
>> the variable $to has fixed the problem.
>>
>> Richard Yates
>>
>
> Yes, you do have a choice. There are much better (and less expensive)
> hosting companies around.
The other sites I manage I have a choice about (and highly recommend
Total Choice Hosting), but this one has software I wrote and installed
where someone else owns the site.
I will see if register_globals can be turned off for this particular
site and, otherwise, I assume I have to check all SESSION variable
names to see if they might interfere with other variables names that I
use.
|
|
|
|
| Re: Completely stumped (still) [message #185059 is a reply to message #185058] |
Tue, 25 February 2014 05:30 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Mon, 24 Feb 2014 21:09:40 -0800, Richard Yates
<richard(at)yatesguitar(dot)com> wrote:
> On Mon, 24 Feb 2014 22:04:47 -0500, Jerry Stuckle
> <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 2/24/2014 10:00 PM, Richard Yates wrote:
>>> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
>>> <jstucklex(at)attglobal(dot)net> wrote:
>>>
>>>> > I inserted var_dump successively at each stage in the script to see
>>>> > where it changes from the (correct) array to a (incorrect) string. I
>>>> > narrowed it down to ONE statement, but cannot see how that could
>>>> > possibly change the variable. Here's the section with var_dump, then
>>>> > the one statement, and then the var_dump repeated exactly.
>>>> >
>>>> > var_dump($_SESSION['to']);
>>>> > $to=$_SESSION['to'][$ct]['email'];
>>>> > var_dump($_SESSION['to']);
>>>> >
>>>> > The output of the two var_dumps is:
>>>> >
>>>> > The first:
>>>> > array(1) { [0]=> array(3)
>>>> > { ["fname"]=> string(4) "Dick"
>>>> > ["lname"]=> string(5) "Yates"
>>>> > ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> > }
>>>> >
>>>> > The second:
>>>> > string(23) "dyates(at)salemharvest(dot)org"
>>>> >
>>>> > If I comment out the second line (that sets $to), the second var_dump
>>>> > comes out correct. Am I losing my mind?
>>>> >
>>>>
>>>> The failing server has register_globals enabled.
>>>>
>>>> This value changed to default to OFF in PHP 4.2, has been deprecated in
>>>> PHP 5.3, and removed in PHP 5.4. If your hosting company won't disable
>>>> it, find another hosting company.
>>>>
>>>> It sounded like a good idea when it was first implemented many years
>>>> ago, but has caused more problems than it has solved. Therefore it has
>>>> been removed from current releases.
>>>
>>> Thank you, Jerry. You are correct - I checked phpinfo() and found
>>> register_globals enabled. I don't have a choice about the server,
>>> unfortunately. FYI it is at networksolutions.com. Changing the name of
>>> the variable $to has fixed the problem.
>>>
>>> Richard Yates
>>>
>>
>> Yes, you do have a choice. There are much better (and less expensive)
>> hosting companies around.
>
> The other sites I manage I have a choice about (and highly recommend
> Total Choice Hosting), but this one has software I wrote and installed
> where someone else owns the site.
>
> I will see if register_globals can be turned off for this particular
> site and, otherwise, I assume I have to check all SESSION variable
> names to see if they might interfere with other variables names that I
> use.
It turns out that networksolutions has a cPanel utility called php.ini
EZconfig that has simple radio buttons and text fields for changing
the php.ini file. It worked quite nicely and register_globals is now
off.
|
|
|
|
| Re: Completely stumped (still) [message #185062 is a reply to message #185047] |
Tue, 25 February 2014 18:38 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Richard Yates wrote:
>>>> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
>>>> <cmbecker69(at)arcor(dot)de> wrote:
>>>> > Richard Yates wrote:
>>>> >> I inserted var_dump successively at each stage in the script to see
>>>> >> where it changes from the (correct) array to a (incorrect) string. I
>>>> >> narrowed it down to ONE statement, but cannot see how that could
>>>> >> possibly change the variable. Here's the section with var_dump, then
>>>> >> the one statement, and then the var_dump repeated exactly.
>>>> >>
>>>> >> var_dump($_SESSION['to']);
>>>> >> $to=$_SESSION['to'][$ct]['email'];
>>>> >> var_dump($_SESSION['to']);
>>>> >>
>>>> >> The output of the two var_dumps is:
>>>> >>
>>>> >> The first:
>>>> >> array(1) { [0]=> array(3)
>>>> >> { ["fname"]=> string(4) "Dick"
>>>> >> ["lname"]=> string(5) "Yates"
>>>> >> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> >> }
>>>> >>
>>>> >> The second:
>>>> >> string(23) "dyates(at)salemharvest(dot)org"
>>>> >>
>>>> >> If I comment out the second line (that sets $to), the second
>>>> >> var_dump comes out correct. Am I losing my mind?
>>>> >
>>>> > $to being a reference to $_SESSION['to'] would explain the behavior.
>>>>
>>>> Thanks, Christropher. In desperation I changed all instances of $to
>>>> in the script to $tomail and it fixed the problem!
>>>>
>>>> But I don't understand how setting the variable: $to can affect the
>>>> array: $_SESSION['to']? They are completely different variables.
>>>> And why would it all work fine on other servers?
>>>
>>> Frankly, I don't know. If I had to examine the issue, I'd probably
>>> check the value of $to at the start of the script execution and directly
>>> after the session start. If $to is set in either case, that would give
>>> a hint. If $to is null at the start of the script execution, but is set
>>> to the value of $_SESSION['to'] after starting the session, checking the
>>> session handler would be appropriate. And if $to is already set at the
>>> beginning of the script execution, checking the register_globals
>>> setting[1] seems appropriate (even if that wouldn't explain the strange
>>> behavior per se).
>>
>> session_register('to');
>>
>> <http://php.net/session_register> (deprecated since 5.3, removed in 5.4)
>> would explain it even if
>>
>> $to =& $_SESSION['to'];
>>
>> was missing.
>
> If that were the case, it would fail on all his systems. Note he is
> running the same code on 4 different systems, but it only fails on one.
There are too many unknowns here to be certain. There could be
conditionally executed statements. There could be auto_prepend_file. There
could be extensions interfering. And so on.
However, I am willing to concede to you that “register_globals = on”, which
you suggested elsewhere, is the Occam’s-razor-explanation here.
Never having relied on it, I was not aware that this directive would affect
$_SESSION as well, and that session_register() does not work with
“register_globals = off” (which explains why that function was removed as of
PHP 5.4 as well, see bottom):
,--[ibid.]
|
| Caution
| If you want your script to work regardless of register_globals, you need
| to instead use the $_SESSION array as $_SESSION entries are automatically
| registered. If your script uses session_register(), it will not work in
| environments where the PHP directive register_globals is disabled.
If “register_globals” is the culprit, it has to be "on" on this one system
which must run PHP 5.3 or earlier; either it has to be "off" on the other
three systems, or they must run PHP 5.4 or newer (where the directive is no
longer supported), respectively.
The OP should call phpinfo() to check the used PHP version and the actual
value of the setting; they should check the .htaccess, and .config files in
that directory and up to the document root, the virtual host configuration
(if any; unfortunately, the aforementioned files are not listed by
phpinfo()), and the configuration files listed by phpinfo(), for the
directive.
And they should stop writing/using PHP programs that require the setting to
be "on" now, before they are forced to by PHP < 5.4 becoming unavailable.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: Completely stumped (still) [message #185066 is a reply to message #185062] |
Tue, 25 February 2014 19:06 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/25/2014 1:38 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Richard Yates wrote:
>>>> > On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
>>>> > <cmbecker69(at)arcor(dot)de> wrote:
>>>> >> Richard Yates wrote:
>>>> >>> I inserted var_dump successively at each stage in the script to see
>>>> >>> where it changes from the (correct) array to a (incorrect) string. I
>>>> >>> narrowed it down to ONE statement, but cannot see how that could
>>>> >>> possibly change the variable. Here's the section with var_dump, then
>>>> >>> the one statement, and then the var_dump repeated exactly.
>>>> >>>
>>>> >>> var_dump($_SESSION['to']);
>>>> >>> $to=$_SESSION['to'][$ct]['email'];
>>>> >>> var_dump($_SESSION['to']);
>>>> >>>
>>>> >>> The output of the two var_dumps is:
>>>> >>>
>>>> >>> The first:
>>>> >>> array(1) { [0]=> array(3)
>>>> >>> { ["fname"]=> string(4) "Dick"
>>>> >>> ["lname"]=> string(5) "Yates"
>>>> >>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> >>> }
>>>> >>>
>>>> >>> The second:
>>>> >>> string(23) "dyates(at)salemharvest(dot)org"
>>>> >>>
>>>> >>> If I comment out the second line (that sets $to), the second
>>>> >>> var_dump comes out correct. Am I losing my mind?
>>>> >>
>>>> >> $to being a reference to $_SESSION['to'] would explain the behavior.
>>>> >
>>>> > Thanks, Christropher. In desperation I changed all instances of $to
>>>> > in the script to $tomail and it fixed the problem!
>>>> >
>>>> > But I don't understand how setting the variable: $to can affect the
>>>> > array: $_SESSION['to']? They are completely different variables.
>>>> > And why would it all work fine on other servers?
>>>>
>>>> Frankly, I don't know. If I had to examine the issue, I'd probably
>>>> check the value of $to at the start of the script execution and directly
>>>> after the session start. If $to is set in either case, that would give
>>>> a hint. If $to is null at the start of the script execution, but is set
>>>> to the value of $_SESSION['to'] after starting the session, checking the
>>>> session handler would be appropriate. And if $to is already set at the
>>>> beginning of the script execution, checking the register_globals
>>>> setting[1] seems appropriate (even if that wouldn't explain the strange
>>>> behavior per se).
>>>
>>> session_register('to');
>>>
>>> <http://php.net/session_register> (deprecated since 5.3, removed in 5.4)
>>> would explain it even if
>>>
>>> $to =& $_SESSION['to'];
>>>
>>> was missing.
>>
>> If that were the case, it would fail on all his systems. Note he is
>> running the same code on 4 different systems, but it only fails on one.
>
> There are too many unknowns here to be certain. There could be
> conditionally executed statements. There could be auto_prepend_file. There
> could be extensions interfering. And so on.
>
No, there are no unknowns. He has a script which works one way on three
systems and another way on a fourth system. The script is not the problem.
> However, I am willing to concede to you that “register_globals = on”, which
> you suggested elsewhere, is the Occam’s-razor-explanation here.
>
It is pretty much the ONLY solution here. The solution is NOT a
differences in scripts.
> Never having relied on it, I was not aware that this directive would affect
> $_SESSION as well, and that session_register() does not work with
> “register_globals = off” (which explains why that function was removed as of
> PHP 5.4 as well, see bottom):
>
> ,--[ibid.]
> |
> | Caution
> | If you want your script to work regardless of register_globals, you need
> | to instead use the $_SESSION array as $_SESSION entries are automatically
> | registered. If your script uses session_register(), it will not work in
> | environments where the PHP directive register_globals is disabled.
>
> If “register_globals” is the culprit, it has to be "on" on this one system
> which must run PHP 5.3 or earlier; either it has to be "off" on the other
> three systems, or they must run PHP 5.4 or newer (where the directive is no
> longer supported), respectively.
>
That is exactly the case.
> The OP should call phpinfo() to check the used PHP version and the actual
> value of the setting; they should check the .htaccess, and .config files in
> that directory and up to the document root, the virtual host configuration
> (if any; unfortunately, the aforementioned files are not listed by
> phpinfo()), and the configuration files listed by phpinfo(), for the
> directive.
>
> And they should stop writing/using PHP programs that require the setting to
> be "on" now, before they are forced to by PHP < 5.4 becoming unavailable.
>
>
> PointedEars
>
That has been the case ever since PHP 4.2.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185068 is a reply to message #185042] |
Tue, 25 February 2014 19:27 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>
>> I inserted var_dump successively at each stage in the script to see
>> where it changes from the (correct) array to a (incorrect) string. I
>> narrowed it down to ONE statement, but cannot see how that could
>> possibly change the variable. Here's the section with var_dump, then
>> the one statement, and then the var_dump repeated exactly.
>>
>> var_dump($_SESSION['to']);
>> $to=$_SESSION['to'][$ct]['email'];
>> var_dump($_SESSION['to']);
>>
>> The output of the two var_dumps is:
>>
>> The first:
>> array(1) { [0]=> array(3)
>> { ["fname"]=> string(4) "Dick"
>> ["lname"]=> string(5) "Yates"
>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>> }
>>
>> The second:
>> string(23) "dyates(at)salemharvest(dot)org"
>>
>> If I comment out the second line (that sets $to), the second var_dump
>> comes out correct. Am I losing my mind?
>>
>>
>
> The failing server has register_globals enabled.
I'm still confused that it seems that register_globals makes the
respective global variables *references* to the session variables. If
that is so, register_globals is even far worse a feature than I thought.
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185069 is a reply to message #185066] |
Tue, 25 February 2014 19:28 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 2/25/2014 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>> > Richard Yates wrote:
>>>> >> But I don't understand how setting the variable: $to can affect the
>>>> >> array: $_SESSION['to']? They are completely different variables.
>>>> >> And why would it all work fine on other servers?
>>>> >
>>>> > Frankly, I don't know. If I had to examine the issue, I'd probably
>>>> > check the value of $to at the start of the script execution and
>>>> > directly after the session start. If $to is set in either case, that
>>>> > would give a hint. If $to is null at the start of the script
>>>> > execution, but is set to the value of $_SESSION['to'] after starting
>>>> > the session, checking the session handler would be appropriate. And
>>>> > if $to is already set at the beginning of the script execution,
>>>> > checking the register_globals setting[1] seems appropriate (even if
>>>> > that wouldn't explain the strange behavior per se).
>>>>
>>>> session_register('to');
>>>>
>>>> <http://php.net/session_register> (deprecated since 5.3, removed in
>>>> 5.4) would explain it even if
>>>>
>>>> $to =& $_SESSION['to'];
>>>>
>>>> was missing.
>>>
>>> If that were the case, it would fail on all his systems. Note he is
>>> running the same code on 4 different systems, but it only fails on one.
>>
>> There are too many unknowns here to be certain. There could be
>> conditionally executed statements. There could be auto_prepend_file.
>> There could be extensions interfering. And so on.
>
> No, there are no unknowns.
Yes, there are.
> He has a script which works one way on three systems and another way on a
> fourth system. The script is not the problem.
Please get informed about conditional statements, auto_prepend_file, and the
other possibilities I mentioned (and not mentioned).
>> However, I am willing to concede to you that “register_globals = on”,
>> which you suggested elsewhere, is the Occam’s-razor-explanation here.
>
> It is pretty much the ONLY solution here. The solution is NOT a
> differences in scripts.
You just couldn't leave it at that. You had to be "right" in the end.
>> Never having relied on it, I was not aware that this directive would
>> affect $_SESSION as well, and that session_register() does not work with
>> “register_globals = off” (which explains why that function was removed as
>> of PHP 5.4 as well, see bottom):
>>
>> ,--[ibid.]
>> |
>> | Caution
>> | If you want your script to work regardless of register_globals, you
>> | need to instead use the $_SESSION array as $_SESSION entries are
>> | automatically registered. If your script uses session_register(), it
>> | will not work in environments where the PHP directive register_globals
>> | is disabled.
>>
>> If “register_globals” is the culprit, it has to be "on" on this one
>> system which must run PHP 5.3 or earlier; either it has to be "off" on
>> the other three systems, or they must run PHP 5.4 or newer (where the
>> directive is no longer supported), respectively.
>
> That is exactly the case.
You do not know that for certain. Claiming that you do does not make it so.
>> The OP should call phpinfo() to check the used PHP version and the actual
>> value of the setting; they should check the .htaccess, and .config files
>> in that directory and up to the document root, the virtual host
>> configuration (if any; unfortunately, the aforementioned files are not
>> listed by phpinfo()), and the configuration files listed by phpinfo(),
>> for the directive.
>>
>> And they should stop writing/using PHP programs that require the setting
>> to be "on" now, before they are forced to by PHP < 5.4 becoming
>> unavailable.
>
> That has been the case ever since PHP 4.2.
(Your statement does not make sense.)
The *built-in* *default* for “register_globals” is "off" since PHP 4.2.
Many people have set it to "on" without knowing it. Some have it set to
"on" deliberately, many of them are unaware of the full consequences, few
accepted them willingly.
<http://php.net/manual/en/ini.core.php#ini.register-globals>
<http://php.net/manual/en/security.globals.php>
PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14
|
|
|
|
| Re: Completely stumped (still) [message #185070 is a reply to message #185068] |
Tue, 25 February 2014 19:34 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>> I inserted var_dump successively at each stage in the script to see
>>> where it changes from the (correct) array to a (incorrect) string. I
>>> narrowed it down to ONE statement, but cannot see how that could
>>> possibly change the variable. Here's the section with var_dump, then
>>> the one statement, and then the var_dump repeated exactly.
>>>
>>> var_dump($_SESSION['to']);
>>> $to=$_SESSION['to'][$ct]['email'];
>>> var_dump($_SESSION['to']);
>>>
>>> The output of the two var_dumps is:
>>>
>>> The first:
>>> array(1) { [0]=> array(3)
>>> { ["fname"]=> string(4) "Dick"
>>> ["lname"]=> string(5) "Yates"
>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>> }
>>>
>>> The second:
>>> string(23) "dyates(at)salemharvest(dot)org"
>>>
>>> If I comment out the second line (that sets $to), the second var_dump
>>> comes out correct. Am I losing my mind?
>>
>> The failing server has register_globals enabled.
>
> I'm still confused that it seems that register_globals makes the
> respective global variables *references* to the session variables.
Or both of them are references to the same array element. Whatever the
implementation, it is the case that they yield the same value then, and it
is – if I may say so – a *logical* consequence of how register_globals is
supposed to work. $*_VARS were first.
> If that is so, register_globals is even far worse a feature than I
> thought.
ACK.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: Completely stumped (still) [message #185073 is a reply to message #185068] |
Tue, 25 February 2014 20:39 |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Tue, 25 Feb 2014 20:27:59 +0100, Christoph Michael Becker
<cmbecker69(at)arcor(dot)de> wrote:
> Jerry Stuckle wrote:
>
>> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>
>>> I inserted var_dump successively at each stage in the script to see
>>> where it changes from the (correct) array to a (incorrect) string. I
>>> narrowed it down to ONE statement, but cannot see how that could
>>> possibly change the variable. Here's the section with var_dump, then
>>> the one statement, and then the var_dump repeated exactly.
>>>
>>> var_dump($_SESSION['to']);
>>> $to=$_SESSION['to'][$ct]['email'];
>>> var_dump($_SESSION['to']);
>>>
>>> The output of the two var_dumps is:
>>>
>>> The first:
>>> array(1) { [0]=> array(3)
>>> { ["fname"]=> string(4) "Dick"
>>> ["lname"]=> string(5) "Yates"
>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>> }
>>>
>>> The second:
>>> string(23) "dyates(at)salemharvest(dot)org"
>>>
>>> If I comment out the second line (that sets $to), the second var_dump
>>> comes out correct. Am I losing my mind?
>>>
>>>
>>
>> The failing server has register_globals enabled.
>
> I'm still confused that it seems that register_globals makes the
> respective global variables *references* to the session variables. If
> that is so, register_globals is even far worse a feature than I thought.
From what I have been able to glean from forums it can be a
nightmare. I found this bit on StackOverflow:
$_SESSION[x] = 123;
$x = 'asd';
echo $_SESSION[x];
The output will be asd if register_globals is on.
I was doing the equivalent of $x=$_SESSION['x'] for the second line
which made it a double whammy. It seemed reasonable, tidy and easy to
keep track of to use the same name for the regular variable as the
_SESSION variable. I do that with _GET and _POST sometimes, too. At
least it turned out to be easy to turn register_globals off once Jerry
had pointed me there.
|
|
|
|
| Re: Completely stumped (still) [message #185076 is a reply to message #185069] |
Tue, 25 February 2014 21:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/25/2014 2:28 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 2/25/2014 1:38 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 2/24/2014 9:37 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Christoph Michael Becker wrote:
>>>> >> Richard Yates wrote:
>>>> >>> But I don't understand how setting the variable: $to can affect the
>>>> >>> array: $_SESSION['to']? They are completely different variables.
>>>> >>> And why would it all work fine on other servers?
>>>> >>
>>>> >> Frankly, I don't know. If I had to examine the issue, I'd probably
>>>> >> check the value of $to at the start of the script execution and
>>>> >> directly after the session start. If $to is set in either case, that
>>>> >> would give a hint. If $to is null at the start of the script
>>>> >> execution, but is set to the value of $_SESSION['to'] after starting
>>>> >> the session, checking the session handler would be appropriate. And
>>>> >> if $to is already set at the beginning of the script execution,
>>>> >> checking the register_globals setting[1] seems appropriate (even if
>>>> >> that wouldn't explain the strange behavior per se).
>>>> >
>>>> > session_register('to');
>>>> >
>>>> > <http://php.net/session_register> (deprecated since 5.3, removed in
>>>> > 5.4) would explain it even if
>>>> >
>>>> > $to =& $_SESSION['to'];
>>>> >
>>>> > was missing.
>>>>
>>>> If that were the case, it would fail on all his systems. Note he is
>>>> running the same code on 4 different systems, but it only fails on one.
>>>
>>> There are too many unknowns here to be certain. There could be
>>> conditionally executed statements. There could be auto_prepend_file.
>>> There could be extensions interfering. And so on.
>>
>> No, there are no unknowns.
>
> Yes, there are.
>
Then why did he indicate my answer was correct?
>> He has a script which works one way on three systems and another way on a
>> fourth system. The script is not the problem.
>
> Please get informed about conditional statements, auto_prepend_file, and the
> other possibilities I mentioned (and not mentioned).
>
I am familiar with them. They are not pertinent to the problem at hand.
>>> However, I am willing to concede to you that “register_globals = on”,
>>> which you suggested elsewhere, is the Occam’s-razor-explanation here.
>>
>> It is pretty much the ONLY solution here. The solution is NOT a
>> differences in scripts.
>
> You just couldn't leave it at that. You had to be "right" in the end.
>
Nope, you're just pissed off because someone else knew the answer and
you didn't.
>>> Never having relied on it, I was not aware that this directive would
>>> affect $_SESSION as well, and that session_register() does not work with
>>> “register_globals = off” (which explains why that function was removed as
>>> of PHP 5.4 as well, see bottom):
>>>
>>> ,--[ibid.]
>>> |
>>> | Caution
>>> | If you want your script to work regardless of register_globals, you
>>> | need to instead use the $_SESSION array as $_SESSION entries are
>>> | automatically registered. If your script uses session_register(), it
>>> | will not work in environments where the PHP directive register_globals
>>> | is disabled.
>>>
>>> If “register_globals” is the culprit, it has to be "on" on this one
>>> system which must run PHP 5.3 or earlier; either it has to be "off" on
>>> the other three systems, or they must run PHP 5.4 or newer (where the
>>> directive is no longer supported), respectively.
>>
>> That is exactly the case.
>
> You do not know that for certain. Claiming that you do does not make it so.
>
Yes, I do. The OP acknowledged it.
>>> The OP should call phpinfo() to check the used PHP version and the actual
>>> value of the setting; they should check the .htaccess, and .config files
>>> in that directory and up to the document root, the virtual host
>>> configuration (if any; unfortunately, the aforementioned files are not
>>> listed by phpinfo()), and the configuration files listed by phpinfo(),
>>> for the directive.
>>>
>>> And they should stop writing/using PHP programs that require the setting
>>> to be "on" now, before they are forced to by PHP < 5.4 becoming
>>> unavailable.
>>
>> That has been the case ever since PHP 4.2.
>
> (Your statement does not make sense.)
>
> The *built-in* *default* for “register_globals” is "off" since PHP 4.2.
> Many people have set it to "on" without knowing it. Some have it set to
> "on" deliberately, many of them are unaware of the full consequences, few
> accepted them willingly.
>
> <http://php.net/manual/en/ini.core.php#ini.register-globals>
> <http://php.net/manual/en/security.globals.php>
>
>
> PointedEars
>
It makes perfect sense if you understand English.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185077 is a reply to message #185068] |
Tue, 25 February 2014 21:06 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/25/2014 2:27 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>
>>> I inserted var_dump successively at each stage in the script to see
>>> where it changes from the (correct) array to a (incorrect) string. I
>>> narrowed it down to ONE statement, but cannot see how that could
>>> possibly change the variable. Here's the section with var_dump, then
>>> the one statement, and then the var_dump repeated exactly.
>>>
>>> var_dump($_SESSION['to']);
>>> $to=$_SESSION['to'][$ct]['email'];
>>> var_dump($_SESSION['to']);
>>>
>>> The output of the two var_dumps is:
>>>
>>> The first:
>>> array(1) { [0]=> array(3)
>>> { ["fname"]=> string(4) "Dick"
>>> ["lname"]=> string(5) "Yates"
>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>> }
>>>
>>> The second:
>>> string(23) "dyates(at)salemharvest(dot)org"
>>>
>>> If I comment out the second line (that sets $to), the second var_dump
>>> comes out correct. Am I losing my mind?
>>>
>>>
>>
>> The failing server has register_globals enabled.
>
> I'm still confused that it seems that register_globals makes the
> respective global variables *references* to the session variables. If
> that is so, register_globals is even far worse a feature than I thought.
>
That is how it works. And while it seemed like a good idea in the
beginning, as of PHP 4.2 the recommendation was not to use it any more.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Completely stumped (still) [message #185083 is a reply to message #185070] |
Tue, 25 February 2014 21:46 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Jerry Stuckle wrote:
>>> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>> I inserted var_dump successively at each stage in the script to see
>>>> where it changes from the (correct) array to a (incorrect) string. I
>>>> narrowed it down to ONE statement, but cannot see how that could
>>>> possibly change the variable. Here's the section with var_dump, then
>>>> the one statement, and then the var_dump repeated exactly.
>>>>
>>>> var_dump($_SESSION['to']);
>>>> $to=$_SESSION['to'][$ct]['email'];
>>>> var_dump($_SESSION['to']);
>>>>
>>>> The output of the two var_dumps is:
>>>>
>>>> The first:
>>>> array(1) { [0]=> array(3)
>>>> { ["fname"]=> string(4) "Dick"
>>>> ["lname"]=> string(5) "Yates"
>>>> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> }
>>>>
>>>> The second:
>>>> string(23) "dyates(at)salemharvest(dot)org"
>>>>
>>>> If I comment out the second line (that sets $to), the second var_dump
>>>> comes out correct. Am I losing my mind?
>>>
>>> The failing server has register_globals enabled.
>>
>> I'm still confused that it seems that register_globals makes the
>> respective global variables *references* to the session variables.
>
> Or both of them are references to the same array element. Whatever the
> implementation, it is the case that they yield the same value then, and it
> is – if I may say so – a *logical* consequence of how register_globals is
> supposed to work.
However, GPC parameters are *copied* to the respective global variables.
Why is it logical to make global variables references to session
variables (resp. let both reference the same variable/element)?
> $*_VARS were first.
According to the manual $HTTP_SESSION_VARS and $_SESSION are different
variables, anyway.[1]
[1] <http://www.php.net/manual/en/reserved.variables.session.php>
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185086 is a reply to message #185083] |
Tue, 25 February 2014 22:30 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>> On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>> > I inserted var_dump successively at each stage in the script to see
>>>> > where it changes from the (correct) array to a (incorrect) string. I
>>>> > narrowed it down to ONE statement, but cannot see how that could
>>>> > possibly change the variable. Here's the section with var_dump, then
>>>> > the one statement, and then the var_dump repeated exactly.
>>>> >
>>>> > var_dump($_SESSION['to']);
>>>> > $to=$_SESSION['to'][$ct]['email'];
>>>> > var_dump($_SESSION['to']);
>>>> >
>>>> > The output of the two var_dumps is:
>>>> >
>>>> > The first:
>>>> > array(1) { [0]=> array(3)
>>>> > { ["fname"]=> string(4) "Dick"
>>>> > ["lname"]=> string(5) "Yates"
>>>> > ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> > }
>>>> >
>>>> > The second:
>>>> > string(23) "dyates(at)salemharvest(dot)org"
>>>> >
>>>> > If I comment out the second line (that sets $to), the second var_dump
>>>> > comes out correct. Am I losing my mind?
>>>>
>>>> The failing server has register_globals enabled.
>>>
>>> I'm still confused that it seems that register_globals makes the
>>> respective global variables *references* to the session variables.
>>
>> Or both of them are references to the same array element. Whatever the
>> implementation, it is the case that they yield the same value then, and
>> it is – if I may say so – a *logical* consequence of how register_globals
>> is supposed to work.
>
> However, GPC parameters are *copied* to the respective global variables.
How did you get that idea?
> Why is it logical to make global variables references to session
> variables (resp. let both reference the same variable/element)?
The (error-prone, unsafe) shortcut that register_globals allowed would have
been inconsistent otherwise.
>> $*_VARS were first.
>
> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
> variables, anyway.[1]
>
> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
$_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it needs to
be declared a global if it is to be accessed from local context). But I am
quite certain that when both were still supported, if you modified one, you
modified the other (I have only PHP 5.5.9 to test with, where there is no
$HTTP_SESSION_VARS anymore).
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: Completely stumped (still) [message #185088 is a reply to message #185086] |
Tue, 25 February 2014 23:03 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>> >> I inserted var_dump successively at each stage in the script to see
>>>> >> where it changes from the (correct) array to a (incorrect) string. I
>>>> >> narrowed it down to ONE statement, but cannot see how that could
>>>> >> possibly change the variable. Here's the section with var_dump, then
>>>> >> the one statement, and then the var_dump repeated exactly.
>>>> >>
>>>> >> var_dump($_SESSION['to']);
>>>> >> $to=$_SESSION['to'][$ct]['email'];
>>>> >> var_dump($_SESSION['to']);
>>>> >>
>>>> >> The output of the two var_dumps is:
>>>> >>
>>>> >> The first:
>>>> >> array(1) { [0]=> array(3)
>>>> >> { ["fname"]=> string(4) "Dick"
>>>> >> ["lname"]=> string(5) "Yates"
>>>> >> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> >> }
>>>> >>
>>>> >> The second:
>>>> >> string(23) "dyates(at)salemharvest(dot)org"
>>>> >>
>>>> >> If I comment out the second line (that sets $to), the second var_dump
>>>> >> comes out correct. Am I losing my mind?
>>>> >
>>>> > The failing server has register_globals enabled.
>>>>
>>>> I'm still confused that it seems that register_globals makes the
>>>> respective global variables *references* to the session variables.
>>>
>>> Or both of them are references to the same array element. Whatever the
>>> implementation, it is the case that they yield the same value then, and
>>> it is – if I may say so – a *logical* consequence of how register_globals
>>> is supposed to work.
>>
>> However, GPC parameters are *copied* to the respective global variables.
>
> How did you get that idea?
As it doesn't seems to be explicitely documented, and I wanted some
confirmation before posting, I had made a quick test with following script:
var_dump($_GET['x']);
var_dump($x);
$x = 'bar';
var_dump($x);
var_dump($_GET['x']);
I requested the script with a query string of "x=foo". The output:
string(3) "foo" string(3) "foo" string(3) "bar" string(3) "foo"
(tested with PHP 5.2.13, FCGI, register_globals=On)
With $HTTP_GET_VARS instead of $_GET I get the same results
(register_long_arrays=On), by the way.
>> Why is it logical to make global variables references to session
>> variables (resp. let both reference the same variable/element)?
>
> The (error-prone, unsafe) shortcut that register_globals allowed would have
> been inconsistent otherwise.
IMHO only if the other parameters were also referenced.
>>> $*_VARS were first.
>>
>> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>> variables, anyway.[1]
>>
>> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>
> $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it needs to
> be declared a global if it is to be accessed from local context). But I am
> quite certain that when both were still supported, if you modified one, you
> modified the other (I have only PHP 5.5.9 to test with, where there is no
> $HTTP_SESSION_VARS anymore).
The manual says:
| $HTTP_SESSION_VARS contains the same initial information, but is not
| a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
| different variables and that PHP handles them as such)
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185091 is a reply to message #185088] |
Tue, 25 February 2014 23:29 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>> > I'm still confused that it seems that register_globals makes the
>>>> > respective global variables *references* to the session variables.
>>>>
>>>> Or both of them are references to the same array element. Whatever the
>>>> implementation, it is the case that they yield the same value then, and
>>>> it is – if I may say so – a *logical* consequence of how
>>>> register_globals is supposed to work.
>>>
>>> However, GPC parameters are *copied* to the respective global variables.
>>
>> How did you get that idea?
>
> As it doesn't seems to be explicitely documented, and I wanted some
> confirmation before posting, I had made a quick test with following
> script:
>
> var_dump($_GET['x']);
> var_dump($x);
> $x = 'bar';
> var_dump($x);
> var_dump($_GET['x']);
>
> I requested the script with a query string of "x=foo". The output:
>
> string(3) "foo" string(3) "foo" string(3) "bar" string(3) "foo"
>
> (tested with PHP 5.2.13, FCGI, register_globals=On)
>
> With $HTTP_GET_VARS instead of $_GET I get the same results
> (register_long_arrays=On), by the way.
ACK. Session variables must be different, though.
>>> Why is it logical to make global variables references to session
>>> variables (resp. let both reference the same variable/element)?
>>
>> The (error-prone, unsafe) shortcut that register_globals allowed would
>> have been inconsistent otherwise.
>
> IMHO only if the other parameters were also referenced.
Do you think it is a consistent implementation if you can read a session
value using a global variable, but not modify it this way?
>>>> $*_VARS were first.
>>>
>>> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>>> variables, anyway.[1]
>>>
>>> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>>
>> $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it needs
>> to be declared a global if it is to be accessed from local context). But
>> I am quite certain that when both were still supported, if you modified
>> one, you modified the other (I have only PHP 5.5.9 to test with, where
>> there is no $HTTP_SESSION_VARS anymore).
>
> The manual says:
>
> | $HTTP_SESSION_VARS contains the same initial information, but is not
> | a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
> | different variables and that PHP handles them as such)
I *know* what the manual says. That does not prove anything.
(Puzzling, but probably not relevant because of the newer PHP version:
$ php -r 'session_start(); var_dump($HTTP_SESSION_VARS["foo"]);
$_SESSION["foo"] = "bar"; var_dump($HTTP_SESSION_VARS["foo"]);
var_dump($_SESSION);'PHP Notice: Undefined variable: HTTP_SESSION_VARS in
Command line code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
NULL
PHP Notice: Undefined variable: HTTP_SESSION_VARS in Command line code on
line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
NULL
array(1) {
'foo' =>
string(3) "bar"
}
$ php -r 'session_start(); global $HTTP_SESSION_VARS;
var_dump($HTTP_SESSION_VARS["foo"]); $_SESSION["foo"] = "bar";
var_dump($HTTP_SESSION_VARS["foo"]); var_dump($_SESSION);'
NULL
NULL
array(1) {
'foo' =>
string(3) "bar"
}
$ php -v
PHP 5.5.9-1 (cli) (built: Feb 8 2014 00:52:52)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with XCache v3.1.0, Copyright (c) 2005-2013, by mOo
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
with XCache Optimizer v3.1.0, Copyright (c) 2005-2013, by mOo
with XCache Cacher v3.1.0, Copyright (c) 2005-2013, by mOo
with XCache Coverager v3.1.0, Copyright (c) 2005-2013, by mOo
)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: Completely stumped (still) [message #185103 is a reply to message #185091] |
Wed, 26 February 2014 18:50 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>
>>>> Why is it logical to make global variables references to session
>>>> variables (resp. let both reference the same variable/element)?
>>>
>>> The (error-prone, unsafe) shortcut that register_globals allowed would
>>> have been inconsistent otherwise.
>>
>> IMHO only if the other parameters were also referenced.
>
> Do you think it is a consistent implementation if you can read a session
> value using a global variable, but not modify it this way?
Well, I see your point. While it usually makes no sense to modify
$_GET, $_POST or $_COOKIE, modifying $_SESSION does. However, this
difference (reference assignment vs. copying) is still somewhat
confusing, IMHO.
>>>> > $*_VARS were first.
>>>>
>>>> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>>>> variables, anyway.[1]
>>>>
>>>> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>>>
>>> $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it needs
>>> to be declared a global if it is to be accessed from local context). But
>>> I am quite certain that when both were still supported, if you modified
>>> one, you modified the other (I have only PHP 5.5.9 to test with, where
>>> there is no $HTTP_SESSION_VARS anymore).
>>
>> The manual says:
>>
>> | $HTTP_SESSION_VARS contains the same initial information, but is not
>> | a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
>> | different variables and that PHP handles them as such)
>
> I *know* what the manual says. That does not prove anything.
Testing on a single system might not prove much more, either. Anyway, I
tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
Off, register_long_arrays=On):
<?php
session_start();
var_dump($HTTP_SESSION_VARS["foo"]);
$_SESSION["foo"] = "bar";
var_dump($HTTP_SESSION_VARS["foo"]);
The result really surprised me:
string(3) "bar" string(3) "bar"
The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION. A
similar test regarding $_GET and $HTTP_GET_VARS showed the documented
behavior, by the way.
It seems that is a documentation bug. However, I suppose that's mostly
irrelevant now, because the bug tracker is concerned with PHP 5.4-5.6,
and says wrt. earlier versions: "upgrade first". But since PHP 5.4
register_long_arrays has been removed, so I conclude that the
$HTTP_*_VARS have been removed also, in which case their documentation
is even more in error, because it states they are deprecated, but
doesn't mention that they have been removed. Now I am completely stumped.
--
Christoph M. Becker
|
|
|
|
| Re: Completely stumped (still) [message #185107 is a reply to message #185103] |
Wed, 26 February 2014 21:20 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>> > Thomas 'PointedEars' Lahn wrote:
>>>> >> $*_VARS were first.
>>>> >
>>>> > According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>>>> > variables, anyway.[1]
>>>> >
>>>> > [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>>>>
>>>> $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it
>>>> needs to be declared a global if it is to be accessed from local
>>>> context). But I am quite certain that when both were still supported,
>>>> if you modified one, you modified the other (I have only PHP 5.5.9 to
>>>> test with, where there is no $HTTP_SESSION_VARS anymore).
>>>
>>> The manual says:
>>>
>>> | $HTTP_SESSION_VARS contains the same initial information, but is not
>>> | a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
>>> | different variables and that PHP handles them as such)
>>
>> I *know* what the manual says. That does not prove anything.
>
> Testing on a single system might not prove much more, either. Anyway, I
> tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
> Off, register_long_arrays=On):
>
> <?php
>
> session_start();
> var_dump($HTTP_SESSION_VARS["foo"]);
> $_SESSION["foo"] = "bar";
> var_dump($HTTP_SESSION_VARS["foo"]);
>
> The result really surprised me:
>
> string(3) "bar" string(3) "bar"
>
> The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION. A
> similar test regarding $_GET and $HTTP_GET_VARS showed the documented
> behavior, by the way.
>
> It seems that is a documentation bug.
ACK.
> However, I suppose that's mostly rrelevant now, because the bug tracker is
> concerned with PHP 5.4-5.6, and says wrt. earlier versions: "upgrade
> first". But since PHP 5.4 register_long_arrays has been removed, so I
> conclude that the $HTTP_*_VARS have been removed also,
They have been removed indeed, as you can see in my PHP 5.5 test results.
I found it curiouser, though, that you can use “global” outside a function.
And not only that (which makes some sense as the file can be included), but
that apparently you can actually *declare* a global variable in PHP this way
(in my case, the previously non-existing $HTTP_SESSION_VARS).
> in which case their documentation is even more in error, because it states
> they are deprecated, but doesn't mention that they have been removed.
> Now I am completely stumped.
ACK.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: Completely stumped (still) [message #185114 is a reply to message #185107] |
Wed, 26 February 2014 23:21 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>> > Christoph Michael Becker wrote:
>>>> >> Thomas 'PointedEars' Lahn wrote:
>>>> >>> $*_VARS were first.
>>>> >>
>>>> >> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>>>> >> variables, anyway.[1]
>>>> >>
>>>> >> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>>>> >
>>>> > $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it
>>>> > needs to be declared a global if it is to be accessed from local
>>>> > context). But I am quite certain that when both were still supported,
>>>> > if you modified one, you modified the other (I have only PHP 5.5.9 to
>>>> > test with, where there is no $HTTP_SESSION_VARS anymore).
>>>>
>>>> The manual says:
>>>>
>>>> | $HTTP_SESSION_VARS contains the same initial information, but is not
>>>> | a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
>>>> | different variables and that PHP handles them as such)
>>>
>>> I *know* what the manual says. That does not prove anything.
>>
>> Testing on a single system might not prove much more, either. Anyway, I
>> tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
>> Off, register_long_arrays=On):
>>
>> <?php
>>
>> session_start();
>> var_dump($HTTP_SESSION_VARS["foo"]);
>> $_SESSION["foo"] = "bar";
>> var_dump($HTTP_SESSION_VARS["foo"]);
>>
>> The result really surprised me:
>>
>> string(3) "bar" string(3) "bar"
>>
>> The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION. A
>> similar test regarding $_GET and $HTTP_GET_VARS showed the documented
>> behavior, by the way.
>>
>> It seems that is a documentation bug.
>
> ACK.
>
>> However, I suppose that's mostly rrelevant now, because the bug tracker is
>> concerned with PHP 5.4-5.6, and says wrt. earlier versions: "upgrade
>> first". But since PHP 5.4 register_long_arrays has been removed, so I
>> conclude that the $HTTP_*_VARS have been removed also,
>
> They have been removed indeed, as you can see in my PHP 5.5 test results.
>
> I found it curiouser, though, that you can use “global” outside a function.
> And not only that (which makes some sense as the file can be included), but
> that apparently you can actually *declare* a global variable in PHP this way
> (in my case, the previously non-existing $HTTP_SESSION_VARS).
Indeed, the behavior is somewhat strange. However, it becomes more
understandable, considering what global actually does: it creates a
local variable as a reference to the respective global variable. So the
following functions are equivalent (if I'm not mistaken):
function foo() {
global $a;
echo $a;
}
function bar() {
$a =& $GLOBALS['a'];
echo $a;
}
>> in which case their documentation is even more in error, because it states
>> they are deprecated, but doesn't mention that they have been removed.
>> Now I am completely stumped.
>
> ACK.
Thanks for the confirmation. I have filed a doc bug report now[1].
[1] <https://bugs.php.net/bug.php?id=66784>
--
Christoph M. Becker
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]