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

Groups > comp.lang.php > #12964

Re: Completely stumped (still)

Show all headers | View raw

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
==================

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