[BUG] Blank white page with PHP Warning
 

All I get after updating from 2.7.1 to 2.7.2+ is a blank white page with a PHP Warning (not Fatal Error) on it:

Warning: stristr() [function.stristr]: needle is not a string or an integer in /path/to/forums/arcade.php on line 5550


This warning does not cease execution, but I guess since it's part of the SQL stuff it's needed before the page can get any kind of output.



To update our Arcade, I uploaded (and over-wrote) all files from the upload folder to my forum root directory, then imported the XML (allowing Overwrite). The steps for template changes were not needed, as they were already done for 2.7.1 the same way. (Well, and because I've already customized my postbit.)

The Arcade was working previously (2.7.1+), but there was a [unconfirmed] report from one of our members that scores from one game could be applied to another. Thinking that perhaps that bug is one that might have been fixed, I decided to update. XD





As this does not seem to be any kind of common error, I'm not really sure what went wrong. I have tried re-uploading the files and re-importing the XML, both without success. I've also tried setting error_reporting(0); just to see if getting rid of the error would be fine, but oddly enough, the warning still stays on the page. O_O Not quite sure what THAT is all about...





Edit: P.S., vB is 4.1.10

--------------- Added [DATE]1330423099[/DATE] at [TIME]1330423099[/TIME] ---------------

Another bit of weirdness to add onto this error...

When on my home computer, I generally see the forums in Debug Mode. I decided to turn that off just in case it was screwing with the Arcade, and I still get the same error, but with one small difference:

/path/to/forums/arcade.php is changed to [path]/arcade.php

Not sure if that matters much in actually finding out what's wrong. Perhaps it's something in my config.php?







Also, that stuff I said about setting error_reporting(0), I tried setting that in my config.php, and no errors were reported (weird, because I set error_reporting(0) right after the include of global.php), but still got a blank white screen.

Hi there,

VERY SORRY - PLEASE IGNORE THIS POST - ALTHOUGH IT CLEARED THE ERROR WHEN JUST VIEWING = I GOT THE SAME ERROR MESSAGE AGAIN AFTER WHEN SUBMITTING A SCORE ... I WILL TEST MORE BEFORE I SUBMIT A SUPPOSED SOLUTION ...

I have left my comments below just in case ... but please note THIS IS NOT THE SOLUTION!! :(

I'm not a PHP expert, but I think the reason it gives that message is because at some point the needle $inthis is (nothing) or "". so when it runs it doesn't know the data type.

What I have done is added the following few lines of code in front:-

if ($inthis === "") {
RETURN $inthis;
}

just before the line 5550 in arcade.php and this removes the error

I'm not sure if it should be === or == (as my PHP knowledge is limited) but from what I can see the code doing - it's the only thing I can come up with.

So, the full "recursive_str_ireplace" function now shows in my arcade.php as :

function recursive_str_ireplace($replacethis,$withthis,$int his)
{
while (1==1)
{
$inthis = str_ireplace($replacethis,$withthis,$inthis);
if ($inthis === "") {
RETURN $inthis;
}
if(stristr($inthis, $replacethis) === FALSE)
{
RETURN $inthis;
}
}
RETURN $inthis;
}

Hope this helps or I'm sure someone will point out if I've made a boo-boo.

Cheers,
G

Thanks for the attempt, but I'm afraid simply getting rid of the error doesn't seem to rectify the problem. I still get a blank white page.

From what I can tell, that function is only used in one area, in the ibp_cleansql() function. Which means whyever it's failing, even if I bypass the error, it still won't be able to get the data from MySQL.... or at least I guess? (I'm rather clueless.)




And it doesn't help matters much when I'm trying to figure out wtf is going on and I find out that stristr() is one of the rare PHP functions that has the needle after the haystack.... >_< I don't get why they did that, honestly. (Obviously not something the developer of this Mod can do anything about, though, heh.)

You have a pm Sarteck...Hope that helps..

OK .. I have replaced the recursive function with the following and this does exactly the same as the original one but just uses a different way of checking if it needs to repeat.

function recursive_str_ireplace($replacethis,$withthis,$int his)
{
$old_inthis = "";
while ($old_inthis != $inthis)
{
$old_inthis = $inthis;
$inthis = str_ireplace($replacethis,$withthis,$inthis);
}
return $inthis;
}

I have to say though, I can see a lot of problems with this "solution" of just stripping out mysql commands ... for example if any (legitimate) words/variables within the mysql contain the letters "or" or "and" - then the "or" and "and" bits (and anything else that it filters out) ..

So for example, when I had finished playing a game, if I enter a comment next to my high scores.. this is what I get..

I type "Finally I get a good score!" ... it will show "Finally I get a good sce!" (the "or" removed)
If i typed something like "I think I upset the dealer in this game" then "upset" would be just "up" so whilst it more than likely removes the chance of some dodgy mysql going in - it is not quite the best. I'm not sure if it would be enough to just put a space after each of the words in the ibp_cleansql as probably other characters can be used..

I'm not sure why you are getting a white screen (or if you got any further) but at least this fuction below gets around using that stristr function ... but I think it would be best if a slightly improved solution is made really because otherwise potentially other legitimate mysql statements might get messed up by using this most recent correction..

stangger5, gmhastings, providing "fixes" to that recursive_str_ireplace() function only gets rid of the warning message--I still have the blank white page problem. I think it's not that function, but some kind of error in what gets fed to that function.

See, it seems all that function is supposed to is to help ibp_cleansql() clean a value for MySQL statements. ibp_cleansql() is used in several places, itself, and I think that whatever value the script is choking on is coming from that function being used.

(This is all guesswork mind you--I have a hard time making heads or tales of what's going on in the script. Heh.)

I am not an expert, but yes this solution does seem kind of rushed and not the best option. I'd rather disable comments entirely then have random bits disappear and cause confusion. I am not a PHP expert, but there are plenty of commands to strip bad code out of user input.. can these commands not be applied to comments properly so they are only displayed and not executed? Why is the comment field vulnerable when other data input is not? I think something needs to change...

Still only have that blank white page and the error. Anyone got any advice?

I always start by looking at the server error logs - if you are getting a completely blank page then it must be some error and the logs would be my first place to check. Sorry it's a bit tricky otherwise to guess.

I can help / look at it .. send me details
use my email in my profile..

if you want..

Hippy