| 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:
|
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).
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]