Last modified: 2011-04-14 15:10:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20274, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18274 - Parser Cache's {{SERVER}} becomes "localhost" with maintenance scripts
Parser Cache's {{SERVER}} becomes "localhost" with maintenance scripts
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
1.15.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 18362 (view as bug list)
Depends on: 61
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-31 07:58 UTC by Dan Jacobson
Modified: 2011-04-14 15:10 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-03-31 07:58:29 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
Comment 1 Dan Jacobson 2009-03-31 14:02:19 UTC
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"
}
Comment 2 Roan Kattouw 2009-03-31 15:01:13 UTC
Renders identically in both versions for me.
Comment 3 Roan Kattouw 2009-03-31 15:08:34 UTC
(In reply to comment #2)
> Renders identically in both versions for me.
> 

Oops, mid-air collision, totally missed comment #1.
Comment 4 Chad H. 2009-04-03 14:02:21 UTC
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.
Comment 5 Dan Jacobson 2009-04-07 02:43:51 UTC
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.
Comment 6 Niklas Laxström 2009-04-07 06:22:45 UTC
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';
}
Comment 7 Dan Jacobson 2009-04-10 21:01:52 UTC
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?
Comment 8 Dan Jacobson 2009-04-14 05:26:17 UTC
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.
Comment 9 Dan Jacobson 2009-05-04 04:14:10 UTC
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".
Comment 10 Dan Jacobson 2009-05-12 02:54:38 UTC
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.
Comment 11 Chad H. 2009-08-25 23:57:03 UTC
*** Bug 18362 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links