UESPWiki:Administrator Noticeboard/Archives/Wiki Upgrade to 1.10.0

This is an archive of past UESPWiki:Administrator Noticeboard discussions. Do not edit the contents of this page, except for maintenance such as updating links.

Wiki Upgrade to 1.10.0

I finally had time to upgrade the Wiki to the latest quarterly release, 1.10.0 (thanks Nephele for reminding me occasionally). While things appear to be working in general there's a good chance a few things here and there will be broken so let me know if/when you find something. -- Daveh 22:13, 14 May 2007 (EDT)

Cool beans, though I noticed one problem right away. Any table given without a class now has a white background instead of the transparent, background-matching tan we've been using. Example:

header	header
stuff	stuff

This includes the MediaWiki:Edittools that appears at the bottom of the edit screen, so it's quite noticable. I'm guessing some line in the CSS files went back to the default Wikipedia colors. Hopefully this can be fixed? --TheRealLurlock ^Talk 22:47, 14 May 2007 (EDT)

Confirmed, getting the same white background. --AlbinoMudcrab 22:50, 14 May 2007 (EDT)

Yah, noticed this too. Should be fixable when I (or someone) has time to track it down. -- Daveh 23:08, 14 May 2007 (EDT)

Well, don't look at me - CSS is still a mystery to me. Another weird difference I noticed is that when you create a new page without putting anything in the Edit summary, it creates a summary for you, by copying the beginning lines of the page text. Given that the vast majority of pages on this site begin with a template of some sort, you're going to get a lot of ugliness like this in the history. I mean, I suppose if I remember to put something in the Edit summary that won't happen, but more often than not, the name of the page is self-explanatory enough that I don't feel it needs one. I can see how this feature could be useful in spotting spam/vandalism on a site of Wikipedia's scale where new pages are created every few seconds. But we've been doing a pretty good job of that without it - pages created as spam/vandalism are typically spotted and deleted (or blanked/Speedy Delete-tagged if the spotter was a non-Admin) within 10 minutes, tops. If this is an optional feature, I would vote in favor of not having it, though I'll let other people speak out in its defense if they see a reason to keep it... --TheRealLurlock ^Talk 23:24, 14 May 2007 (EDT)

Table background color is fixed.

More automatic edit summaries (only if one isn't provided by the editor) are indeed a new feature. I'd say having an edit summary is always more useful than having no edit summary, even if the edit summary is just template ugliness in alot of cases. But at the least I'd like to wait a few days about making any decision about changing that option, and see how the system works for a bit.

Another new feature are the numbers on the recent changes page like (-74) or (+114). Those show how many bytes were changed by the edit. --Nephele^Talk 23:35, 14 May 2007 (EDT)

Yay! Another quick save by Nephele. Although thinking about it, if it hadn't been for that glitch momentarily being on the site, I would never have noticed the extra table-formatting that I removed in my last edit of Shivering:Split, but oh well. Glad to have it back to normal. I did notice the byte-change feature added. Wasn't surprised by it, as I've seen it on Wikipedia for weeks now. I suppose it's a good way of spotting when somebody makes a drastic change like blanking a page or filling it with spam links. Again, not something we've ever really had a problem detecting without the feature, though I don't have a problem with that. I do think that the new-page auto-summary is a little bit iffy, though. If it were smart enough to take the first text after the template, it'd be one thing, but this will just look ugly the way it is now. Or I could try remembering to put something inane in the edit summary even when it should be self-evident what the page is for... Just seems like it creates more of a hassle than it should. --TheRealLurlock ^Talk 23:44, 14 May 2007 (EDT)

These are nice changes and everything seems to be working fine, exept for the fact that now all my edits are no longer marked as patrolled and I don't see the "Mark edits I make as patrolled" option under 'My Preferences' on the 'Editing' tab. Could someone fix this please? --DrPhoton 08:26, 15 May 2007 (EDT)

Hmm, I'll look into this and see why this feature is missing, whether intentional or not. I may just need to update the Patrollers extension. -- Daveh 10:57, 15 May 2007 (EDT)

Update: I'm not sure why the auto-patrol feature was removed but it seems that any edits I make are automatically marked as patrolled. Are other Sysop or patrollers seeing the same thing? I assume it is now associated with the user's level but haven't looked into it much further that that. -- Daveh 19:52, 16 May 2007 (EDT)

My edits are also still being automatically marked as patrolled. But under My Preferences -> Editing there is no longer a check box labeled "Mark edits I make as patrolled". It used to be there for both admins and patrollers, but disappeared with the upgrade. --Nephele^Talk 20:46, 16 May 2007 (EDT)

OK, I did some research and there have actually been some significant changes to how patrolling works.

The issue here is that 'autopatrol' has been turned into a user right that is assigned to a group of users (instead of being a user-by-user setting in the preferences section). By default it is given only to the groups 'bot' and 'sysop'. That means that to fix the problem a line needs to be added to LocalSettings.php that looks like:

$wgGroupPermissions['patroller']['autopatrol']      = true;

The other interesting change I noticed is that the database now keeps track of what patrollers do, so you can now see who patrolled what. For example this lists all the patrols I've done since the upgrade. Also, if you look on the history of any page you'll see a "View logs for this page" link that now shows all the patrols done on that page (again, since the upgrade only). --Nephele^Talk 14:13, 17 May 2007 (EDT)

Another vanished feature is the ActiveUsers page, which is no longer listed at Special Pages and cannot even be accessed directly. --Nephele^Talk 12:51, 15 May 2007 (EDT)

I temporarily removed this due to the SpecialPage.php outputting a bunch of error messages. It turned out to be unrelated but I'll wait until I fix the error until I restore the Active Users entry. -- Daveh 13:19, 15 May 2007 (EDT)

One more change introduced by the upgrade: multiple left-aligned thumbnails now stack vertically, instead of being placed in a horizontal row next to each other. See for example Help:Images#Multiple Thumbnails (the text of which is now wrong: left and right are symmetric) or Oblivion:Wendelbek#Maps. I can't see anything about this on the wikipedia help pages (which still claim that images work the old way), but it probably means that sets of images will now need to be placed into an invisible table in order to be arranged properly. --Nephele^Talk 17:14, 15 May 2007 (EDT)

Looks like this was a change in 1.9 in the main.css file of the MonoBook skin. I've reverted it for now (one or two comments) but if this breaks anything else let me know. It seems that Wikipedia currently works the same way...you can't align thumbnails on a single line without a table or gallery.

Also fixed the minor issue with SpecialPage.php and added Active Users back in there. -- Daveh 20:50, 15 May 2007 (EDT)

Actually, the right-aligned images now behave the way left-aligned images do, which is a change from previously. I'm not complaining, though - that's definitely a good thing. Was annoying having to create tables to do that in the past. Only problem is if it has any unintended side-effects. I don't think it will affect any existing pages, but you can never tell with these things... I'll change the Help:Images page to reflect this. --TheRealLurlock ^Talk 22:15, 15 May 2007 (EDT)