Last modified: 2010-05-15 15:33:51 UTC
Javascript errors are occurring in the auto-generated tooltips & access-keys javascript header in the monobook skin (though it may affect other skins too). The error is caused by unescaped quote marks appearing in quoted strings. Example: ta['pt-anonuserpage'] = new Array('.','The user page for the ip you're editing as'); (the ' in you're should be escaped). URL on my local wiki is /wiki/index.php?title=User:HappyDog/-&action=raw&gen=js&maxage=18000
These are not auto-generated, they come from the message 'monobook.js', editable via [[MediaWiki:Monobook.js]]. Perhaps you have edited this message and removed the escapes?
Hmmm... I looked for monobook.js, and couldn't find it, but then I realised it is a system message. The reason I thought it was auto-generated is that the downloaded file begins with the comment "generated javascript". I have never touched the system messages, so I assume an error in here must come from an earlier version. My upgrade path was 1.3.x -> 1.4.0 -> 1.4.1 -> 1.4.4. The 'default text' in Special:Allmessages is correct in 1.4.4, so it is no longer an active bug, but it is perhaps something that needs looking into with regards to the upgrade process (if that is where the problem lies). As a side note, I tried to fix the problem by deleting MediaWiki:Monobook.js, but even though the page is now gone the message list still shows the old value. I assume this is a problem with the cache not being rebuilt when a message is deleted. Is this something that should be reported as a bug?
What was your upgrade procedure? (wrt running updaters, etc.) When did the errors start? Are they recent or have they always been there? What's your PHP version? Have you ever had obscure and dangerous options such as magic_quotes_runtime on? Is it the message cache that might be stale, or your browser cache? Clear your browser cache and/or try a new browser to check the browser cache. *Always* clear the browser cache when checking things these; CSS and JS are aggressively cached. To check the message cache, try in eval.php: > return $messageMemc->get("$wgDBname:messages"); This will dump the message cache array to the terminal so you can inspect its contents.
PHP version is 4.1.2 and magic_quotes_* have never been enabled. I cleared browser cache, and also tried viewing the page in a different browser, neither of which helped. note: $wgCachePages is set to false (and I think it always has been). I only noticed the error when I first reported it here, but it may well have been present before this. Using eval.php as you described gives the messages without escaped quotes. My update procedure was initially non-standard, but I have since stripped back and run the updater as intended. This could have caused some problems. I also had to move the data between databases, ditto. Both of these MAY have been the reason for the initial error (and if no-one else reports a similar problem then that should perhaps be assumed), but it doesn't explain the current problem that the quotes are still unescaped after the MediaWiki: page has been deleted. I tried modifying one of the other system messages, and that change shows up on Special:Allmessages, but the javascript is still showing the old version (and marking the diff in pink), so it doesn't _appear_ to be a caching error.
Gonna go ahead and resolve this unless further info has come up.
I resolved the problem by copying the expected version of the content for this message into the wiki page, and as no-one else appears to have been having this problem, it was probably some idiosyncrasy in my setup. I am happy with WORKSFORME resolution. However I realised that one of the problems I observed above is still present: even when the page text is exactly the same as the expected text, it is highlighted on Special:Allmessages as being different. I tested this by checking my newly installed wiki, where no system messages have been changed at all. About 30 system messages are flagged in pink as being changed from the default, even though they appear to be identical in content and have definitely not been changed from the installation defaults. I have reported this as a separate bug (bug 4108).
