Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12929 > unrolled thread

Completely stumped

Back to article view | Back to comp.lang.php

Contents

  Completely stumped Richard Yates <richard@yatesguitar.com> - 2014-02-24 14:51 -0800
    Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 15:53 -0800
      Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:11 +0100
        Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 16:24 -0800
          Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:49 +0100
            Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 03:37 +0100
              Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 22:01 -0500
                Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 19:38 +0100
                  Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 14:06 -0500
                    Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:28 +0100
                      Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:04 -0500
      Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 20:59 -0500
        Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 19:00 -0800
          Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 22:04 -0500
            Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 21:09 -0800
              Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 21:30 -0800
        Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 20:27 +0100
          Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:34 +0100
            Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:46 +0100
              Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 23:30 +0100
                Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 00:03 +0100
                  Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-26 00:29 +0100
                    Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 19:50 +0100
                      Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-26 22:20 +0100
                        Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-27 00:21 +0100
          Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-25 12:39 -0800
          Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:06 -0500

Page 1 of 2  [1] 2  Next page →

#12929 — Completely stumped

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@salemharvest.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@salemharvest.org' (length=23)
  1 => 
    array (size=3)
      'fname' => string 'Benjamin' (length=8)
      'lname' => string 'Rasmus' (length=6)
      'email' => string 'benjamin@harvest.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

[toc] | [next] | [standalone]

#12931 — Re: Completely stumped (still)

On Mon, 24 Feb 2014 14:51:23 -0800, Richard Yates
<richard@yatesguitar.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@salemharvest.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@salemharvest.org' (length=23)
>  1 => 
>    array (size=3)
>      'fname' => string 'Benjamin' (length=8)
>      'lname' => string 'Rasmus' (length=6)
>      'email' => string 'benjamin@harvest.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@salemharvest.org" } 
	         } 

The second:
	string(23) "dyates@salemharvest.org" 

If I comment out the second line  (that sets $to), the second var_dump
comes out correct. Am I losing my mind?

 

[toc] | [prev] | [next] | [standalone]

#12933 — Re: Completely stumped (still)

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@salemharvest.org" } 
> 	         } 
> 
> The second:
> 	string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12934 — Re: Completely stumped (still)

On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
<cmbecker69@arcor.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@salemharvest.org" } 
>> 	         } 
>> 
>> The second:
>> 	string(23) "dyates@salemharvest.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?

[toc] | [prev] | [next] | [standalone]

#12937 — Re: Completely stumped (still)

Richard Yates wrote:

> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
> <cmbecker69@arcor.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@salemharvest.org" } 
>>> 	         } 
>>>
>>> The second:
>>> 	string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12942 — Re: Completely stumped (still)

Christoph Michael Becker wrote:

> Richard Yates wrote:
>> On Tue, 25 Feb 2014 01:11:40 +0100, Christoph Michael Becker
>> <cmbecker69@arcor.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@salemharvest.org" }
>>>> }
>>>>
>>>> The second:
>>>> string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12945 — Re: Completely stumped (still)

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@arcor.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@salemharvest.org" }
>>>>> }
>>>>>
>>>>> The second:
>>>>> string(23) "dyates@salemharvest.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12960 — Re: Completely stumped (still)

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@arcor.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@salemharvest.org" }
>>>>>> }
>>>>>>
>>>>>> The second:
>>>>>> string(23) "dyates@salemharvest.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).

[toc] | [prev] | [next] | [standalone]

#12964 — Re: Completely stumped (still)

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@arcor.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@salemharvest.org" }
>>>>>>> }
>>>>>>>
>>>>>>> The second:
>>>>>>> string(23) "dyates@salemharvest.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12967 — Re: Completely stumped (still)

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

[toc] | [prev] | [next] | [standalone]

#12974 — Re: Completely stumped (still)

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12940 — Re: Completely stumped (still)

On 2/24/2014 6:53 PM, Richard Yates wrote:
> On Mon, 24 Feb 2014 14:51:23 -0800, Richard Yates
> <richard@yatesguitar.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@salemharvest.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@salemharvest.org' (length=23)
>>   1 =>
>>     array (size=3)
>>       'fname' => string 'Benjamin' (length=8)
>>       'lname' => string 'Rasmus' (length=6)
>>       'email' => string 'benjamin@harvest.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@salemharvest.org" }
> 	         }
>
> The second:
> 	string(23) "dyates@salemharvest.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12944 — Re: Completely stumped (still)

On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
<jstucklex@attglobal.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@salemharvest.org" }
>> 	         }
>>
>> The second:
>> 	string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12946 — Re: Completely stumped (still)

On 2/24/2014 10:00 PM, Richard Yates wrote:
> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
> <jstucklex@attglobal.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@salemharvest.org" }
>>> 	         }
>>>
>>> The second:
>>> 	string(23) "dyates@salemharvest.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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#12956 — Re: Completely stumped (still)

On Mon, 24 Feb 2014 22:04:47 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/24/2014 10:00 PM, Richard Yates wrote:
>> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
>> <jstucklex@attglobal.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@salemharvest.org" }
>>>> 	         }
>>>>
>>>> The second:
>>>> 	string(23) "dyates@salemharvest.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. 

[toc] | [prev] | [next] | [standalone]

#12957 — Re: Completely stumped (still)

On Mon, 24 Feb 2014 21:09:40 -0800, Richard Yates
<richard@yatesguitar.com> wrote:

>On Mon, 24 Feb 2014 22:04:47 -0500, Jerry Stuckle
><jstucklex@attglobal.net> wrote:
>
>>On 2/24/2014 10:00 PM, Richard Yates wrote:
>>> On Mon, 24 Feb 2014 20:59:47 -0500, Jerry Stuckle
>>> <jstucklex@attglobal.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@salemharvest.org" }
>>>>> 	         }
>>>>>
>>>>> The second:
>>>>> 	string(23) "dyates@salemharvest.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. 

[toc] | [prev] | [next] | [standalone]

#12966 — Re: Completely stumped (still)

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@salemharvest.org" }
>>              }
>>
>> The second:
>>     string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12968 — Re: Completely stumped (still)

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@salemharvest.org" }
>>>              }
>>>
>>> The second:
>>>     string(23) "dyates@salemharvest.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).

[toc] | [prev] | [next] | [standalone]

#12981 — Re: Completely stumped (still)

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@salemharvest.org" }
>>>>              }
>>>>
>>>> The second:
>>>>     string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12984 — Re: Completely stumped (still)

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@salemharvest.org" }
>>>>>              }
>>>>>
>>>>> The second:
>>>>>     string(23) "dyates@salemharvest.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@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web