This Might Be A Wiki:MediaWiki 1.14 Migration Issue Tracker Page

From This Might Be A Wiki

Use this page to discuss issues related to our 4/2/2009 upgrade to MediaWiki 1.14. Here are the release notes: 1.13 / 1.14

What Has Changed[edit]

Date: 4/2/2009
Prior Upgrade: New Server (3-20-2009) Migration Issue Tracker Page
Next Upgrade: MediaWiki 1.15.1 Migration Issue Tracker Page
Summary of Changes:

Item Old Version New Version Notes
MediaWiki 1.12.0 1.14
ParserFunctions Unknown 1.1.1
Variables Unknown 1.2

Misc To-Do Items[edit]

Misc Notes[edit]

  • Signatures that use templates are now automatically substituted. (i.e. if your signature is at {{User:TMBGFan/Sig}}, the code of the signature will be dumped onto each page rather than its title). There is a workaround; create a second subpage containing the first signature's page transcluded (but not substituted), and use this second subpage on your Preferences screen. -CapitalQtalk ♪ 06:15, 3 April 2009 (UTC)

Open Issues[edit]

Filelinks[edit]

  • Many images are showing extremely inflated values for the number of pages that link to them. (For example, on most linked files page, images that are found only on the Lincoln page are shown as having 50 links. If this is ghostlinking, it is definitely not your normal garden-variety ghostlinking; not only do the images show up on the special page, but similar images seem to have the same number, and unlike normal ghostlinking, the pages list of pages that "link" to it doesn't change when you reload. Bizarre. --ant 15:41, 3 April 2009 (UTC)
  • BW - The issue appears to be that files are getting marked as included, even if they are part of an "#if" statement. I'm not sure if it's something that can be fixed by running rebuildall.php, or if it's something in the parserfunctions code. Will keep investigating.
  • BW - I've done a couple things, including upgrading the parserfunctions extension and the variables extension. I then went through and ran refreshLinks.php. It seems to have taken care of most of the files, although there are some like File:95jhshoot.jpg, whose numbers are still high.
  • BW - Ok, this is interesting. The ones with the high numbers appear to be part of galleries. Not sure why that would be.
  • It seems to me that all the userpages that "link" to an image actually just link to a page that the image is on... For instance... all of the userpages that supposedly link to the John Henry shoot picture do in fact link to John Henry... I highly doubt this is a coincidence. --ant 17:53, 4 April 2009 (UTC)

Fixed Issues[edit]

Filepath[edit]

  • From the MediaWiki 1.14 release notes: "(bug 13835) Fix rendering of {{filepath:Wiki.png|nowiki}}"
  • BW - Ok, this is fixed. I also fixed it on the amazon download template. If anyone sees it, all you need to do is wrap the {{filepath}} in an "img" tag. That worked on those two pages. Weird that this was apparently a "fix".

Special Pages Tab[edit]

  • Tab on Special pages now says "Special page" instead of "Special," causing overflow (this can probably be fixed in a MW:Special page or something like that).

Category Images[edit]

  • Pages with categories on the bottom have two category "box" images.
  • BW - Edited all the custom skins. Removed id="catlinks" from the div. There was a class="catlinks", and an id="catlinks" that was causing it to show up twice.
  • CapitalQ also reported to me that there were two boxes around the category on the monobook skin, but only in IE7. I've fixed that by editing the monobook skin in the same manner. --Duke33 00:03, 7 April 2009 (UTC)

Skin Font[edit]

  • More a personal preference than a full-blown "issue," but in Monobook the default font has changed, and in my opinion this new default is worse.
  • BW - Well, this is just downright weird. The problem is that common.css and monobook.css were not getting imported. Here was the old code that worked just fine on 1.12:
<?php	if($this->data['pagecss'   ]) { ?>
		<style type="text/css"><?php $this->html('pagecss'   ) ?></style>
<?php	}
		if($this->data['usercss'   ]) { ?>
		<style type="text/css"><?php $this->html('usercss'   ) ?></style>

I replaced it with a hardcoded (non-dynamic) import, so it is like this:

<style type="text/css">/*<![CDATA[*/
@import "/testwiki/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000";
@import "/testwiki/index.php?title=MediaWiki:Monobook.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000";
@import "/testwiki/index.php?title=-&action=raw&gen=css&maxage=18000&smaxage=0";
/*]]>*/</style>

It works for now. I just hope we don't run into this again in the future. I have no idea why the old code doesn't work in 1.14

Statistics Page[edit]

  • Special:Statistics is a big ugly table now. I think we just need to add CSS for "mw-statistics-table"

Moving Images[edit]

  • On the "Move succeeded" page, I see this error up at the top of the page:
Warning:  chmod() [function.chmod]: Operation not permitted in
/home/tmbwnet/public_html/wiki/includes/filerepo/FSRepo.php on line 20
I opened bug #18326 on bugzilla to track this.
BW - I did a "chmod 777 images -R" in the /wiki directory, and that seemed to clear these problems up. Not sure why that was still occurring though.

Parser Function Limit[edit]

  • I've noticed that a lot of the Shows pages for individual years have problems; they're reporting show pages that DO exist as red links. For example, Shows/2001 displays every show after 2001-9-10b as a red link, but many of these pages are on the wiki. If you enter the direct address for each page, like 2001-10-30, they're fine, but the Shows pages are displaying many of these as non-existent. Is there an easy way to fix this? --Mosesofthecows 13:53, 4 April 2009 (UTC)
  • BW - Hmmm...I noticed that these pages are now including this category: Category:Pages with too many expensive parser function calls. I'll take a look later. Something to do with upgrading parser functions.
  • BW - Nice catch, Moses. I dug into the code, and found a new variable that controls the maximum number of calls to parserfunctions in a page. I added this to LocalSettings.php, and it's working now:
    $wgExpensiveParserFunctionLimit = 500;