Hi,
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc & list,
Marc Delisle wrote:
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Strange... as long as the search page does rely on GET / POST parameters that are named 'cfg', 'GLOBALS', '_something' or 'strSomething', this should not happen.
Regards,
AMT
Alexander M. Turek a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc & list,
Marc Delisle wrote:
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Strange... as long as the search page does rely on GET / POST parameters that are named 'cfg', 'GLOBALS', '_something' or 'strSomething', this should not happen.
The bug does not happen with this code:
if ( //$key == 'cfg' //$key == 'GLOBALS' substr($key, 0, 3) == 'str' || $key{0} == '_') { continue; }
but happens if I activate the first or the second comparison!
Marc (scratching his head)
Marc Delisle a écrit :
Alexander M. Turek a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc & list,
Marc Delisle wrote:
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Strange... as long as the search page does rely on GET / POST parameters that are named 'cfg', 'GLOBALS', '_something' or 'strSomething', this should not happen.
The bug does not happen with this code:
if ( //$key == 'cfg' //$key == 'GLOBALS' substr($key, 0, 3) == 'str' || $key{0} == '_') { continue; }
but happens if I activate the first or the second comparison!
Marc (scratching his head)
Confirmed other problem with same cause: can no longer edit a row!
Let's work quickly on this one. I am considering deactivating 2.6.1-pl1 unless we can come up with a -pl2 today.
Marc
Marc Delisle a écrit :
Alexander M. Turek a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc & list,
Marc Delisle wrote:
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Strange... as long as the search page does rely on GET / POST parameters that are named 'cfg', 'GLOBALS', '_something' or 'strSomething', this should not happen.
The bug does not happen with this code:
if ( //$key == 'cfg' //$key == 'GLOBALS' substr($key, 0, 3) == 'str' || $key{0} == '_') { continue; }
but happens if I activate the first or the second comparison!
Marc (scratching his head)
This solves the bug for me, please comment:
if ( is_string($key) && ($key == 'cfg' || $key == 'GLOBALS' || substr($key, 0, 3) == 'str' || $key{0} == '_')) { continue; }
Without the first test, each [0] is lost.
Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc,
Marc Delisle wrote:
This solves the bug for me, please comment:
if ( is_string($key) && ($key == 'cfg' || $key == 'GLOBALS' || substr($key, 0, 3) == 'str' || $key{0} == '_')) { continue; }
Without the first test, each [0] is lost.
I am as confused as you are, but I can confirm that the code fixes the newly introduced bug.
Regards,
AMT
Alexander M. Turek a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Marc & list,
Marc Delisle wrote:
there is a problem with the new grab_globals.lib.php as released in 2.6.1-pl1. For example, the Search page no longer works.
I'm looking at this right now.
Strange... as long as the search page does rely on GET / POST parameters that are named 'cfg', 'GLOBALS', '_something' or 'strSomething', this should not happen.
Regards,
Can you reproduce the problem?
In my test, tbl_select.php loses $param[0] after grab_globals. $param[1] stays set.
I think that bugs 1150996 and 1150902 have the same cause, but I haven't tested it yet.
Marc