Last modified: 2011-04-14 15:10:28 UTC
Holy moly, why does {{SERVER}}/ render as localhost on http://transgender-taiwan.org/index.php?title=%E8%81%AF%E7%B5%A1&oldid=103 but correctly on http://transgender-taiwan.org/index.php?title=聯絡&oldid=101 ? The diff shows the wikitext is the same http://transgender-taiwan.org/index.php?title=聯絡&diff=103&oldid=101 And if you edit it (don't save changes please), the / at the end seems to trigger the problem. Purging, rebuilding don't seem to help. I can't reproduce it on http://test.wikipedia.org
OK: I have found the problem: If one uses importDump.php or importTextFile.php, {{SERVER}} will be rendered as http://localhost/ until one does echo "TRUNCATE objectcache;"|mysql MyDatabase Special:Import and editing by hand are not affected. Proof: $ echo {{SERVER}} > TestOne; php importTextFile.php TestOne This will render as http://localhost/ Now visit title=TestTwo&action=edit, placing the words {{SERVER}} in it and hitting save. Notice how TestTwo renders fine. No spurious "localhost". Instead the true hostname. So how can we fix TestOne? $ echo "TRUNCATE objectcache;"|mysql MyDatabase OK, now our wiki is once more presentable to the public. (Which I have done, so run the test on your own wiki, as I have now fixed mine.) You might say "well, then just edit everything by hand". Try importing 15 pages by hand. Debugging the problem, we see the date <!-- Saved in parser cache with key transgender:pcache:idhash:12-0!1!0!!zh-tw!2 and timestamp 20090331072334 --> is the moment we imported the file. I put a debug statement here, which produced the following. --- includes/BagOStuff.php (revision 49060) +++ includes/BagOStuff.php (working copy) @@ -423,6 +423,7 @@ } } $ret = unserialize( $serial ); + echo '<pre>',var_dump($ret),'</pre>'; return $ret; } } which produced: ["mCacheTime"]=> string(14) "20090331072334" ["mVersion"]=> string(5) "1.6.4" ["mLinks"]=> array(2) { [0]=> array(1) { ["專線"]=> string(2) "20" } [2]=> array(1) { ["WikiSysop"]=> string(1) "7" } } ["mTemplates"]=> array(0) { } ["mTemplateIds"]=> array(0) { } ["mImages"]=> array(0) { } ["mExternalLinks"]=> array(4) { ["mailto:lioualan@gmail.com"]=> int(1) ["mailto:twtgbg@gmail.com"]=> int(1) ["http://zh.wikipedia.org/"]=> int(1) ["http://localhost/"]=> int(1) } ["mNewSection"]=> bool(false) ["mHideNewSection"]=> bool(false) ["mNoGallery"]=> bool(false) ["mHeadItems"]=> array(0) { } ["mOutputHooks"]=> array(0) { } ["mWarnings"]=> array(0) { } ["mSections"]=> array(0) { } ["mProperties"]=> array(0) { } ["mIndexPolicy:private"]=> string(0) "" ["displayTitle:private"]=> bool(false) ["mTimestamp"]=> string(14) "20090323222425" }
Renders identically in both versions for me.
(In reply to comment #2) > Renders identically in both versions for me. > Oops, mid-air collision, totally missed comment #1.
Anyone have an idea for a fix on this? Flushing the cache isn't the answer, it should've been rendered correctly before caching. Or, if it can't, it should've indicated that it was a non-cacheable parser output.
See also Bug 18362. I didn't test if it ruins all the {{fullurl}} too, but the embarrassment when "Hey everybody, bookmark my new site: {{SERVER}} !" becomes localhost behind one's back is more than enough.
We had the same problem at translatewiki.net in the mails which were containing localhost urls. We use this hack to work around it: if ( $wgServer === 'http://localhost' ) { $wgServer = $wgInternalServer = 'http://translatewiki.net'; }
In what file does one put this hack? How about not creating cache items until a page is requested, if then can't be properly dealt with upon such imports?
I see, you put it into LocalSettings.php. By the way, the only alternative to $ echo "TRUNCATE objectcache;"|mysql MyDatabase to fix the damage is running php update.php. There is no other maintenance script that will do the job.
It seems we really can't blame MediaWiki for not being able to figure out our site's URL when a maintenance script is being run. We must give it hints depending on our individual site, as I have done in http://www.mediawiki.org/wiki/Manual:Wiki_family#Ultimate_minimalist_solution However, a script should still bomb out with an error instead of guessing "localhost".
Note that following all the above steps, one's wiki will now work properly. However one must still at this point run php refreshLinks.php, otherwise SpecialLinkSearch.php and the API will still find the old localhost entries in the externallinks table.
*** Bug 18362 has been marked as a duplicate of this bug. ***