Last modified: 2010-05-15 15:48:16 UTC
When looking at any page on the wiki, I got the following error: Fatal error: Failed to load cached file (/path/to/my/wiki/includes/normal/UtfNormal.php) class utfnormal is already declared in /path/to/my/wiki/includes/Title.php on line 9 I don't know why this happens. I am running PHP 5.2.1, Apache 1.3, MySQL 5 on Linux. I transferred this wiki from a previous server running under Gentoo, PHP 5.1.6 and Apache 2, I did not have this problem. So maybe this is PHP 5.2.1 related. There is a simple work around, for now: if I comment in Title.php the line at the beginning: require_once( 'normal/UtfNormal.php' ); everything seems to work ok. I don't know what is wrong on my configuration, or why this happens, any help is appreciated. Googling and asking on the IRC channel did not help for now, so I am turning to developers.
Was this upgraded from a previous version of the software, and if so, were old files left alone? I suspect that UtfNormal.php moved at some point, or that there's two files with the same class definition, which for some odd reason, is causing the error.
No, the software version was not moved. I installed 1.9.0 on a server. Then it was decided to move the wiki to another server. I copied the files on the first wiki to the other server, and that's all. Neither on the first nor second server was anything else than 1.9.0 installed.
Probably some sort of path inconsistency confusing require_once, and/or duplicated files of some sort. Relative include paths sometimes get... interesting with PHP. :P Can you test if replacing the line with this works: require_once( dirname(__FILE__) . '/normal/UtfNormal.php' ); That's the version that appears in the current development code, using the full explicit path for consistency. If that works, then we'll go ahead and resolve this as FIXED in the mainline code.
No sorry, this did not fix it: same error message appears...
Please check for a broken or outdated version of eAccelerator or similar, such as Zend Optimiser, which can cause bizarre problems under otherwise normal circumstances. If not, it would be helpful to know if the problem persists in 1.10.0.