UESPWiki talk:MediaWiki 1.14 Upgrade

Upgrade Details

Large parts of the main article are effectively proposals. The core features added by Mediawiki 1.14 are fixed, but all of the other changes being made at the same time (extension upgrades, new extensions, setting changes, etc.) can be altered -- just provide feedback here! --Nephele^Talk 17:49, 15 June 2009 (EDT)

Testing the Upgrade

A test version of the upgraded site is available here. The test site is running an independent copy of UESPWiki -- changes made on the real wiki won't appear on the test site, and vice versa. So, feel free to experiment. The snapshot used to create the copied wiki was made early June 12 (pretty obvious when from its Recentchanges page). Caveats:

• Do not move images. The physical image files are being shared with the real wiki, so anything that renames the image files will mess up the real wiki. (If you really, really want to test moving images, then upload a throwaway image to the test wiki).
• Any edits made on the test wiki will disappear. The entire database copy will be deleted once the wiki is fully migrated to MW1.14. In addition, I'm probably going to overwrite the database at some point (in particular, I want to recreate it from a more up-to-date version of the wiki, once I've finished fixing the site's images). And when edits are lost on the test wiki, they're gone -- no history, no undelete.
• The awkward URLs on the test site are simply because the site is temporary; the occasional redirect to www.uesp.net (instead of content1.uesp.net), for example, when you login, is also just because it's all a test site. (redirect issue fixed).
• I may make configuration changes to the test site at any time, without warning. And I may occasionally mess up those changes ;) So if you suddenly can't access pages any more, wait a few minutes then try again.

I'm tentatively targeting the night of June 23 (morning of June 24) for the switchover of the full site from MW1.10 to MW1.14. Of course, the date is subject to change if major problems are found on the test site. I'll also post some site-wide notices as the date approaches.

I've only done a minimal amount of poking around in the test site. Problems I've noticed so far:

• Tagline needs to be disabled on main page
• The version of the site is a few days old -- which is why the sidebar has reverted to the old, non-indented format

--Nephele^Talk 17:49, 15 June 2009 (EDT)

If it's possible, can I suggest a site notification or other blatantly obvious reminder to people that they're looking at the test site and not at the real thing? --Robin Hood (Talk • E-mail • Contribs) 22:25, 15 June 2009 (EDT)

Good idea :) I've added the notice, but I should also warn you that if you click the "dismiss" link that appears next to the notice, it will disappear for you (new feature!), and there's no way for you to get it back, at least not until the notice is updated. --Nephele^Talk 23:17, 15 June 2009 (EDT)

Thanks! And actually, as I recall from the DismissableSiteNotice docs, it's cookie-based, so deleting my cookies should restore the notice. But yeah, probably just easiest not to dismiss it at all. :) --Robin Hood (Talk • E-mail • Contribs) 00:41, 16 June 2009 (EDT)

True, it is cookie-based, so that should work. --Nephele^Talk 00:46, 16 June 2009 (EDT)

I'm about to replace the test wiki database with a more up-to-date copy (in particular, so that it's possible to check whether there are any obvious problems with image layout). It'll take a couple of hours for the update to run, during which time trying to view the test wiki is probably going to trigger various error messages. I'll post a message here once it's functional again. FYI, I'm not planning on overwriting the copied database again after this. --Nephele^Talk 01:24, 16 June 2009 (EDT)

And it's back online. --Nephele^Talk 03:54, 16 June 2009 (EDT)

More fixes to take care of when I have the chance:

• Change all templates such as Template:KotN Header to use a style-sheet class; on upgraded wiki the style-sheet needs to use negative value for top/bottom. Point out change to users such as Gez who need to change their user page. Look for other cases where absolute positioning has been used.
  • Need to check/tweak icon position for Template:Page Icon, Template:Featured article and Template:Adamantium+LeFemm Header
  • Pages that still use absolute positioning: User:Daedryon/Userheader, User:Gez, User:Syv, User:BC
• Update MediaWiki:Recentchangestext to match test site
• Is it feasible to change all bread crumb trails to new format before upgrade -- then change upgraded CSS to reposition site tag and div.breadcrumb (not that breadcrumb should be in use any more)
  • Still need to be fixed: Template:Place Summary, Template:Shadowkey NPC Summary

--Nephele^Talk 11:43, 16 June 2009 (EDT)

(Question about external editors moved to UESPWiki:Administrator Noticeboard#External Editor) --Nephele^Talk 17:07, 24 June 2009 (UTC)

Post-Upgrade Problems

If you notice anything unusual that may have been caused by the upgrade, please provide details here. --Nephele^Talk 16:34, 24 June 2009 (UTC)

Just wondering, how come you switched to 1.14.0 rather than MediaWiki 1.15.0? --Michaeldsuarez ^{(Talk) (Deeds)} 17:45, 24 June 2009 (UTC)

As the project page says:

"Note that MW1.14 is no longer the most current version of MediaWiki: version 1.15 was just released on June 10, 2009. However, the improvements introduced by MW1.15 are less significant, so it doesn't seem worth restarting the UESP upgrade process. The next UESP upgrade is probably going to be to version 1.16 (likely to be released in about 4 months)."

So I'd guess that's why ;). –Eshe^talk 17:48, 24 June 2009 (UTC)

