MediaWiki 1.14

Forums: Index > Talk to the Admins > MediaWiki 1.14

Wikia has upgraded to MediaWiki 1.14.0. We dont expect many, if any, problems. You can read more about it at http://wikia.com/wiki/MW114

Please report anything majorly broken on the central wikia forum page, so that everyone can possibly benefit from the bug finding.

Anything small, or likely only broken on this wiki, please post on this page.

Thanks for understanding. -- Uberfuzzy 15:05, 23 April 2009 (UTC)

External images and link Edit

Yes, we know about the bug that many "external" links are now marked as such, even when they are to wikia wikis. The whitelists for allowed links and images are currently messed up. Thats why your going to see some things that should be images shown as urls, both to images.wikia.nocookie.net (thats wikia's image cache farm), and even the lootdb.com images will be messed up for a while (sorry) -- Uberfuzzy 15:12, 23 April 2009 (UTC)

Caught me in mid-typing ;). Thanks for the warning. -- lordebon 15:16, 23 April 2009 (UTC)

Seems to be all fixed up. Was fairly important, so it got rushed :). It was one of the few things that wasnt checked during the testing period because the test environment didnt have some of the same setup (like those lists) as the global setup, so it wasnt something anyone thought of. We've made sure that systems like those are given priority testing now for future upgrades/expansions. -- Uberfuzzy 20:18, 25 April 2009 (UTC)

User creation log Edit

This 'user creation log' new with MW 1.14, I bet? -- lordebon 21:18, 23 April 2009 (UTC)

This used to be done via an extension, but it didnt work quite right at wikia, so it was disabled. now that extension is built into mediawiki and we're not having any problems with it, and there doesnt seems to be any extra drain from it, so its being left on. its kinda nice to actually see how often people sign up at each wiki, not just wikia as a whole. -- Uberfuzzy 20:14, 25 April 2009 (UTC)

Issue: #REDIRECTION Edit

It looks like #REDIRECTION was used in the past to redirect, for templates. Example: Template:AfD used to have it to throw to the full template. It seems #REDIRECTION no longer works in MW 1.14. If this is the case, can we get a bot to nuke all #REDIRECTION to be proper #REDIRECT entries? -- lordebon 13:56, 24 April 2009 (UTC)

oh my god, that dates back to forever and a half ago. yeah, i'll see if i can bot those out, and also i'll let the team know to keep an eye out for that. i may end up applying my bot i write for here to all of wikia :( -- Uberfuzzy 01:28, 25 April 2009 (UTC)

Yeah, where I'm seeing it are very old things that we've had no reason to change (like the AfD redirect). Thanks =) -- lordebon 13:47, 25 April 2009 (UTC)

only found it on a couple other pages, both were fairly old. one of which i created. i dont even remember doing that. No one had seen that kind of redirect in a very very long time infact. some initial tests are being done to check for it on wikis that are fairly old, but nothing is coming up so far, guess we're a fluke. -- Uberfuzzy 20:13, 25 April 2009 (UTC)

Ads Edit

Why are you letting your ads overlap your information? I've been trying to get info and all I get is your info box for the game item, promptly overlapped by some doughy, maybe michelin or goodyear or something mascot. No words, no way to turn it off, no way to see around it. Just that.

Yes, I know I could enlarge my ingame browser window, but tell me why then, I would use it at all? I can just use my regular browser if I want to do it that way.

It's so familiar and the death of many a good idea. Fix the ads on the page please and confine them to above or below. The middle of the page, blocking the info I came here for, is just going to send me elsewhere. —Preceding unsigned comment added by 174.1.28.99 ( talk • contribs )

Yes it's an issue with low resolutions and our table-centric approach at eq2i. But it DOES have a very easy solution. Register and log in and you'll only see adds on the main page, not on article pages. -- lordebon 11:14, 28 April 2009 (UTC)

I agree with UNSIGNED - if you are not going to fix the ads then I am going to default to Zam or another site whose ads are properly defined. —Preceding unsigned comment added by 98.247.213.135 ( talk • contribs )

Thankyou for your comments. As we've stated in the past, we as a wiki have no control over the ads and their formatting. The layout of them and their content is solely controlled by wikia.com, our host provider. We suggest that if there is a problem with ads, you report them using the report a problem link on every page at the bottom and provide as much detail as you can about what the ad is doing. We can then forward the information along to the appropriate contact at the host. Logging in will, however, solve many of the problems. We suggest doing that first, especially if you're running the game at the same time. If you log in before you start gaming, the login maintains its session throughout your gaming session and you don't have to worry about it again for that day. -- Kodia 12:47, 14 July 2009 (UTC)

I'd like to add a little more. In most cases, the block ads (the ones that are square, rather than the banner) should not be overlaying text. When you see this happening, report it here and we may be able to come up with a solution. By default the wiki software should not be placing square advertisments where they interfere with or obstruct our tabled formatting or other content. Also, to echo Kodia, if you log in on the in-game browser it doesn't just last for a session, it should last until you log out or the cookie expires. And once logged in you will see NO ads whatsoever on article pages, only on the main page will there then be ads. -- lordebon 12:50, 14 July 2009 (UTC)

Non-alphabetical sorting for MonoBook Edit

