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