Wikimedia Bugzilla is closed!

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. ***