I do not know if it is only Monobook, the skin I use to keep familiarity with Wikipedia, but categories that show images refuse to sort alphabetically. New images added to the categories always show at the beginning of the list, never where they are suppose to (alphabetically). As I am currently working on an icon revamp - highly image intensive - it is quite an annoyance. Janze-Nek 07:33, 20 May 2009 (UTC)

not sure which category you're talking about now, but yesterday i saw that happen as well in one of those categories, and im using default skin. maybe the server is a bit loaded and it takes time to show them in the correct order? just guessing.. -- Vraeth 08:28, 20 May 2009 (UTC)

I think I actually know what your talking about. some changes were made in 1.14 regarding images and sorting in categories. It has to do with how spaces were being stored then sorted, as a space or a _. There have been other reports of certain images not sorting correctly. Give me a category where this is happening, and I can check and try to fix it. -- Uberfuzzy 08:59, 20 May 2009 (UTC)

Category:Item Icons . I see the top 5 rows as icons recently uploaded (yet alphabetical within those rows!), followed by the alphabetical listing of all icons uploaded pre-1.14. Janze-Nek 01:10, 22 May 2009 (UTC)

answer time! Edit

Categories arent actually sorted /entirely/ alphabetically. they are sorted by the sortkey used when that category is added to the page (sortkeys are how we get around the A/AN/THE issue here). If its blank, it uses the full filename, namespace included.

in mediawiki 1.14, the IMAGE namespace was renamed to FILE (long story, 5 year old bug ticket, ever since they let you upload non-image files like pdfs to it, IMAGE never made sense). the problem being, is that mediawiki likes to keep cache data for stuff, so it does have to spend time recalculating it.

http://eq2.wikia.com/api.php?action=query&list=categorymembers&cmprop=title%7Csortkey&cmlimit=25&cmtitle=Category:Item+Icons

see one from the top?

cm ns="6" title="File:Accumulated Knowledge.png" sortkey="File:Accumulated Knowledge.png" /

see one from the bottom?

cm ns="6" title="File:BlueprintGold.jpg" sortkey="Image:BlueprintGold.jpg" /

see the problem here?

the sort key hasnt changed since the upgrade, and the F in file, comes before the I in image, so the ones that edited or nullsaved (nullsaved==open->resave. no changes=no logs+no rc, but all the 'onsave' stuff happens), have the updated sortkey, and go to the top.

and before you ask, no, just a action=purge doesnt work. That mostly only works on parser related things (DPL, etc), or image metadata (the actual image data bits, like colors/size/thumbnails, not the text page part of images).

this actually explains a majnor (major+minor at same time, very large, but unimportant) bug that people have been reporting since the 1.14 switch over, and it all makes perfect logical sense. the staff is looking into if there is a server side fix for this, to just drop/purge/memwipe? all the sortkey data across the whole site, not just here.

/sigh -- Uberfuzzy 18:10, 22 May 2009 (UTC)

You are correct, I do not like it. It is what it is, though. It does not look like something the program will be able to handle without "unfixing" the bug. Can the bots be used to rename IMAGE:s to FILE:s? 71.234.215.133 03:27, 23 May 2009 (UTC) (Janze)

I just noticed something. Example: File:Altar icon.jpg is listed as File . What would happen if the category ( Category:Item Icons ) was deleted then re-created? Would this reset the category listing to turn IMAGES into FILES? 71.234.215.133 16:30, 24 May 2009 (UTC) (Janze)

I'm not sure it would. Uberfuzzy is having a discussion with the Wikia.com staff to see how best to address this since it's not just for our wiki, but the whole of Wikia.com. He mentioned that they're considering a couple of options that would be used broadly across all of the wikis to fix the problem and said he'd report back when things were decided.-- Kodia 17:18, 24 May 2009 (UTC)

I think it's an issue with the caching of the sortkey, which (to my knowledge) is independent of the listing in the category. I don't think normal methods reset the sortkey, short of actually overriding the sortkey on all those images manually for now. Uberfuzzy and the rest of the wikia staff should come up with a solution pretty soon, they're pretty good at getting things like that fixed. -- lordebon 23:59, 24 May 2009 (UTC)

Two Quests of the Same Name, In the Same Zone? Edit

There's a 'Thinning the Herd' writ from Trooper Bonesaw for freeport militia and there's also a 'Thinning the Herd' writ from Helvanica for the freeport militia. The one from Bonesaw asks you to kill young vulriches and is level 11.. the one from Helvanic asks you to kill tortured invaders and is level 22. As such, there is a conflict with the 'Thinning the Herd' writ quest page. The current page is for the level 11 writ, but if this is followed by a link from the other 'Thinning the Herd' quest, it doesn't give information for the level 22 version. How should this be handled? I have added the level 22 version to the writ page already. In other words, how should this be disambiguated, since they're in the same zone. -- Codeseer 13:45, 3 August 2009 (UTC)

This doesn't really have anything to do with the MW1.14 update, but... they are from the same zone, but do they GO to the same zone? If one is L11 and other is L22, then the zones that they send you to should be different, correct? Just name them after the destination zones then, eg Thinning the Herd (Commonlands). If they do somehow still go to the same zone, then I guess you have to go to the tier, eg Thinning the Herd (T2) vs Thinning the Herd (T3). Only go to the tier if the destination zones are still the same though, if the destinations are different (As they should be) then use those zone names. -- lordebon 18:03, 3 August 2009 (UTC)