Sorry, I didn't realize that this was only a talk page. --Michaeldsuarez ^{(Talk) (Deeds)} 17:50, 24 June 2009 (UTC)

Foreign languages: choosing a default language other than English may cause a lot of formatting problems (some visible as <prefs-memberingroups> and <comma-separator> tags on the preferences page as soon as you save your preferences). I'm guessing this is related to the internationalisation cache failing to refresh (i.e., the same problem that stymied the upgrade for 8 hours) -- the good news is at least the pages are loading. Problems seen for German, but not French or Italian, supporting the theory that it's a cache problem rather than a code problem. I need to figure out whether there's a way to see what languages have been cached or whether to somehow just clear all of the memcached data. --Nephele^Talk 00:42, 25 June 2009 (UTC)

• Fixed. --Nephele^Talk 01:06, 25 June 2009 (UTC)

"Morrowind:Morrowind": While I suspect that it's currently being worked on, I would like to note that for some reason, the (TESIII) Morrowind article home page is showing an "Internal error". All other Morrowind articles seem to be in working order. 24.16.181.131 02:37, 25 June 2009 (UTC)

Here is a screen shot of the image. I use FF, but Eshe has reported that it works with Google Chrome. --Mr. Oblivion^(T-C) 02:43, 25 June 2009 (UTC)

Purging seems to have fixed it. --GK^Talk2me 02:47, 25 June 2009 (UTC)

Oops, I thought I replied to this an hour ago, but my edit wasn't saved because of an edit conflict. I also took care of purging the page a few times.

FYI, that error message was very clearly generated while the site was in the middle of the upgrade -- the dead giveaway is the orange upgrade site notice. As for the error being reported, it's The Error that I had to fix before completing the upgrade; the page was obviously generated during one of the brief periods when I turned on the upgrade in an attempt to diagnose this specific error. In other words, the error has already been fixed. So if any editors see orange upgrade notices on error pages, all that needs to be done is to purge the page and refresh it; there's no need to track down the error. --Nephele^Talk 03:50, 25 June 2009 (UTC)

Uhh, the Morrowind:Quests page is showing an internal error also, this is different however; unformatted plain text. For example: "Exception caught inside exception handler: exception 'MWException' with message 'Magic word 'hiddencat' not found' in /home/www/uesp.net/w/languages/Language.php:1773". P.S. What is 'hiddencat'?

Purged. Now works okay. –Rpeh^{•T•C•E•} 07:58, 25 June 2009 (UTC)

DEFAULTSORT warnings: Several pages were generating a red warning message that the page's default sort key had been changed (i.e., that {{DEFAULTSORT}} was being used twice on the page and/or its templates). The red warning message is a new "feature", and it's possible that some such warnings will be legitimate. However, an obscure bit of coding in UespCustomCode was also triggering the warning even when DEFAULTSORT was only being called once; I've fixed the code. So if you see such a warning, try to purge the page first; if the warning doesn't go away, then start hunting through the page's templates for multiple DEFAULTSORT tags.--Nephele^Talk 04:12, 25 June 2009 (UTC)

Three that won't go away: Morrowind:Lord Dregas Volar, Morrowind:Ghost of Galos Heleran, and Morrowind:Wraith of Sul-Senipul. –Rpeh^{•T•C•E•} 19:42, 26 June 2009 (UTC)

I found the problem DEFAULTSORT tag in the Soul template, and deleted it (the second DEFAULTSORT tag is a useful one in the Creature Summary template that is only activated if the altname parameter is set). I'm half-tempted to disable the ugly red warning message, but on the other hand it is useful for tracking down DEFAULTSORT tags that no longer have any reason to exist. I'm also very relieved that our recent code changes have made nearly all of our DEFAULTSORT tags obsolete, otherwise it would be impossible to get rid of the warning messages :)

If any others are found, a useful trick I just came across is to add something like {{DEFAULTSORT:testing}} at the very top of the problem page. The red messages will then appear at the location in the document anytime another tag is inserted, making it much easier to zero in on the problem templates. --Nephele^Talk 20:18, 26 June 2009 (UTC)

Search Problems Doing a search for "Knights of the Nine" results in no hits, and at the top of the page "<uespsearchmany>" appears. This occurs whether I'm logged in or out. It appears to be a problem with small words: "Order of the Virtuous Blood" gets no results, but "Order Virtuous Blood" does, although "Knights Nine" still gets nothing. –Rpeh^{•T•C•E•} 10:48, 25 June 2009 (UTC)

The "<uespsearchmany>" was an easy fix, but the rest of it gets ugly ;)

Yes, the basic problem is with small words. MW1.14 has added a hack to make it possible to search on small (two-letter) words such as 'of' and 'the' -- a hack consisting of changing any such words into 'ofu800' and 'theu800' (we had already tweaked our database so that three letter words, e.g., 'the', are not considered short). Previously such words were simply ignored in queries, since the MATCH function in mysql completely ignores such words (there's probably a bit more explanation at Help:Searching). The reason why it's causing a problem is that our search indices have not yet been updated. This afternoon, I should be able to rerun a patch from a few weeks ago that at least fixes the search index titles for now; eventually we'll really need to rebuild the entire search index, but I'd rather wait a few days before doing that. If you want to speed up the process and at least get 'knights of the nine' working again, do a dummy edit on the article (a purge might not be enough) to force its search index entry to update. (Or to convince yourself that the underlying problem is fixed, try a search on 'gray cowl of nocturnal', which has already been re-indexed).

The third problem is even uglier. 'nine' is basically a word that mysql ignores -- not because it's short, but because it's too common. The MW1.14 hack only tries to fix short words, not common words. On top of that, in trying to allow plurals of words to match, I was basically forcing mysql to do a match on 'nine*', which mysql does not ignore, unlike a search on 'nine'. I made a tweak to my code -- which means mysql is back to just ignoring 'nine', rather than half-ignoring nine and failing as a result. In any case, a search on 'Knights Nine' is now returning results again -- but it's somewhat useless because it's really just doing a search on 'Knights'. There's not much I can do about that.

In summary: one issue fixed, another needs a major database refresh to fix, and the third is no longer broken (but not really fixable).

Oh, and most of this ugliness only applies to "searches" not the "go" feature. --Nephele^Talk 18:18, 25 June 2009 (UTC)

Perhaps it is worth noting that the lack of hits for "Knights of the Nine" occurred prior to the upgrade as well. --Mr. Oblivion^(T-C) 18:29, 25 June 2009 (UTC)

Is there a content-side hack we can make for affected pages? Adding "u800" to the {{DISPLAYTITLE}} for example? Or am I misunderstanding the problem? –Rpeh^{•T•C•E•} 19:14, 25 June 2009 (UTC)

Mr. Oblivion: Correct, searches on 'nine' would have failed completely before the upgrade, too.

Rpeh: Any type of edit on an affected page will fix the u800 problem -- because that will force the searchindex entry for the page to be refreshed (both title and full text indices). Also, as far as the titles are concerned, the server is churning through and refreshing all the titles as we speak (should be done in less than 2 hours). The full text of all articles will still need to be refreshed (so that searching for 'knights of the nine' will also work if you unselect the "Search Titles Only" box). I'd rather wait until next week, however, to start that job (it will take a while, and the servers are already being kept busy purging the squid cache).

Myself (for future reference): The issue with searching on 'nine' (or 'eight', or any other word in this list that has special significance for UESP) can eventually be fixed, but it will require Daveh. I'll need to create a custom stopword file (notes), then Daveh will have to set the ft_stopword_file system variable (4.1 manual) in the mysql configuration file. And then don't forget the notes here about rebuilding the fulltext indices.

--Nephele^Talk 19:48, 25 June 2009 (UTC)

Oh, and I just found one final complication that's resulting in "Go" failing for 'Knights of the Nine': a redirect at 'Knights of the nine', which means that "Go" doesn't know which of the two articles is the one you're looking for. I'm going to speedy delete the redirect. --Nephele^Talk 20:00, 25 June 2009 (UTC)

Documentation

As a reminder to myself, documentation related to the upgrade features/changes needs to be added in a lot of places around the site:

• Admin page needs to spell out new admin abilities
• Patroller page needs to spell out new patroller abilities
• Protection policy tweaks reflecting new patroller abilities
• Updates to search help page
• Lots of changes needed on images help page -- including ability to rename images and implications
• Add other extension-based non-standard parser functions/tags to Help:Magic_Words

--Nephele^Talk 07:15, 26 June 2009 (UTC)

Moving Images - minor issue

I just renamed Danus Artellian's image to fit with the standard. Everything was fine logged in, but I had to purge the page while logged out to get the new image to show. Yet another caching problem, and a fairly minor one since it's so easily fixable, but I thought I should mention it. –Rpeh^{•T•C•E•} 07:25, 26 June 2009 (UTC)

As far as I can tell, the job queue will automatically deal with pages that display any moved images (including telling squid to update its HTML for the page), but since it's going through the job queue, it might not happen instantaneously. I just did some tests, forcing the job queue to immediately complete all its tasks behind the scenes, that confirmed this. I'm not sure there's much else that can be done. --Nephele^Talk 22:22, 26 June 2009 (UTC)

Protect Tags

Okay, so now that we can protection tags, how do we do it? I tried looking at MediaWiki's site and quickly became lost. :) --Robin Hood (Talk • E-mail • Contribs) 19:16, 26 June 2009 (UTC)

You put <protect>...</protect> around the sections you want to protect. Simples :) –Rpeh^{•T•C•E•} 19:39, 26 June 2009 (UTC)

