-
2005-06-08
morgan
preg_match() expects parameter 2 to be a string, array given in "inc/common.php" on line 675.
if(!preg_match("#google\\.#i",$url['host'])) return '';
$query = array();
parse_str($url['query'],$query);
-
2005-06-08
andi
What PHP version do you run? Can you add the following line before the snippet above:
dbg($url['host']);
and send me what it prints?
-
2005-06-08
morgan
Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.11 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
Warning: Cannot modify header information - headers already sent by (output started at /inc/common.php:439) in /inc/actions.php on line 71
-
2005-06-08
andi
hmm okay... could you please attach the whole generated output here? Just use "save as html" in your browser.
-
2005-06-08
morgan
-
2005-06-08
andi
Hmm... very strange the debug output doesn't look like an array at all. Are you running Zend Optimizer on this machine? I found some references which may point to a incompatibility there...
-
2005-06-08
morgan
Zend Engine v1.3.0
Zend Extension Manager v1.0.7
Zend Optimizer v2.5.10
-
2005-06-12
andi
Hmm your Zend Optimizer seems to be uptodate. Try adding this line after $url = parse_url($_SERVER['HTTP_REFERER']); :
if(!$url) return '';
-
2005-06-24
matt
I'm also having this problem suddenly on Wikipes.com, I haven't done anything, so I'm thinking either it's another security exploit, or my host has done something to make Dokuwiki do this suddenly.
You can see the output here:
http://wikipes.com/doku.php
I'm using the latest version. Using PHP version 4.3.10, you can get full info at
http://wikipes.com/phpinfo.php
-
2005-06-24
negatendo
I get this error and a few more "expected to be string, array given" here:
http://www.dogheadbone.com/clients/doku.php
Sometimes if I reload though they go away.
I think one thing to note is that I am running this wiki on Dreamhost,
http://www.dreamhost.com . I might be wrong, but I think Matt's site, wikipes, is also on Dreamhost.
-
2005-06-24
andi
I don't get it - all those "arrays" should be strings and they are for me. Could you ask your Hoster if they did change anything on their PHP config recently? I'm still thinking it's the Zend Optimizer...
-
2005-06-24
negatendo
Ok I've put in a request to Dreamhost and pointed them to this page. I'll post their reply here once I get it.
-
2005-06-24
matt
Correct, I am using Dreamhost too. Looks like it may very well be something with the host. I'm going to contact them too about it.
-
2005-06-25
matt
Finally got a response from Dreamhost, they've never been this slow to respond:
"I have emailed the admin team about this and asked them to look into it.
I'll update you when I hear back."
I'll keep you guys updated when I get another response.
-
2005-06-28
negatendo
Got this in my email today:
------
Hello,
Hey, so about the problems you've had with DocuWiki....it does seem like
the Optimizer is to blame.
I've un-installed it from your machine and emailed the DocuWiki
developer. We do need to have Optimizer installed on our machines as
there are people out there who buy and want to run "encoded" PHP apps.
In the meantime, let us know if you hear anything about DocuWiki! It
shouldn't be super tough to work around the bug you were seeing.
Thanks!
Nathaniel
-
2005-06-28
matt
Yep, I got that same email, the site now works. On one hand I like how Dreamhost like to stay ahead of the curve, but sometimes it has consequences. :|
-
2005-06-30
andi
Well I got a mail from nate, saying he can't find the bug and he will enable ZO again, so thats bad news for you :-/ However to make things somewhat stranger, I just installed ZO on my machine here and everything works just fine! The only difference in configuration I can see is my PHP running as Apache module while it's running as CGI on your hosters server.
-
2005-07-01
matt
When they do enable ZO again and break the site, I'll set it to not run PHP as CGI and see if that solves the problem. Otherwise, I'll have no other choice but to try and use a different wiki software, which will be a nightmare considering the amount of hours put into making Wikipes to suit the needs of recipe submission. I chose Dokuwiki because of it's ease of use, and it wasn't too confusing to style it the way I wanted it, not to mention being standards-compliant too. Switching to another wiki will be hard because the last time I checked when searching for wiki software, not many matched my criterias. :(
I can understand Dreamhost staying on top of things, and these kind of things happen, so I'm not blaming anyone. It's just frustrating, since I've never been in this situation before.
With that said, I do have to commend you for the work you've done on Dokuwiki, whether or not I switch to another wiki software, I'll always consider Dokuwiki superb.
-
2005-07-01
andi
Hmm my mistake. Now I get the error, too. But only once, after reloading the page it is gone. I have to close the browser to reproduce the error. Very strange, maybe it is connected to the session handling. Now that I can reproduce the behavior not all hope is lost ;-)
-
2005-07-01
andi
Okay I got it. It's the auth_logoff() function in inc/auth.php - there are some lines to remove authentication data from the session, looks like this destroys the $_REQUEST array if the specified keys don't exist in $_SESSION. Don't ask me why - this is some really weird bug in ZO I think. Here is how to fix it - just replace all the unset lines in the mentioned function by these ones:
if(isset($_SESSION[$conf['title']]['auth']['user']))
unset($_SESSION[$conf['title']]['auth']['user']);
if(isset($_SESSION[$conf['title']]['auth']['pass']))
unset($_SESSION[$conf['title']]['auth']['pass']);
if(isset($_SESSION[$conf['title']]['auth']['info']))
unset($_SESSION[$conf['title']]['auth']['info']);
if(isset($_SERVER['REMOTE_USER']))
unset($_SERVER['REMOTE_USER']);
Please report back if it works for you so I can close this bug.
-
2005-07-01
morgan
Andreas, when you close this bug, please release a new build. Thanks!
-
2005-07-01
matt
I put that update under the auth_logoff function, and so far I'm able to logout and login just fine, but Dreamhost hasn't enabled ZO yet, so I can't say for sure, but so far so good. Glad to see there's some light at the end of the tunnel. :D
-
Related tasks: