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


Groups > comp.lang.php > #12960

Re: Completely stumped (still)

Message-ID <2897301.1vdB3TozUe@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2014-02-25 19:38 +0100
Subject Re: Completely stumped (still)
Newsgroups comp.lang.php
References (2 earlier) <530bdfbb$0$9512$9b4e6d93@newsspool1.arcor-online.net> <2cong990p92ikr3uconpk9jpofp1s4g18r@4ax.com> <530be89b$0$9505$9b4e6d93@newsspool1.arcor-online.net> <5344407.41oGB2pKJ7@PointedEars.de> <leh11q$2a8$1@dont-email.me>

Show all headers | View raw


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).

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web