boogdesign posts

Longer posts on standards based web design, portable web development and Linux, intermingled with some stuff on my other nerd interests.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now
« London Geek Nights: Ajax :: Amarok Issues with Ogg on Kubuntu »

Fixing WackoWiki for PHP 5


07:41:02 pm Permalink Fixing WackoWiki for PHP 5

Categories: Web Develop, Server Side Web Development

For a long time now, I've had a WackoWiki implementation on my (not so technical) personal site. It was upgraded from a WikkaWiki which was installed back in March 2003, which makes it about four months older than this blog :)

Anyway, the point is it's a legacy app, which has never been a problem for a little used website until I discovered (last night) that the hosting company was doing an upgrade on all the servers which would remove PHP 4 to leave only PHP 5. A quick check indicated Wacko R4.2 was supposed to be PHP 5 compatible, so I didn't worry too much about it and went to bed. Of course, when I checked this morning, it was broken, just a blank page...

I downloaded the error log and found a few entries like this:

[error] [client] PHP Catchable fatal error: Object of class Wacko could not be converted to string in wakka/wakka.php on line 254

A quick Google revealed a number of other WackoWiki installs with a similar problem, but also this more useful result which explained the change in PHP 5.2 which was causing the problem:

Changed __toString() to be called wherever applicable. The magic method __toString() will now be called in a string context, that is, anywhere an object is used as a string. The fallback of returning a string that contains the object identifier was dropped in PHP 5.2.0. It became problematic because an object identifier cannot be considered unique. This change will mean that your application is flawed if you have relied on the object identifier as a return value. An attempt to use that value as a string will now result in a catchable fatal error.

Line 254 of wakka.php is:

$cache->Log("Before Run wacko=".$wacko);

I'm not sure what it's supposed to be doing, but it didn't seem too critical, so I just removed the object reference:

$cache->Log("Before Run wacko=");

Seems to work for me!

Tweet this!


Comment from: Devon Young [Visitor] ·
11/06/08 @ 03:24
Nice little hack there. Makes me wonder what that line does in the whole scheme of the app, if it can be removed without any apparent consequence.
Comment from: robertc [Member] ·
11/06/08 @ 07:33
I'm assuming it's some sort of debugging/logging thing and therefore not at all crucial - just logs the fact that the base object got created correctly.

Comment from: kubi [Visitor] ·
31/07/08 @ 12:03
I had the same problem and adjusted the code. But the Wiki still displays a blank page. Any suggestions?
Comment from: robertc [Member] ·
03/08/08 @ 12:35
I'm not sure, there might be a caching issue of some kind? Are you able to get access to your error log? Depending on your particular configuration, this will either be through your CPanel (or similar) interface, or PHP will create it's own error log in your web root.

These days most PHP installations are configured not to show error messages by default but to log them instead, if you can find the error message then the problem should be easy enough to track down.

Comment from: Roemer2201 [Visitor]
24/05/10 @ 09:42
Solved the Problem for me. Thx
Comment from: AbdulHakim Maina [Visitor] ·
07/08/10 @ 22:35
Thanks for the hack, Rob.

I agree that it has to do with logging for debugging purposes. The contents of the variable $wacko aren't text though and can't be converted to text either.

I commented off the whole line: $cache->Log("Before Run wacko=".$wacko);

Works great!