Quote:
What is happening is that when you select the messages to delete, XOOPS puts them into an array, which is then placed in $_POST. When XOOPS asks you to confirm to delete these messages, it encodes the array with JSON, and after you confirm the deletion, it should decode it again.
Unfortunately, somehow in this particular installation, it is being converted to a string, before XOOPS has a chance to decode it.
Good teamwork always leads to quicker results!
I was further investigating it and found out that the change was being done by the Protector in \xoops_lib\modules\protector\class\protector.php in line 636:
foreach ($_POST as $key => $val) {
if ( substr( $key , -2 ) == 'id' && ! is_array( $_POST[ $key] ) ) {
$newval = preg_replace( '/[^0-9a-zA-Z_-]/' , '' , $val ) ;
$_POST[ $key ] = $HTTP_POST_VARS[ $key ] = $newval ;
if ($_REQUEST[ $key ] == $_POST[ $key ]) {
$_REQUEST[ $key ] = $newval ;
}
}
}
So value that was stored in
$_POST['msg_id'] like this:
"[123,456]" would be converted to
"123456", and JSON could not decode it again into an array.
Once this value has been changed, then the $pm_handler on line 52 in /pm/viewpmsg.php could never find the message, so $pm is null, and creates a Fatal Error in line 53:
This was the file trace:
and by going back step by step, we could see that the change was triggered by this code on line 66 in /xoops_lib/modules/protector/include/precheck_functions.php
// force intval variables whose name is *id
if( ! empty( $conf['id_forceintval'] ) ) $protector->intval_allrequestsendid() ;
because in the "msg_id" we have the "id".
I had to leave to a meeting, but Richard was kind enough to take a look at this, and he found the issue:
Quote:
I am able to turn the problem on and off with a protector preference, Force intval. The default value for this option is off, but when on it looks for request field names ending with 'id' and force them to be integers. Since the pm code uses 'msg_id' for the list of messages to delete in the confirmation, protector manges the value.
I ran a test on a clean system. Created 3 pm's, turned on "Force intval to variables like id" in protector preferences. Attempting to delete the pm's generates error:
"Warning: array_map(): Argument #2 should be an array in file /modules/pm/viewpmsg.php line 47"
Turn off the same preference everything works again.
Since protector is looking for fields ending with 'id', the solution is to end the problem name with something else. This problem effects both the pm module, and the simpler core pm functionality.
I've got patches for both ready to check in that solve this problem.
If anyone can find an additional circumstance that triggers this error, please let us know.
Thanks to Richard, another mystery has been solved, and we'll have a fix for it going forward.
Thanks to Roby73 for reporting the issues, and to Richard for fixing it.
And thanks to
PhpStorm for being such a good tool that helped to debug the code here.