Also, adding [[Category:Section Protection]] to the page is recommended. Guidelines, such as acceptable usage, are covered on UESPWiki:Protection Policy. --Nephele^Talk 20:32, 26 June 2009 (UTC)

CSS and IE

Could the recent tweaks to the stylesheets be the cause of the Ingredient pages not appearing properly in IE6? Can someone test whether the pages appear properly in subsequent versions of IE? The pages work fines in Firefox, and I assume that means they appear correctly in Opera, Safari and all other normal browsers. --Timenn < talk > 09:47, 27 June 2009 (UTC)

Ugh. I see what you mean. Must be an IE6-specific CSS problem - it looks fine with IE7 and IE8. –Rpeh^{•T•C•E•} 10:01, 27 June 2009 (UTC)

Here is a screenshot for those without IE6. –Rpeh^{•T•C•E•} 10:05, 27 June 2009 (UTC)

originally posted at Morrowind talk:Morrowind#Ingredient pages, what's going on with the pictures?

There seem to be some sort of problem with the pictures on the ingredient pages. They are halfway outside of my screen. :(

Anyone who knows how to fix this or something? -Goblin lair 12:02, 27 June 2009

Update your browser? IE 6 is obsolete and no longer supported by Microsoft, and its standard-compliance has always been a joke, forcing webmasters to rely on kludgy hacks to get it to display pages correctly. From what's been said above, it is the only browser that has problems -- Firefox works, as do IE 7 and IE 8. --Gez 10:12, 27 June 2009 (UTC)

Chrome, Opera and Safari all work too. I agree with Gez - it's time to forget about IE6. –Rpeh^{•T•C•E•} 12:01, 27 June 2009 (UTC)

I'm also not sure it's related to the upgrade -- the computed CSS styles for those ingredient images should be the same now as before (assuming that IE6 was at least able to compute CSS styles correctly, which might be a big assumption). Actually, someone with IE6 could check an old-site version (although that wouldn't test whether any of the tons of other changes in the last month are responsible). And if someone wanted to work out a IE6 CSS hack to fix it, I could add the hack to the IE6-specific stylesheet. However, I'm unlikely to put a lot of time into it -- only 14.5% of webusers still use IE6, and the number is dropping steadily. --Nephele^Talk 16:51, 27 June 2009 (UTC)

The old version is displayed correctly in IE6. I agree that IE6 should have been totally deprecated years ago, but I'm willing to take a look at what part of CSS is causing this. --Timenn < talk > 17:17, 27 June 2009 (UTC)

Confirmed. IE6 displays the old version correctly. –Rpeh^{•T•C•E•} 17:23, 27 June 2009 (UTC)

Upload of zip-files no longer possible

Seems since the upgrade to v1.14 it is no longer possible to upload any zip-files. I think someone should look into this matter and find a workaround for this problem.--PLRDLF 13:51, 29 June 2009 (UTC)

Confirmed - I get "Files of the MIME type "application/zip" are not allowed to be uploaded.". It seems this is something only Nephele and Daveh can fix. –Rpeh^{•T•C•E•} 14:02, 29 June 2009 (UTC)

OK, I think I've fixed the problem. MW1.14 doesn't want to allow zip files because of some issue with java archives and cookie-stealing, but it's clearly a filetype that we need to allow, so I've overridden the setting. --Nephele^Talk 16:13, 29 June 2009 (UTC)

Addendum: now it's really fixed ;) --Nephele^Talk 16:59, 29 June 2009 (UTC)

Problems with large png-images

It seems that there are some problems when it comes to larger png-images. I recently uploaded this image Image:BS-The_Battlespire1.png and shortly after it was gone. Furthermore when I try to upload the same image again, the same problem occurs. Using jpg-images or smaller png-images works without any problems.--PLRDLF 23:14, 9 September 2009 (UTC)

640x480 images should be converted to jpeg format, not uploaded as pngs. 900KB is far larger than most images on the site, and the other large images are all maps, where the resolution is necessary to convey meaningful information. Although ideally such a large image shouldn't trigger the types of errors you're seeing, I'm not sure whether it's worth fixing errors that only occur for images that shouldn't be uploaded in the first place. --Nephele^Talk 23:35, 9 September 2009 (UTC)