Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 23:41, 8 October 2011

Table of contents
First discussion
End of page
New post

Shortcuts

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla. Bugs with security implications should be reported to security

wikimedia.org.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Amazon Elastic Compute Cloud cache of WP

In this arstechnica piece on the Kindle Fire they mention an X-ray read-ahead cache of related Wikipedia content. Does this mean that we should expect Amazon Elastic Compute Cloud to be caching WP from now on? If so, does it open up any new performance possibilities? Just wondering... LeadSongDog come howl! 18:41, 29 September 2011 (UTC)[reply]

Doesn't seem to affect us since the article suggest they only pre-cache things for the kindle. Wikipedia is already cached quite heavily from Wikimedia servers. Bawolff (talk) 01:59, 7 October 2011 (UTC)[reply]

Secure login link

I think the secure login link on the login page needs to be changed: it gives https://secure.wikimedia.org/wikipedia/en/wiki/Special:UserLogin.

However, when switching between wikipedias (interwiki), it goes to a simple https://xx.wikipedia.org --- and therefore logs me out. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 04:10, 1 October 2011 (UTC)[reply]

The cross wiki problem is a known issue. I have changed the Login page to point to the new urls. There is one snag, I don't think there is a replacement atm for the "{{#ifeq: {{SERVERNAME}} | secure.wikimedia.org" trick that we used to change the content between secure and insecure servers. If anyone has an idea for a replacement, please do share. —TheDJ (talk • contribs) 11:11, 1 October 2011 (UTC)[reply]

That line is added dynamically in MediaWiki:Loginend when a user is not on secure.wikimedia.org. Unfortunately, there is no magic word to query the used protocol (there is $wgProto, but no {{SERVERPROTO}}), meaning that check will have to be removed. — Edokter (talk) — 11:15, 1 October 2011 (UTC)[reply]

bugzilla:31293 proposes to simply split up the user message for the Special:UserLogin page from the server side. That would fix this specific problem. —TheDJ (talk • contribs) 22:20, 1 October 2011 (UTC)[reply]

Great. I hope this will be done for all wikipedias. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 02:35, 2 October 2011 (UTC)[reply]

my secure login is no longer available via the icon, if anyone understands this occurance then please explain Drift chambers (talk) 09:59, 6 October 2011 (UTC)[reply]

Looks like we've been upgraded

MW 1.18 is apparently here (Special:Version). There are a few teething issues (sidebar not collapsible, no edit toolbar... looks like ResourceLoader is dead). — This, that, and the other (talk) 00:31, 5 October 2011 (UTC)[reply]

Scripts are back. The Twinkle drop-down menu is now broken, so that will need to be fixed... aside from that, all seems to be OK. — This, that, and the other (talk) 00:34, 5 October 2011 (UTC)[reply]

Closing AfDs, the text in the "closing" and "relist" boxes is now like this and straining the eyes, is that a temporary thing I hope? - The Bushranger _{One ping only} 00:37, 5 October 2011 (UTC)[reply]

Not only is the Twinkle menu visually broken, but the scripts themselves are still having issues. I just now got a "User talk page modification: Unknown error received from API while saving page" error. Regards, Orange Suede Sofa (talk) 00:38, 5 October 2011 (UTC)[reply]

And Twinkle is occasionally 'hanging' while closing AfDs. Sigh! - The Bushranger _{One ping only} 00:52, 5 October 2011 (UTC)[reply]

I notice all the tabs and sidebar links are underlined now. It looks pretty ugly (but I still much prefer the underlines in the body which is why I have that setting.). Also, the 'm' and 'b' notes on the watchlist aren't bold any more. ♫ Melodia Chaconne ♫ (talk) 01:55, 5 October 2011 (UTC)[reply]

My watchlist isn't working correctly. Multiple changes to the same page are supposed to be collapsed together, but it's not working... Also, there's an odd glitch with the down arrow next to Twinkle, the page menu gadget, etc. It's showing 5 times in a row, the same distance apart, and the text goes in front of it. Might either of these things have to do with the new version? →Dynamic|cimanyD← (contact me) 02:47, 5 October 2011 (UTC)[reply]

In the "user contributions" list the ability to filter by namespace is gone.[1] Will Beback talk 01:55, 5 October 2011 (UTC)[reply]

This was reported on bugzilla:31197. Helder 02:05, 5 October 2011 (UTC)[reply]

Citations in {{reflist|group=upper-alpha}} are broken, see South American dreadnought race#Footnotes. There's also an extra drop-down arrow over "TW" in the top right corner (presumably only for users of Twinkle). Ed ^{[talk] [majestic titan]} 02:46, 5 October 2011 (UTC)[reply]

See #bug in #tag:ref parser function. I did fix one use that had quotes around "upper-alpha"— see Help:Cite link labels. ---— Gadget850 (Ed) ^talk 09:51, 5 October 2011 (UTC)[reply]

Who ever fixed the ref-note glitch -- Thank you!!! -- Gwillhickers (talk) 07:06, 6 October 2011 (UTC)[reply]

I have the same arrow problem, except since I use this I have several extra arrows. →Dynamic|cimanyD← (contact me) 02:50, 5 October 2011 (UTC)[reply]

User talk:72.27.85.119 is also borked in a really weird way... Hersfold ^(t/a/c) 03:05, 5 October 2011 (UTC)[reply]

Yet a permanent link to the current revision of the page works just fine. →Dynamic|cimanyD← (contact me) 03:08, 5 October 2011 (UTC)[reply]

One good thing I noticed is the message you see when you watch/unwatch a page now slides down smoothly, instead of just appearing. →Dynamic|cimanyD← (contact me) 03:10, 5 October 2011 (UTC)[reply]

Naturally, of course, no one has noticed or cared about this yet since it's an improvement, not a problem. →Dynamic|cimanyD← (contact me) 20:06, 6 October 2011 (UTC)[reply]

The letter tags for minor edits ("m") and bot edits ("b") in page histories and my watchlist are no longer showing in bold type for me. —{|Retro00064|☎talk|✍contribs|} 03:14, 5 October 2011 (UTC)[reply]

Wasn't it possible before to click on links in diffs? That no longer works. Orange Suede Sofa (talk) 03:18, 5 October 2011 (UTC)[reply]

What do you mean? —{|Retro00064|☎talk|✍contribs|} 03:28, 5 October 2011 (UTC)[reply]

Wikilinks in the body of diffs used to be displayed with markup (e.g. [[foo]] instead of foo), but were still clickable. Now they are still displayed with markup but are not clickable. Or at least I think it used to work that way. I remember it being very useful when verifying sources directly from a diff. Orange Suede Sofa (talk) 03:46, 5 October 2011 (UTC)[reply]

Unless there's a local site hack or gadget that I'm overlooking, I don't think that was ever the case. You can check a diff on dewiki (which is still running 1.17) for comparison.--Eloquence * 04:08, 5 October 2011 (UTC)[reply]

Oh, you're right. I have "Improved diff view" checked in my gadget preferences. I'm assuming that is it. Ok, then... that's broken. Regards, Orange Suede Sofa (talk) 04:13, 5 October 2011 (UTC)[reply]

solved — ☠MarkAHershberger☣ (talk) 04:26, 6 October 2011 (UTC)[reply]

I came over here hoping to find out why, since approximately 00:00 UTC today, any page looks as if I hadn't logged in or my monobook skin disappeared. Tabs which were at top of page (history, edit, talk, etc.) are gone, though a search down the page found the functions themselves. The entire left margin (with the Wikipedia globe and links to the Main Page and all sorts of other functions) is gone. It was OK on Wikimedia Commons for about an hour then, but the same thing had gone whacko there when I returned after a few hours offline. If an upgrade caused this, I hope there's a downgrade very soon... – Athaenara ✉ 07:49, 5 October 2011 (UTC)[reply]

Is this also the reason why the website keeps crashing? I've just wasted an hour trying to edit one page. DrKiernan (talk) 08:32, 5 October 2011 (UTC)[reply]

Yes, seems so. It works in Mozilla but not Explorer. DrKiernan (talk) 09:06, 5 October 2011 (UTC)[reply]

Invisible block: should blocked user be told automatically how to get third party review?

I was told on my talk page that my bot account had been blocked. However, I can't see any indication of the block. I don't want to try much testing in case it gets this account blocked too.

I'm not seeking opinions on the merits of the block. I'm sure that will all be sorted out. I'm merely seeking technical help on the following:

why is the block invisible to me at the blocked account (Lightbot) even if I log in as that account?
I understand blocked users are told how to get a third party review. Why is that also not visible to me?
what is the method of getting third party review?

Thanks. Lightmouse (talk) 01:07, 5 October 2011 (UTC)[reply]

http://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3ALightbot shows the block fairly clearly. ΔT _{^{The only constant}} 01:10, 5 October 2011 (UTC)[reply]

I didn't know of that page. Is there a particular reason why blocks don't show at user pages? Lightmouse (talk) 01:45, 5 October 2011 (UTC)[reply]

it only shows in the block log and on the contribs page. ΔT _{^{The only constant}} 01:46, 5 October 2011 (UTC)[reply]

The log exists for other users to see the block. It is prepended to the user's contributions page, and to their userpage if it is empty. The user who is blocked will receive this message when they try to edit, explaining who blocked them, when, for how long, why, as well as giving four ways to appeal. Prodego ^talk 01:49, 5 October 2011 (UTC)[reply]

Interesting. Why don't we tell users before they try to edit? Lightmouse (talk) 01:53, 5 October 2011 (UTC)[reply]

Tell them what before they try to edit, exactly? That they're blocked? KillerChihuahua^?!?Advice 03:11, 5 October 2011 (UTC)[reply]

Yes. But more importantly, how to get unblocked. The same information before the attempted edit as after. 09:42, 6 October 2011 (UTC)

Different formatting of categories?

It looks like the categories box at the bottom of most pages has been reformatted to include more space between the category names. Where was this discussed or where would it be discussed? --Metropolitan90 (talk) 05:20, 5 October 2011 (UTC)[reply]

Yes, I believe it was a result of the MW 1.18 rollout (see above). Not sure where you would go to discuss it, someone else might, though. Jenks24 (talk) 05:23, 5 October 2011 (UTC)[reply]

...I just noticed that now that you mentioned it. It looks horrible. So does text in the close/relist AfD boxes being this size. - The Bushranger _{One ping only} 05:44, 5 October 2011 (UTC)[reply]

Looks good - more modern and Vector-ish, in my opinion - unlike the old category-link style that was left over from Monobook. — This, that, and the other (talk) 05:52, 5 October 2011 (UTC)[reply]

That's all well and good - except I have (and prefer) Monobook, and would like to at least have the option to have the old style display. - The Bushranger _{One ping only} 06:03, 5 October 2011 (UTC)[reply]

It does look terrible on Monobook. "More modern" does not necessarily mean "better". --jpgordon^{::==( o )} 06:13, 5 October 2011 (UTC)[reply]

Yes, I can imagine that it would jar with the small, sharp style of Monobook. Perhaps we can change it locally through MediaWiki:monobook.css? — This, that, and the other (talk) 06:36, 5 October 2011 (UTC)[reply]

I use the classic monobook as well, and yes, the categories look weird. The tiny inline icon that used to appear after an external link is now missing too... all I see there now, is a blank whitespace. -- WikHead (talk) 07:45, 5 October 2011 (UTC)[reply]

Don't call "Monobook" classic, because "Classic" is a different skin... and the categories look horrible there too. DS (talk) 23:07, 5 October 2011 (UTC)[reply]

It looks terrible in Monobook, so I just now switched to Vector, and I think it looks just as bad in Vector. --NSH001 (talk) 09:09, 5 October 2011 (UTC)[reply]

It looks like it was done in rev:92054 (bugzilla:12261), due to the change in how they are rendered. Peachey88 ^{(T · C)} 08:02, 5 October 2011 (UTC)[reply]

Blech! I agree that the categories look quite terrible now. --Philosopher ^{Let us reason together.} 19:35, 5 October 2011 (UTC)[reply]

Anyone who doesn't like the new styles should be able to get the old ones back pretty easily. Let me know if you need help setting up your CSS for this. — ☠MarkAHershberger☣ (talk) 04:50, 6 October 2011 (UTC)[reply]

This category issue is clearly associated with the move to Mediawiki 1.18. It is almost certainly a BUG, probably technical but at the least aesthetic. Even if 1.18 somehow fixed a CSS rendering issue and is now rendering the categories "correctly", the skins were designed with the old rendering in mind. Regardless of the technical question of the correctness of the new rendering, the new look for the categories is terrible. There's simply way too much space being used for the category separators. (I am using Vector and haven't checked Monobook.) This should be investigated and the look should revert to the previous spacing. Jason Quinn (talk) 00:14, 7 October 2011 (UTC)[reply]

See #Categories are surrounded by much more space, and they don't wrap from line to line for a chunk of CSS to restore something like the old behaviour. --Redrose64 (talk) 11:35, 7 October 2011 (UTC)[reply]

Enhanced recent changes doesn't work

Resolved

– fixed

Enhanced recent changes is no longer working on my account. Is this the case for others, or am I alone in this problem?

I have used the feature for years, without problem. But this morning, it simply does not work. My watchlist appears, with all of the diffs displayed, rather than collapsed. as usual. Other Java features seem to work normally, so I don't think I have a Java problem. Has there been any change made overnight which could have caused this?

I have checked my preferences, and "enable enhanced recent changes" is checked. I have rebooted my computer, in case something hadn't loaded properly; but this makes no difference. Please help, as it is difficult navigating a long watchlist with all diffs displayed. RolandR (talk) 08:12, 5 October 2011 (UTC)[reply]

That would be bugzilla:31358, also strange question, What skin are you running?. Peachey88 ^{(T · C)} 08:44, 5 October 2011 (UTC)[reply]

Vector. Looking at the contributions above, it is clear that others are experiencing this issue, and that it is related to the latest upgrade. I hope it can be resolved soon. RolandR (talk) 08:51, 5 October 2011 (UTC)[reply]

It is Vector. Thanks for your help, I'll change my skin for a while. Pitke (talk) 15:20, 5 October 2011 (UTC)[reply]

It's working again. But I still have some of the other problems noted below. RolandR (talk) 23:02, 5 October 2011 (UTC)[reply]

1.18 issues

Interwiki(s):

commons:Commons:Village_pump#MediaWiki_1.18_deployment_to_Commons

We've gone 1.18 (yay!). Unfortunately, not without any hickups that are sure to be fixed very soon. Please list your issues here. — Edokter (talk) — 09:08, 5 October 2011 (UTC)[reply]

Wasn't there any testing done on this release? It's certainly introduced a load of problems that ought to have been caught by any proper test plan. Malleus Fatuorum 22:04, 5 October 2011 (UTC)[reply]

Yes, see this discussion — ☠MarkAHershberger☣ 18:45, 7 October 2011 (UTC)[reply]

Special:PrefixIndex

Issue reported here: Bugzilla:31362 -- ☠MarkAHershberger☣ (talk) 20:35, 5 October 2011 (UTC)[reply]

Extended content

When transluded on a page, Special:PrefixIndex is broken in that it displays in a table that no longer has it's width set to 98%, resulting in the links being cramped together like so:

But on it's own page (Special:PrefixIndex/User:Edokter), display is OK. It seems when transcluded, the CSS for #mw-prefixindex-list-table doesn't seem to get picked up. — Edokter (talk) — 09:08, 5 October 2011 (UTC)[reply]

I see the CSS for the prefindex table is loaded trough the mediawiki.special module, which apparently is not loaded if you are not viewing a special page. That means that any special content transcluded on a normal page will not have it's accociated CSS loaded at all. — Edokter (talk) — 09:13, 5 October 2011 (UTC)[reply]

A fix for this was requested on bugzilla:31362. Helder 13:24, 5 October 2011 (UTC)[reply]

Down-arrow in dropdown menu

The down arrow on top of the drop down menu (in Vector) is one pixel off (to the left). The arrow icon has been changed to enable highlighting, but some CSS may not have been updated. — Edokter (talk) — 12:14, 5 October 2011 (UTC)[reply]

off-by-one error on down arrow — ☠MarkAHershberger☣ (talk) 04:58, 6 October 2011 (UTC)[reply]

New image uploaded to bugzilla. — Edokter (talk) — 16:47, 6 October 2011 (UTC)[reply]

bug in #tag:ref parser function

Resolved

– Should be working now. Purge pages if error is still appearing. —mc10 (t/c) 05:42, 6 October 2011 (UTC)[reply]

Extended content

I guess this is yet another problem with the MW 1.18 rollout above.

When a <ref> tag is used within a note which is itself within a #tag:ref function, the superscript appears as a very long (and ugly) string (representing the internal link to the cite) instead of the normal small numeral. The link is still clickable and works fine, apart from the very ugly and off-putting display. Example at User:NSH001/sandbox.

--NSH001 (talk) 09:02, 5 October 2011 (UTC)[reply]

Confirmed. This breaks {{refn}}. I think we have seen this one before. ---— Gadget850 (Ed) ^talk 09:06, 5 October 2011 (UTC)[reply]

Err, does that mean it's going to be fixed? It's been working fine (for months, at least) until now. --NSH001 (talk) 09:12, 5 October 2011 (UTC)[reply]

See the section above this one, and see an example of the damage: Prince George of Denmark#Notes. DrKiernan (talk) 09:11, 5 October 2011 (UTC)[reply]

All refs on that page contain nested <ref> tags; I don't think that is even supported... — Edokter (talk) — 09:17, 5 October 2011 (UTC)[reply]

Support was added in rev:33066. {{refn}} has been working until now. ---— Gadget850 (Ed) ^talk 09:29, 5 October 2011 (UTC)[reply]

It's the way suggested at WP:REFNEST when one wants to place a reference in a footnote. DrKiernan (talk) 09:25, 5 October 2011 (UTC)[reply]

For more examples, see Anna Essinger#Footnotes and Bunce Court School#Footnotes and Sir Arthur Harris, 1st Baronet#References. Hope this is fixed soon! Marrante (talk) 09:16, 5 October 2011 (UTC)[reply]

~~Already reported as Template:Bug.~~ ---— Gadget850 (Ed) ^talk 09:29, 5 October 2011 (UTC)[reply]

Has this been fixed? I'm not seeing it. Ucucha (talk) 11:33, 5 October 2011 (UTC)[reply]

Nope, still not working. --NSH001 (talk) 11:38, 5 October 2011 (UTC)[reply]

Per Happy-melon on previous issues:

The "uniq...quinu" strings are strip markers: placeholders that the parser inserts to say "more complicated content will go here". Exposing strip markers, which is what is happening here, occurs when badly-formed code in MediaWiki causes the parser to be reset, and lose its memory of which strip marker corresponds to which piece of special content.

Logged as Template:Bug. If you see the strip marker below, then it is still broken; if you see "Fixed now!", then it is fixed. ---— Gadget850 (Ed) ^talk 12:07, 5 October 2011 (UTC) ^{[note 1]}[reply]

^ ^[1]

^ Fixed now!

I just visited Tropical Storm Debra (1978), one of my articles, and the "footnotes" section says "Tornadoes were confirmed in Texas,?UNIQ4f238ebe6a8c71c3-nowiki-00000031-QINU?4?UNIQ4f238ebe6a8c71c3-nowiki-00000032-QINU??UNIQ4f238ebe6a8c71c3-nowiki-00000034-QINU?5?UNIQ4f238ebe6a8c71c3-nowiki-00000035-QINU??UNIQ4f238ebe6a8c71c3-nowiki-00000037-QINU?6?UNIQ4f238ebe6a8c71c3-nowiki-00000038-QINU? Louisiana,?UNIQ4f238ebe6a8c71c3-nowiki-0000003A-QINU?4?UNIQ4f238ebe6a8c71c3-nowiki-0000003B-QINU??UNIQ4f238ebe6a8c71c3-nowiki-0000003D-QINU?7?UNIQ4f238ebe6a8c71c3-nowiki-0000003E-QINU? Mississippi,?UNIQ4f238ebe6a8c71c3-nowiki-00000040-QINU?4?UNIQ4f238ebe6a8c71c3-nowiki-00000041-QINU??UNIQ4f238ebe6a8c71c3-nowiki-00000043-QINU?8?UNIQ4f238ebe6a8c71c3-nowiki-00000044-QINU? Arkansas,?UNIQ4f238ebe6a8c71c3-nowiki-00000046-QINU?9?UNIQ4f238ebe6a8c71c3-nowiki-00000047-QINU? and Tennessee.?UNIQ4f238ebe6a8c71c3-nowiki-00000049-QINU?10?UNIQ4f238ebe6a8c71c3-nowiki-0000004A-QINU?" HurricaneFan 25 13:16, 5 October 2011 (UTC)[reply]

Already reported; see #bug_in_.23tag:ref_parser_function. –Drilnoth (T/C) 13:17, 5 October 2011 (UTC)[reply]

See #bug in #tag:ref parser function above. ---— Gadget850 (Ed) ^talk 13:17, 5 October 2011 (UTC)[reply]

Yet another badly borked example of this: FMA IAe 33 Pulqui II#References. This needs to be fixed immediately, because members of the general public browsing Wikipedia are going to come across that, shake their heads, and go, "see? I knew Wikipedia was stupid." - The Bushranger _{One ping only} 19:45, 5 October 2011 (UTC)[reply]

We have plenty of examples now. If you check progress on the Bugzilla page, you will see the the issue has been characterized and is being worked on. When it is fixed, the sample I provided above will start working. ---— Gadget850 (Ed) ^talk 20:00, 5 October 2011 (UTC)[reply]

Fixed You may need to purge a page. Please update if you see more issues. ---— Gadget850 (Ed) ^talk 01:32, 6 October 2011 (UTC)[reply]

Had to add "?action=purge" to the URL, but after purging - hurrah, eet werked! Nice work devs. :) - The Bushranger _{One ping only} 01:58, 6 October 2011 (UTC)[reply]

Wikilinks in diffs no longer clickable

Resolved

– fixed

Extended content

Can't click on wikilinks in diffs (or, more usefully, get them to show in popups). A big time-waster. --NSH001 (talk) 10:13, 5 October 2011 (UTC)[reply]

That wasn't core functionality, that is a gadget which is currently broken as to my understanding. Peachey88 ^{(T · C)} 11:43, 5 October 2011 (UTC)[reply]

I think that should be reported on User_talk:Cacycle/wikEd. Helder 15:59, 5 October 2011 (UTC)[reply]

Improved diff view not working

This gadget is no longer working (preferences/gadgets/editing), at least in Monobook. Very annoying. --NSH001 (talk) 10:13, 5 October 2011 (UTC)[reply]

Likewise for me, in Vector (Firefox). There is more information about this problem at User talk:Cacycle/wikEd#Did the diff go away. --Tryptofish (talk) 19:19, 6 October 2011 (UTC)[reply]

Me too. Vector, IE9. →Dynamic|cimanyD← (contact me) 12:03, 7 October 2011 (UTC)[reply]

I fixed wikEdDiff. This change needs to be made. You guys can either wait for an admin or Cacycle to make the edit, or just import my version for now. wikEd is also broken, but I haven't looked at it because I don't use it, and it's probably a more complicated problem, anyway. Although it's also very likely going to be merely a problem with finding the right classes, because a lot of new classes and DIVs have been added in the latest MediaWiki update. Gary King (talk · scripts) 19:44, 7 October 2011 (UTC)[reply]

Additional possibly useful information on a fix is at User_talk:Cacycle/wikEdDiff#wikEdDiff broken with MediaWiki 1.18 update. I cried when this got broken; finding a changed period/full stop in WP's default diff view is nearly impossible. - Dank (push to talk) 15:32, 8 October 2011 (UTC)[reply]

What about using something like wikEd.diffTable = $( 'table' ).find( '.diff').get(0) instead of that loop? Helder 15:48, 8 October 2011 (UTC)[reply]

Gary's fix worked for me, thanks very much Gary! For people like me who are less than fluent with this kind of thing, the way to do it is to go to Gary's link, and select and copy just the part between "START INSTALLATION CODE" and "END INSTALLATION CODE". Then open either your monobook.js file or your vector.js file (depending on whether you use monobook or vector), and you can find these quickly by going to your own user contributions and clicking "subpages" at the bottom of the screen, then edit the file by pasting the material at the end. You might have to clear your browser cache for it to take effect, but I didn't have to, and as I said, it works fine. --Tryptofish (talk) 16:40, 8 October 2011 (UTC)[reply]

External link icon

Filed as Missing external link problem on IE6

Extended content

I know I mentioned this above already... and I'm really not as concerned about the return of the EL icon as I am the double space it's leaving before punctuation. This is bad form that I'll never get used to looking at. (see screen-cap at Image Shack). -- WikHead (talk) 10:42, 5 October 2011 (UTC)[reply]

The icon displays perfectly for me, in both Monobook and Vector, so I suspect the problem may be something other than the upgrade. --NSH001 (talk) 10:56, 5 October 2011 (UTC)[reply]

Try clearing your browser cache. That can help to refresh the style files. — This, that, and the other (talk) 11:16, 5 October 2011 (UTC)[reply]

My cache has been cleared several times, along with several [ctrl] + [F5] refresh(es) and reboots, and even well before I posted, but still no change with this at all. That routine was needed to resolve other issues I was having, but has done nothing to fix this one. -- WikHead (talk) 18:49, 5 October 2011 (UTC)[reply]

Browser and version? --brion (talk) 01:51, 6 October 2011 (UTC)[reply]

As a note, no problems with EL icons here. - The Bushranger _{One ping only} 01:59, 6 October 2011 (UTC)[reply]

If most everyone else can see the icon but I can't, and I'm being asked my browser-type, I can pretty much guess where the problem lies. I would assume that the icon may have been reworked, and some of us aren't able to deal with the latest PNG encoding. I had a similar problem with "no transparency" in the Wikipedia logo when it was updated, but its PNG encoding was altered and has worked fine ever since. I believe they described it as "64-bit compatibility for PNG". -- WikHead (talk) 03:00, 6 October 2011 (UTC)[reply]

Does this mean you are using IE6 ? Please try to be specific. it takes a lot of the back and forth questions out of the discussion, and results in less confusion and faster resolution of problems. —TheDJ (talk • contribs) 15:47, 6 October 2011 (UTC)[reply]

My apologies, as it was never my intent to confuse. Troubleshooting for this issue should indeed be based on "IE6". When I first reported this, I was under the impression that the icon had been entirely removed, lost, or simply forgotten about... as I see no indication that an image is even attempting to load into the empty space. I'm assuming at this point (after digging up the details of a previous image-related problem), that my specific issue may be in relation to having no PNG-24 support... and if so, it could be resolved if the icon image was saved as PNG-8. If I'm the only user on the project having this problem, feel free to simply dismiss it and close the thread. While the issue is an annoyance to "me" personally, I don't want it becomming an unnecessary annoyance to others. -- WikHead (talk) 23:16, 6 October 2011 (UTC)[reply]

Watchlist doesn't collapse

Resolved

Extended content

It says

Error: $that.attr("id") is undefined
Source File: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=MediaWiki:JQuery-makeCollapsible.js&action=raw&ctype=text/javascript
Line: 230

on Special:Watchlist, and for pages where there have been multiple edits, those do not collapse into a single line per page. Ucucha (talk) 11:26, 5 October 2011 (UTC)[reply]

(edit conflict) I was just about to say that enhanced recent changes isn't working for me either, on recent changes or my watchlist. Grouping works, not collapsing. →Dynamic|cimanyD← (contact me) 11:30, 5 October 2011 (UTC)[reply]

To clarify, this is in Firefox 6.0.2 on Vector. The error console gives the error I pasted above twice, plus the following one:

Error: uncaught exception: Syntax error, unrecognized expression: [href*=&days=7]

I haven't tried turning off other scripts yet. Ucucha (talk) 11:43, 5 October 2011 (UTC)[reply]

This seems to be fixed after our local copy of the jQuery plugin "makeCollapsible" was removed. Could you confirm if your Special:Watchlist is working again? (Remember to clear your cache) Helder 14:34, 5 October 2011 (UTC)[reply]

It is, thanks. Ucucha (talk) 16:02, 5 October 2011 (UTC)[reply]

Working! →Dynamic|cimanyD← (contact me) 23:13, 5 October 2011 (UTC)[reply]

Classic skin sidebar

Reported: Classic skin has extra spacing in IE8 — ☠MarkAHershberger☣ 17:12, 6 October 2011 (UTC)[reply]

Extended content

(e/c/) I don't know if it's due to 1.18, or someones been altering the css/js, but I'm getting two separator bars between "Contact Wikipedia" and "Edit this page" on the sidebar of Classic Skin, when looking at editable pages. Not a major issue, but it looks wrong.—An optimist on the run! 11:36, 5 October 2011 (UTC)[reply]

I'm seeing large gaps between the various sections, i.e. between Donate to Wikipedia and Search etc.... The Rambling Man (talk) 12:09, 5 October 2011 (UTC)[reply]

Can you provide a screenshot? Sumanah (talk) 22:41, 5 October 2011 (UTC)[reply]

I was seeing that too. I changed to the Vector skin, and it's OK now. Voceditenore (talk) 12:53, 5 October 2011 (UTC)[reply]

One shouldn't have to change to Vector for the sidebar to appear correctly. Some of us like MonoBook, and it's screwed up there as well. Deor (talk) 18:24, 5 October 2011 (UTC)[reply]

I have switched multiple times to both skins. I never see this problem. What browsers are the users using ? Perhaps it's something browser specific. —TheDJ (talk • contribs) 15:48, 6 October 2011 (UTC)[reply]

IE8 and Firefox 7 - I get the same problem in both.—An optimist on the run! 15:50, 6 October 2011 (UTC)[reply]

See this image, which also shows the problems caused by the category spacing.—An optimist on the run! 16:52, 6 October 2011 (UTC)[reply]

Collapsible navboxes

Resolved

– Looks fine to me now. DrKiernan (talk) 08:07, 6 October 2011 (UTC)[reply]

Extended content

Navboxes no longer collapse. DrKiernan (talk) 12:01, 5 October 2011 (UTC)[reply]

Works for me. Can you give some examples? --NSH001 (talk) 12:22, 5 October 2011 (UTC)[reply]

All the boxes at the bottom of Prince Philip, Duke of Edinburgh used to collapse. Now they are all fully expanded for me. DrKiernan (talk) 12:43, 5 October 2011 (UTC)[reply]

Ah, they work in Explorer but not Firefox. (I've just switched to Firefox because I can't edit in Explorer anymore.) DrKiernan (talk) 12:47, 5 October 2011 (UTC)[reply]

They are all expanded for me in IE8. Problems were also reported at WP:HD regarding Steve Bruce. - David Biddulph (talk) 12:50, 5 October 2011 (UTC)[reply]

Works for me (Firefox 7.0.1, Ubuntu Linux 11.04). Off topic, that article has way too many categories. Takes up a whole screen on my browser since the apparent font size change. –Drilnoth (T/C) 13:17, 5 October 2011 (UTC)[reply]

WFM too (Firefox 9.0a2 on Win7 x64). I agree that the change in the categories font is pretty annoying though. Should be changed back imho. Regards So Why 13:36, 5 October 2011 (UTC)[reply]

If you think that's too many categories, you should look at his wife's article. And there are even more categories which are hidden with <!-- code. DrKiernan (talk) 13:37, 5 October 2011 (UTC)[reply]

Should be fixed after this change —TheDJ (talk • contribs) 16:01, 5 October 2011 (UTC)[reply]

Nope, they still don't collapse for me. Interestingly the problem only occurs when I am logged in, also I ticked 'Exclude me from feature experiments' and then 'Don't show the Article feedback widget on pages'. Both times this solved the problem very briefly, but then it came back. Just this second I changed my skin, and refreshed and the problem was fixed. I refreshed again and the problem returned.--Echetus Xe 17:24, 5 October 2011 (UTC)[reply]

Navboxes seem to be collapsing normally for me. - The Bushranger _{One ping only} 23:22, 5 October 2011 (UTC)[reply]

They look OK to me now too. I shall tag this as resolved for now, but just remove the tag if others still have problems. DrKiernan (talk) 08:07, 6 October 2011 (UTC)[reply]

Yeah, looks to be fixed now.--Echetus Xe 08:57, 6 October 2011 (UTC)[reply]

The new Sorting breaks all tables arround Wikipedia which include two headers

Resolved

– fixed

The issue is that the new Sorting applying in the past few days breaks all tables arround Wikipedia which includes two headers once you sort one.

Exemples (there are many more but posted the ones I use to edit):

– HonorTheKing (talk) 12:00, 5 October 2011 (UTC)[reply]

Fixed in r99092. --Catrope (talk) 13:39, 6 October 2011 (UTC)[reply]

Extended content

I can't see any sortable tables on either of those articles (using IE8). - David Biddulph (talk) 12:17, 5 October 2011 (UTC)[reply]

And looking at the wikisource it says unsortable. Where are you finding something sortable? - David Biddulph (talk) 12:19, 5 October 2011 (UTC)[reply]

Both tables are sortable, (IE9, Chrome, Firefox) not sure why you can't see them. exept of Ref they both sort. they sort for me but they break and merge the headers.

In addition, if you press the wikilinked in the header it sort the table and not go to the pressed linked.

Exemple: If you press FA Cup it sort it but not direct to it. It used to direct while pressing the names, and only by pressing the up and down icons it sorted.
– HonorTheKing (talk) 12:32, 5 October 2011 (UTC)[reply]

The second table titled "List of Manchester United F.C. players with at least 100 appearances". In IE9 and FF7, clicking on a sort arrow creates a second header row with the Appearances title cell in the leftmost column followed by the other title cells. In IE9, when I clock on a sort arrow, it pushes the table below the images. ---— Gadget850 (Ed) ^talk 12:37, 5 October 2011 (UTC)[reply]

Looking again at the wikisource the one in List of Manchester United F.C. seasons does say sortable and one of the tables in List of Manchester United F.C. players does too, though others are unsortable. I don't know why they don't appear sortable for me. Perhaps it's connected with the new software? - David Biddulph (talk) 12:44, 5 October 2011 (UTC)[reply]

The sort buttons are still there, but are now smaller (and nicer, I think). As far as I can remember, though, sorting tables with more than one row of headers has always been dodgy, which is why, when I create a new sortable table, I restrict it to one row of headers. --NSH001 (talk) 12:53, 5 October 2011 (UTC)[reply]

They sorted well before. No issues or something like that. The few issues were fixed few weeks ago after improving all tables after FLC talk for ACCESS. In past and now aswell, the two headers always included the sorting icons in the first header while the second didn't have one, but it was able to sort.

The Russian Wikipedia uses the same table format and as it uses the old Wikipedia Version you can see how it works there. Russian Page for ManUtd players
– HonorTheKing (talk) 12:59, 5 October 2011 (UTC)[reply]

Also see List of India women ODI cricketers. Has the sort problem, hidden sort arrows and also the "unsortable rows" bit doesn't work -- it sends the unsortables to the top. —SpacemanSpiff 13:39, 5 October 2011 (UTC)[reply]

If the sort buttons are there but smaller, for me they are so small as to be invisible and so as to be ineffective. I still cannot sort those tables. The Russian one will sort, the English version won't. - David Biddulph (talk) 14:51, 5 October 2011 (UTC)[reply]

The fact that this (multispan headers with sorting) worked before, was a side effect of the sortable script, not being able to properly handle rowcolspans. As such the fact that it worked like this a few weeks ago, is by all intents and purposes an accident. Now colspan and rowspan functionality actually works (one of the most longstanding requests in bugzilla in think). Now this breaks. I say, file as a bugreport, and when someone has a lot of time to spare, they can dive into the tablesorter code :D —TheDJ (talk • contribs) 15:58, 5 October 2011 (UTC)[reply]

I have similar problem with sorting on 2010–11 HNK Hajduk Split season. Using Firefox 7.0.1., it breaks Appearances and goals table when trying to sort it and the table "freezes". Previously, I could sort by number, position, player name and total appearances. Now those sort arrows are gone and only sort arrows are that under apps and goals. While in IE8 and Opera 11.51, sort arrows aren't visible at all. Dr. Vicodine (talk) 18:50, 5 October 2011 (UTC)[reply]

Looks like this is fixed, but will probably require purging the page. Lets get some feedback on this. ---— Gadget850 (Ed) ^talk 01:54, 6 October 2011 (UTC)[reply]

Iv'e purged the page and cleaned my browser and the sorting problem still there. Only thing fixed is that now you can click the wikilinked in the header as it fixed few bellow.
– HonorTheKing (talk) 08:45, 6 October 2011 (UTC)[reply]

The problem with the wikilinks is solved yes, the other issue is bugzilla:31420. —TheDJ (talk • contribs) 09:19, 6 October 2011 (UTC)[reply]

Related: No sort arrows

There are no sorting arrow buttons in at least some lists, including List of songs in Green Day: Rock Band and List of Rock Band Network songs, although the text is indented as though they were present, and clicking anywhere in the header sorts the table. –Drilnoth (T/C) 13:11, 5 October 2011 (UTC)[reply]

that is caused by the background on the title cells. I don't know if this worked before. ---— Gadget850 (Ed) ^talk 13:16, 5 October 2011 (UTC)[reply]

It certainly did. –Drilnoth (T/C) 13:24, 5 October 2011 (UTC)[reply]

I'm using IE8, and clicking anywhere in the header does not sort the table for me. - David Biddulph (talk) 14:46, 5 October 2011 (UTC)[reply]

bugzilla:31196. —TheDJ (talk • contribs) 15:46, 5 October 2011 (UTC)[reply]

Fix deployed. --Catrope (talk) 13:39, 6 October 2011 (UTC)[reply]

Still not seeing any icons. Yes, I purged my cache. –Drilnoth (T/C) 14:53, 6 October 2011 (UTC)[reply]

Same here. No sort arrows, so not resolved. - David Biddulph (talk) 15:00, 6 October 2011 (UTC)[reply]

It said eleviated... Problem still exists if people set the individual tablecell background (instead of the background-color). I'm not sure what to do with that... perhaps we should !important the sort elements.... I generally dislike that approach, but here it might be required.... —TheDJ (talk • contribs) 15:54, 6 October 2011 (UTC)[reply]

Ah, background-color instead of background. That is manageable, at least, but I don't like it. Why, exactly, did the dev team decide to make such a breaking change in the first place? –Drilnoth (T/C) 15:59, 6 October 2011 (UTC)[reply]

We wanted a tablesorter that had actually working sorting. Something we could build from and was more efficient than the old code and wouldn't require all those sort templates that are now required for almost every tablecell. So we switched the entire implementation around to the http://tablesorter.com implementation. That came with a bit different layout and some other details, that most people didn't even notice (like it uses the shift key to do multi column sortkey sorting). —TheDJ (talk • contribs) 10:44, 8 October 2011 (UTC)[reply]

Solved with rev:99307. Still needs to be deployed. —TheDJ (talk • contribs) 13:02, 8 October 2011 (UTC)[reply]

We need to get some help page updates on this. ---— Gadget850 (Ed) ^talk 13:15, 8 October 2011 (UTC)[reply]

Namespace option on contribution history

Resolved

– fixed

I'll be short. My User contributions is normal and functional otherwise, but it's missing the droplist for Search by namespace. It works normally in all other wikipedias and Commons too, but not here. I want it back :( Pitke (talk) 06:35, 5 October 2011 (UTC)[reply]

This function was removed at the request of Domas, one of the developers. No-one knows what his reason for requesting this change was. Apparently, "if we don't hear from him [Domas] by the end of this week, then I'll suggest that the change be backed out." See mediazilla:31197. — This, that, and the other (talk) 06:43, 5 October 2011 (UTC)[reply]

Change has been reverted, see Bugzilla. --Catrope (talk) 13:52, 6 October 2011 (UTC)[reply]

Extended content

I want it back as well. I often used that feature. -- Alan Liefting (talk) - 07:42, 5 October 2011 (UTC)[reply]

I also use the function, though if there were a very good reason for removing it I suppose I could live without it. Will Beback talk 07:54, 5 October 2011 (UTC)[reply]

Yes, let's have that back. –xeno^talk 12:38, 5 October 2011 (UTC)[reply]

Agreed - I want the feature back. I use it to track my deletion discussions where I don't want to add them to my watchlist. SchuminWeb (Talk) 03:43, 6 October 2011 (UTC)[reply]

The entries in my Watchlist are now all expanded rather than being collapsed. Would this be a related issue? -- Alan Liefting (talk) - 07:50, 5 October 2011 (UTC)[reply]

Not really related. See this other section. It seems this edit fixed it. Helder 15:23, 5 October 2011 (UTC)[reply]

For me, the contribs dropdown menu for search by namespace is gone both here and on Wikimedia Commons. – Athaenara ✉ 07:58, 5 October 2011 (UTC)[reply]

I have both of those probs

Sp33dyphil ^{"Ad astra"} 08:43, 5 October 2011 (UTC)[reply]

I also hope the namespace option here can be returned; I found it very useful in keeping tracking of discussions outside of articlespace. Hullaballoo Wolfowitz (talk) 16:36, 5 October 2011 (UTC)[reply]

This is an extremely useful feature; I hope it is restored soon. For one thing, my bot does a lot of logging to a subpage in userspace and it is very handy to filter those contributions out and just view the articlespace changes it's made. 28bytes (talk) 17:39, 5 October 2011 (UTC)[reply]

It appears to have been removed intentionally. :( –Drilnoth (T/C) 18:00, 5 October 2011 (UTC)[reply]

Then it should be restored as an option. It's not just useful, it's necessary. - The Bushranger _{One ping only} 19:30, 5 October 2011 (UTC)[reply]

Agreed, it should be restored. --NSH001 (talk) 21:57, 5 October 2011 (UTC)[reply]

A very useful filtering option; should be restored. . . Mean as custard (talk) 07:53, 6 October 2011 (UTC)[reply]

There used to be (12 hours ago or so) a "Namespace" option on the contributions history pages. Did it disappear for everyone? I've tried switching my interface language back to English from Dutch, and my skin from Monobook back to Vector, and it stays gone.—Kww(talk) 11:34, 5 October 2011 (UTC)[reply]

Gone for me, missed your while I was writing mine below.--Crossmr (talk) 11:42, 5 October 2011 (UTC)[reply]

Did I miss a memo? When did this happen? I was just checking out contribs and I can no longer select a drop-box to filter by name space (article/talk/wikipedia/etc). This was insanely useful. Why was this removed?--Crossmr (talk) 11:42, 5 October 2011 (UTC)[reply]

Confirmed. This did work yesterday. ---— Gadget850 (Ed) ^talk 11:58, 5 October 2011 (UTC)[reply]

I want it back - as Bushranger says, it is necessary. I would also like an option "only show edits that are not latest revisions" - I use my own contribution history as a sort of watch list and this option would help greatly. But I will file a separate Bugzilla request for it. — [[::User:RHaworth|RHaworth]] (talk · contribs) 02:05, 6 October 2011 (UTC)[reply]

The "show only edits that are not latest" option is available now with my HideTopContrib script. Mark Hurd (talk) 11:13, 6 October 2011 (UTC)[reply]

I agree. It's necessary to deal with certain types of vandals. (See WP:BEANS for details.) — Arthur Rubin (talk) 02:19, 6 October 2011 (UTC)[reply]

Definitely agree that we need this feature. I even find it useful when looking at my own contributions, e.g. when I'm trying to find the most recent time that I participated in AFD. Nyttend (talk) 03:36, 6 October 2011 (UTC)[reply]

I definitely want it back. Unless, as Will Beback said above, a good reason is given for its removal, it should be restored. Those of us who contribute in multiple namespaces find it not only useful, but necessary. ---RepublicanJacobite_TheFortyFive 03:41, 6 October 2011 (UTC)[reply]

Adding to the pile-on. This is a VERY useful feature for me, especially dealing with certain types of vandalism. I would like to see it back. Trusilver 03:44, 6 October 2011 (UTC)[reply]

Totally agreeing with everyone. It's useful for checking contributions, especially vandals'. One reason my own MediaWiki installations will stay on 1.17 for now.Jasper Deng (talk) 03:47, 6 October 2011 (UTC)[reply]

According to this comment on the bug, the feature was not removed from MediaWiki, but merely disabled for very large wikis like this one. jcgoble3 (talk) 04:21, 6 October 2011 (UTC)[reply]

I also agree, good for finding copyvios as well Secret ^account 03:53, 6 October 2011 (UTC)[reply]

Lets have it back, please. JORGENEV 04:09, 6 October 2011 (UTC)[reply]

I absolutely need this functionality to do my job here. Why was it removed without discussion? When can it be restored? --John (talk) 04:10, 6 October 2011 (UTC)[reply]

I twenty-third the call for restoration. I used that feature nearly every day.--Fuhghettaboutit (talk) 04:15, 6 October 2011 (UTC)[reply]

Twenty-fourthed - ditto. JohnCD (talk) 09:39, 6 October 2011 (UTC)[reply]

I can't believe that someone has removed this feature. It's something I use nearly every day, especially if I want to remember what talk pages I've been posting on (even if they are not on my watchlist, which is too big anyway), this has got to be restored to working order as soon as possible. --Hibernian (talk) 04:39, 6 October 2011 (UTC)[reply]

Agreed with all, we need the namespace option back. Whose idea was it to remove it? --

Bryce Wilson | talk

05:06, 6 October 2011 (UTC)[reply]

I'd like this functionality back as well. It is also useful to be able to see related changes and watchlists and other reports filtered by namespace. An incredibly useful feature. Why it was removed with no explanation or warning is worrying. It makes me feel that the Wikimedia software used on Wikipedia is that little bit more unstable and less reliable, and makes me wonder what else could just be removed like this. Carcharoth (talk) 05:12, 6 October 2011 (UTC)[reply]

Just one more voice with the same request--this is necessary. Just to give another rationale why, a complaint has just been raised on ANI about a problematic user, and I need to know if the user has ever discussed the problems on user or article talk pages (i.e., are they completely uncommunicative, or just generally so), in order to advise how to move forward (because completely uncommunicative in the face of complaints is highly block worthy, while the latter may indicate other approaches). Searching through all of the communications by hand is much more time consuming and harder to get the "big" picture. Qwyrxian (talk) 05:15, 6 October 2011 (UTC)[reply]

Namespace back, needed.--Musamies (talk) 05:25, 6 October 2011 (UTC)[reply]

In favor of restoring the namespace filtering feature if at all possible. Sorry for joining late. --Lexein (talk) 10:38, 6 October 2011 (UTC)[reply]

WP:SNOW close this already and turn the feature back on. It's obvious that there is consensus to restore the feature, without a single !vote in opposition to turning the feature back on. Now let's close this discussion already and re-enable the feature. This is seriously getting in the way of accomplishing real work on this encyclopedia of ours. SchuminWeb (Talk) 06:10, 6 October 2011 (UTC)[reply]

Domas requested that this be removed because the implementation of namespace searching was such that it could create queries (either accidentally or maliciously) that would tie up database server resources for minutes at a time, and that represents an unacceptably large burden. Now it is also true that most queries created by namespace filtering do not take very long. Obviously many people want functionality like this, and the developers have been listening. More likely than not there will eventually be a restored filter with some new limitations to address the cases that can create a large server burden. For example, a filter might be limited to only consider a user's 5000 most recent contributions, or something like that. The exact form of what limits might be imposed are still being discussed and depend heavily on technical considerations about what can be implemented efficiently. Dragons flight (talk) 06:17, 6 October 2011 (UTC)[reply]

So Domas fixed bug by disabling feature? Congratulations. I suggest to disable editing on all wikimedia projects - it will allow to close many bugs on bugzilla. Bulwersator (talk) 08:01, 6 October 2011 (UTC)[reply]
- Surprisingly not all "bugs"/issues can't be magically fixed like you seem to think they can, making "trollish" remarks like "lets just disable editing although" don't help anything. Peachey88 ^{(T · C)} 08:27, 6 October 2011 (UTC)[reply]

Who would want to be looking up 5,000 edits every day? I think most people only wish to look for the last hundred at the most. --Hibernian (talk) 08:53, 6 October 2011 (UTC)[reply]

As I understand it, the problem with the current implementation is it searches back through, say 5000 edits, to find 20 in the namespace you've chosen. As I understand it there isn't an index on namespace, or at least not a usable one. (BTW I want the feature back too.) Mark Hurd (talk) 10:32, 6 October 2011 (UTC)[reply]

Though I would like the feature back, I'd prefer the servers not crash or slow to a crawl every time I do something unexpected. I'm sure the developers can figure out something reasonable. WLU (t) (c) Wikipedia's rules:^simple/_complex 11:01, 6 October 2011 (UTC)[reply]

It's completely inacceptable that this feature was modified. As an German wikinews admin I can say that I did not use the feature because of making fun (like other things e.g. delivering cat images on user talk pages) but because of I needed to do so, especially for fighting vandalism, what especially in small projects with only a small number of admins which cannot keep up with the recent changes all day but will to browse thorugh a large number of recent edits once a day or maybe only twice a week. No good idea, what was done. --Matthiasb (talk) 12:33, 6 October 2011 (UTC)[reply]

If the only reason it was disabled was because "it can be slow", it should be immediately turned back on - we do not kill the patient to cure the disease. I think it's safe to assume that users who use the feature by-and-large realize that it is expensive, and understand the delay. If it's affecting site-wide performance, then that is a little more understandable but would like it if we could explore ways to provide this feature to users by way of a usergroup or by limiting the number of revisions one can ask for at one time (whenever I use the feature, I set this fairly low so the query does not take too long). –xeno^talk 13:22, 6 October 2011 (UTC)[reply]

Ridiculous. If the idea is to make it impossible to locate diffs, accomplished. This won't work. SandyGeorgia (Talk) 13:31, 6 October 2011 (UTC)[reply]

Some JS tools broken

A couple javascript tools (User:Dr pda/prosesize.js, User:Dr pda/prosesizebytes.js, User:Shubinator/DYKcheck.js) are no longer working on Firefox. rʨanaɢ (talk) 13:04, 5 October 2011 (UTC)[reply]

These three should now be working properly... Shubinator (talk) 03:32, 6 October 2011 (UTC)[reply]

Okay, Twinkle is down for me. No little 'TW' in the corner; just tried to revert an edit using Twinkle but the usual [ROLLBACK (AGF)] [ROLLBACK] [ROLLBACK (VANDAL)] buttons didn't appear. HurricaneFan 25 11:56, 5 October 2011 (UTC)[reply]

Same issue here. –Drilnoth (T/C) 13:15, 5 October 2011 (UTC)[reply]

Same here. For Twinkle, see WT:TW#No Twinkle at all?. Regards So Why 13:56, 5 October 2011 (UTC)[reply]

Ditto. Only found out when went to give an IP a vandal warning. The drop down just doesn't appear. (Firefox) Haruth (talk) 18:46, 5 October 2011 (UTC)[reply]

Fixed now. (Thanks you back room guys, wherever you are... ;-)) Haruth (talk) 12:40, 6 October 2011 (UTC)[reply]

It's been working all along for me, for the record. (Firefox 5.0, Monobook). - The Bushranger _{One ping only} 02:00, 6 October 2011 (UTC)[reply]

I'm using Firefox 7.0.1 with the Vector skin. I've already completely cleared the cache and restarted the browser. The Appearance Gadget "Add an [edit] link for the lead section of a page" is not working. (I wasn't sure if this could go under the earlier "Some JS tools broken" section, if that applies to Gadgets.) Thanks, -- Gyrofrog (talk) 17:55, 5 October 2011 (UTC)[reply]

Gadgets are JS tools. –Drilnoth (T/C) 17:56, 5 October 2011 (UTC)[reply]

OK, that explains it. Same deal with the Gadget "Moves edit links next to the section headers". -- Gyrofrog (talk) 17:59, 5 October 2011 (UTC)[reply]

I'm not having an issue with that one. Firefox 7.01, Ubuntu 11.04, 64-bit. –Drilnoth (T/C) 18:01, 5 October 2011 (UTC)[reply]

Apparently it's intermittent. I was about to reply that it just started working again (but I got an edit conflict). Now it's not working. -- Gyrofrog (talk) 18:04, 5 October 2011 (UTC)[reply]

When displaying an article which has a speedy tag on it, the "Speedy" tab, probably provided by the CSDHelper script User:Ale_jrb/Scripts/csdhelper.js, which used to appear to the right of the "Discussion" tab, now appears below it, obscuring the article title. (Vector, Firefox 7.0.1) JohnCD (talk) 18:00, 5 October 2011 (UTC)[reply]

When I wrote the above, I hadn't actually tried to use CSDHelper. On trying to delete a page with it, I got a message: "Forbidden You don't have permission to access /w/ on this server" - but the page was actually deleted. JohnCD (talk) 22:04, 5 October 2011 (UTC)[reply]

The "admin dashboard" tab provided by User:Plastikspork/admindash.js no longer appears on "My contributions" page, though it is still there on "My talk" and "My watchlist" (Vector, Firefox 7.0.1) JohnCD (talk) 18:00, 5 October 2011 (UTC)[reply]

This one has been fixed. JohnCD (talk) 22:26, 7 October 2011 (UTC)[reply]

I don't fully understand all this stuff, and didn't want to create yet another subsection unless necessary. Would User:Pyrospirit/metadata not working belong in this section? —WFC— 21:55, 5 October 2011 (UTC)[reply]

Works for me Gary King (talk · scripts) 17:14, 8 October 2011 (UTC)[reply]

User:MarkS/extraeditbuttons.js doesn't seem to work anymore and unfortunate the author is fairly inactive. Any javascript wizards available to take a look? –xeno^talk 13:18, 6 October 2011 (UTC)[reply]

Same problem on ptwiki. The Portuguese version of the script was updated recently on Portuguese Wikipedia, but there are some unresolved issues (see bugzilla:31511). Helder 01:00, 8 October 2011 (UTC)[reply]

User:Ais523/watchlistnotifier.js is no longer working.--Dudemanfellabra (talk) 22:22, 7 October 2011 (UTC)[reply]

bugzilla:31526 —TheDJ (talk • contribs) 12:40, 8 October 2011 (UTC)[reply]

So does that mean the script needs to be modified, or is a fix being worked on? I'm not an expert at bugzilla.--Dudemanfellabra (talk) 22:04, 8 October 2011 (UTC)[reply]

Buttons in editing bar don't work

Resolved

– fixed

Extended content

Since yesterday, every page loads with an error message at the bottom of my browser (IE7). The error seems to manifest itself in the editing bar, e.g. etc. None of the buttons in the bar work when you click on them. Voceditenore (talk) 13:13, 5 October 2011 (UTC)[reply]

Works for me (Firefox 9.0a/Win7x64). Did you try force-reloading? Regards So Why 13:41, 5 October 2011 (UTC)[reply]

Yep, I tried it. Makes no difference. :( Voceditenore (talk) 13:55, 5 October 2011 (UTC)[reply]

I just started my VM with WinXP/IE7 and I confirm this in that browser. It also doesn't work in IE8 on Win7x64. JS compatibility library is on. Works fine in Firefox and Chrome. Regards So Why 14:10, 5 October 2011 (UTC)[reply]

I'm totally non-techno-savvy. :) What does "JS compatibility library is on" mean? Does it mean someone is working in this? I hope so because it's real pain. Voceditenore (talk) 16:50, 5 October 2011 (UTC)[reply]

There is an option in Special:Preferences under "Gadgets" called "The JavaScript Standard Library" which is designed for browsers that do not support Javascript 1.6 (like Internet Explorer 7). If you insist on using such an outdated browser, you should turn this on to ensure compatibility in your browser. That said, the library does not solve this problem though. Regards So Why 17:05, 5 October 2011 (UTC)[reply]

Fixed in r99097. It was a stray comma, no less ^^ . --Catrope (talk) 13:36, 6 October 2011 (UTC)[reply]

I'm still having this problem. I have cleared my cache and restarted the program since the announcement that it was resolved was made, but to no avail. LadyofShalott 23:41, 8 October 2011 (UTC)[reply]

Editing "insert" box not showing

In Vector. The box with special symbols, emdashes, signatures, foreign characters, etc. isn't showing for me. –Drilnoth (T/C) 13:19, 5 October 2011 (UTC)[reply]

It is now showing the "Copy-paste" (non-JavaScript) box. Better, but still not right. –Drilnoth (T/C) 16:08, 5 October 2011 (UTC)[reply]

It is working fine for me on this page (e.g.: –≠√§) using Google Chrome 14.0.835.186 and vector skin. What browser/skin are you using? Helder 16:34, 5 October 2011 (UTC)[reply]

It is now working for me. Vector, Firefox 7.01, Ubuntu Linux 11.04, 64-bit. –Drilnoth (T/C) 13:08, 6 October 2011 (UTC)[reply]

"m" and "b" edit indicators aren't bold

Makes them much harder to notice. –Drilnoth (T/C) 13:19, 5 October 2011 (UTC)[reply]

Resolved

– fixed

Extended content

You can use this in your skin.css (e.g. Special:Mypage/vector.css) or Special:Mypage/common.css (to have it in all skins) to regain that feature for you:

/* Re-bold-en minor and bot edits in contributions, history, recent changes */
abbr.minoredit, abbr.botedit {
  font-weight: bold;
}

Regards So Why 13:53, 5 October 2011 (UTC)[reply]

Was this a purposeful change? Seems counter-intuitive to me. ♫ Melodia Chaconne ♫ (talk) 14:02, 5 October 2011 (UTC)[reply]

Ditto. —{|Retro00064|☎talk|✍contribs|} 22:26, 5 October 2011 (UTC)[reply]

Thanks for this. I also added it to my vector.css and it works fine. Toshio Yamaguchi (talk) 14:03, 5 October 2011 (UTC)[reply]

Many thanks. Put it in common.css and my MonoBook is now bolded! :) - The Bushranger _{One ping only} 19:31, 5 October 2011 (UTC)[reply]

Yup, adding that code to monobook.css fixed it for me also. Thanks! :-) —{|Retro00064|☎talk|✍contribs|} 22:24, 5 October 2011 (UTC)[reply]

This seems to be coming and going on a regular basis. I can no longer find the relevant CSS in trunk. How about putting it in common.css? — Edokter (talk) — 14:42, 5 October 2011 (UTC)[reply]

Fixed now, see r99089. --Catrope (talk) 13:34, 6 October 2011 (UTC)[reply]

Links are underlined where they shouldn't be

The links to my user page, talk, and all of the links in the tabs ("edit this page", "history", etc.) are now underlined; they weren't previously. I'm using monobook skin.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 13:22 (UTC)

Using monobook as well but I don't experience this. Have you tried force-reloading? Regards So Why 13:54, 5 October 2011 (UTC)[reply]

Happens for as well as I mentioned above (also on monobook). It's not a cache issue. ♫ Melodia Chaconne ♫ (talk) 14:01, 5 October 2011 (UTC)[reply]

I've experienced this on two different computers today (Opera/Win7 and Firefox/WinXP). SoWhy, what browser are you using? Also, the option to underline links is turned on for me—before the rollout everything was underlined as it was supposed to with the exception of the links in the tabs and in the upper right corner (which was fine, too).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 14:38 (UTC)

I'm using Firefox 9.0a2 but I loaded Wikipedia in IE7/WinXP, IE8/Win7 and Chrome/Win7 today and I did not experience this is any of them. Where have you enabled underlining of links? Regards So Why 15:38, 5 October 2011 (UTC)[reply]

In a drop-down box in "My Preferences" under "Appearance"→"Advanced options".—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 15:49 (UTC)

I see. That said, the change makes sense. If you select links to be underlined, you usually expect all of them to be underlined, so I'm guessing this is not a bug but a fix. You can probably change it back by using Special:Mypage/monobook.css but you probably have to manually add every CSS id in the file (e.g. #ca-nstab-user { text-decoration: none !important; }). Regards So Why 16:32, 5 October 2011 (UTC)[reply]

Thanks for the suggestion. If it's indeed a fix and not a bug, I'll "re-fix" it in my monobook.css in a few days. It's a bit annoying, but nothing to cry about. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 17:29 (UTC)

SoWhy, is there an easier way of doing this? I'm using Vector, btw... Jared Preston (talk) 23:27, 5 October 2011 (UTC)[reply]

Categories are surrounded by much more space, and they don't wrap from line to line

See Prince Philip, Duke of Edinburgh for an example of how this results in categories taking up much more space than they should. There may have been desire to allow a little more space between categories, but I doubt this much extra space was intended. --Metropolitan90 (talk) 13:44, 5 October 2011 (UTC)[reply]

Yes, I noticed this too. Also in my watchlist minor/bot edits have got that annoying .... line underneath them, and I recall that being switched off. Who fucked up and when is it going to be fixed? Lugnuts (talk) 14:55, 5 October 2011 (UTC)[reply]

The dotted underlines have always been there. — Edokter (talk) — 14:57, 5 October 2011 (UTC)[reply]

In Vector maybe, but not in Monobook. These weren't dotted-underlined until today. --Redrose64 (talk) 15:43, 5 October 2011 (UTC)[reply]

The extra space around the categories is caused by the vertical line between them. This used to be a pipe character, but is now something created in CSS. The relevant tags are <div id='catlinks' class='catlinks'>, <div id="mw-normal-catlinks"> and <div id="mw-hidden-catlinks" class="mw-hidden-cats-user-shown"> but I have no idea which CSS file sets up these ids and classes. --Redrose64 (talk) 16:04, 5 October 2011 (UTC)[reply]

Having the links not wrap looks useful, we do that manually in navboxes all the time. However, the gobs of extra spacing is useless, I also think it needs to be toned down, maybe not to how it was before but certainly somewhat. --Joy [shallot] (talk) 17:50, 5 October 2011 (UTC)[reply]

From http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&* I'm getting #catlinks li { [...] line-height: 1.35em; [...] }. It should simply be 1em. --Joy [shallot] (talk) 18:15, 5 October 2011 (UTC)[reply]

I totally concur that the categories having the extra space is a problem. The not-wrapping is a Good Thing, but the extra space...especially in Monobook...er...well...I'll just point everyone to the category table at the bottom of AIM-120 AMRAAM as Exhibit A as to why the extra spacing is Not Of The Good. o.o - The Bushranger _{One ping only} 19:33, 5 October 2011 (UTC)[reply]

The space itself is not as bad as the | character appearing from line 2 onward. It didn't show there before, or did it? NVO (talk) 11:46, 6 October 2011 (UTC)[reply]

It was there before, but the text didn't wrap the same way so you didn't notice it. If we're going to be using this {{nowraplinks}}-like style for categories, we might as well make the separator work like {{middot}}. --Joy [shallot] (talk) 12:50, 6 October 2011 (UTC)[reply]

CSS code for users' monobook.css/vector.css/common.css is listed (and works) at de:Wikipedia:Fragen_zur_Wikipedia#MW118:_Kategorienanzeige. Although I am tempted to suggest that this CSS code should be for everyone by default - especially in monoboook. Cheers --Saibo (Δ) 00:44, 7 October 2011 (UTC)[reply]

For those who don't speak German, try adding this to either Special:MyPage/common.css or Special:MyPage/skin.css:

/* Reduce space around category links, allow word wrapping - see [[:de:Wikipedia:Fragen zur Wikipedia#MW118: Kategorienanzeige]] */
#catlinks li {
        display: inline;
        border-left: none;
        padding: 0;
}
#catlinks li:first-child { padding-left: 0; }
#catlinks li:before { content: " | "; }
#catlinks li:first-child:before { content: ""; }

--Redrose64 (talk) 11:33, 7 October 2011 (UTC)[reply]

Thanks for the code. I'm agreeing with Saibo though, can we put this in Mediawiki:Common.css? Regards So Why 11:51, 7 October 2011 (UTC)[reply]

Hurrah, thank you! - The Bushranger _{One ping only} 15:25, 7 October 2011 (UTC)[reply]

The :before pseudo-element is not supported by IE6 and IE7, which still account for about 11% of traffic. ---— Gadget850 (Ed) ^talk 11:49, 8 October 2011 (UTC)[reply]

Another code option by de:Benutzer:✓ (style: somthing between the current and the code mentioned above):

#catlinks li { padding:0 .3em; border-color:black; } #catlinks li:first-child { padding-left:0; }

Maybe it even should be a bug report. ;) At least for Monobook (my favorite skin) the big spacing is not fitting to the rest of the skin... Cheers --Saibo (Δ) 14:15, 8 October 2011 (UTC)[reply]

Suggestions in search box have "seperator" entry

Reported: Bugzilla:31429

Extended content

See this screenshot. Regards So Why 14:00, 5 October 2011 (UTC)[reply]

What browser & browser version? --brion (talk) 01:46, 6 October 2011 (UTC)[reply]

Firefox 9.0a2 / Win7x64. It might be browser-related though since it appears between the auto-fill suggestions by the browser and the ones by the script (see this screenshot). Also, I cannot reproduce this with Firefox 7.0.1. Regards So Why 13:20, 6 October 2011 (UTC)[reply]

Article Feedback tool

Reported at Bugzilla:31543 — ☠MarkAHershberger☢(talk)☣ 22:07, 8 October 2011 (UTC)[reply]

Extended content

IE9 in compatibility view mode:

Text "I am highly knowledgeable about this topic (optional)" does not show; after checking the box, other checkboxes show without accompanying text
Submit rating button is blank

---— Gadget850 (Ed) ^talk 14:04, 5 October 2011 (UTC)[reply]

As advised, copied from http://en.wikipedia.org/wiki/Wikipedia:Help_desk#Ratings_panel_problems. Using IE 8 with Win XP:

Hi, recently the ratings panel at the bottom of articles has been broken for me. I used to be able to see the current rating averages (via a "display ratings" link or something ... don't remember precisely what it was called). Now that has gone, there is a cryptic green arrow and blue box whose purposes are completely unclear, and when I assign a rating some unlabelled checkboxes and an email address, again all of unknown purpose, also appear. Basically it's all in a very broken-looking state, as if someone's currently in the middle of playing around with coding some new features but hasn't yet finished. 86.179.0.153 (talk) 02:43, 8 October 2011 (UTC) — Preceding unsigned comment added by 86.177.104.186 (talk)

Monobook skin loses format on 3rd display

Resolved

Extended content

I am using the monobook skin (which is remembered from Special:Preferences settings). However, after displaying 2 pages, the 3rd page (such as edit-preview) loses the format and shows the page in list format (with menu items listed down the page under the edit-box). At that point, the screen format is corrupted and the Main-page hyperlink area extends into the edit-box and clicks to the main-page when trying to click on text in the edit-window. This is, by far, the worst corruption of the English Wikipedia since the dawn of time. It is a good time to talk about stopping future updates to Wikipedia: it can no longer function when updating to MediaWiki 1.18 or such. It is time to question whether trivial improvements in other areas are worth utterly destroying the edit-window for experienced users. I think it is not: it is high time to place an announcement:

Upgrading to MW 1.18x, Wikipedia will be basically unusable this week

I wish there was an alternate, stable Wikipedia which could edit the same files, to allow users to make progress despite all the useless updates to the MediaWiki software. Sometimes, pages can be copied to Simple Wikipedia for edit-preview, then copied back after the edit-changes have been tested. However, recently all other-language Wikipedias seem to get update-corrupted within days of each other. WP has become too complex to be updated without breaking for thousands of users. -Wikid77 (talk) 15:22, 5 October 2011 (UTC)[reply]

This was caused by an oversight where someone forgot to disable three lines of code that made ResourceLoader slow (a lesson we learned during the 1.17 deployment but was somehow missed for 1.18), should be fixed now. --Catrope (talk) 17:35, 5 October 2011 (UTC)[reply]

"Minor" checkbox is missing on new pages

When a new page is being created, there is no longer the "this is a minor edit" checkbox; only the "watch this page" checkbox.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 15:07 (UTC)

I would guess this is by design. Making a new page is not really a minor action. Update: I could be wrong though, see bugzilla:5754 –xeno^talk 15:11, 5 October 2011 (UTC)[reply]

True, normally it's not a minor action, but I use it all the time when creating redirects.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 5, 2011; 15:16 (UTC)

It is indeed by design. The bug you linked to is very old (2006). I can't find the latest bug report though. — Edokter (talk) — 15:44, 5 October 2011 (UTC)[reply]

It's also missing when creating a new section. Regards So Why 17:12, 5 October 2011 (UTC)[reply]

I see the This is a minor edit checkbox. FF7. ---— Gadget850 (Ed) ^talk 18:54, 5 October 2011 (UTC)[reply]

Suggestion: if a new page is created, have the system automatically tag it as a Minor Edit if the only content in the new page is #REDIRECT [[Foo Bar]]. That aside, I agree completely with this change, no hitting 'minor' when creating a new page or section, which isn't (redirects aside). - The Bushranger _{One ping only} 02:02, 6 October 2011 (UTC)[reply]

Special:Blocklist

http://en.wikipedia.org/wiki/Special:BlockList?wpTarget=%233617969 should show (in this case) the autoblock information; I don't see any way to lift an autoblock any more. --jpgordon^{::==( o )} 15:19, 5 October 2011 (UTC)[reply]

I believe you can still do it via the Unblock form. I have a fix for the BlockList in SVN. Aaron Schulz 03:48, 6 October 2011 (UTC)[reply]

Left sidebar excessively spaced out

Resolved

– duplicate of #Classic skin sidebar

Extended content

Using Monobook on a WinXP computer and IE7, the different sections in the left sidebar are significantly distant from each other (5.5 cm, roughly). This is artificially increasing the length of smaller pages and taking the "interaction" and "toolbox" sections below the fold. Risker (talk) 15:22, 5 October 2011 (UTC)[reply]

You probably need to clear your browser cache. —TheDJ (talk • contribs) 16:07, 5 October 2011 (UTC)[reply]

Did it before posting here, did it again before responding. No change. Risker (talk) 16:26, 5 October 2011 (UTC)[reply]

Have you tried disabling your gadgets and blanking Special:MyPage/monobook.js ? —TheDJ (talk • contribs) 16:43, 5 October 2011 (UTC)[reply]

Turned off all my gadgets, blanked my .js, logged out, cleared my caches, logged back in and .... no change. (I do appreciate the suggestions.) Risker (talk) 17:02, 5 October 2011 (UTC)[reply]

Have the same problem with IE 8. --Túrelio (talk) 06:37, 6 October 2011 (UTC)[reply]

All Preferences not visible

I'm signed in, but my visuals look as though I'm not. What I have selected in my Preferences are not showing, including the Tabs at the top of any page, the "Class" of an article, and the cite options on the Edit Toolbar. Could be more, but I just opened up Wikipedia. I'm on Firefox 3.6.23, with Windows XP. Maile66 (talk) 15:30, 5 October 2011 (UTC)[reply]

This sounds like it is because of many user scripts not working, already reported above. –Drilnoth (T/C) 16:07, 5 October 2011 (UTC)[reply]

Special:AllMessages

Resolved

– fixed

Extended content

The row highlighting is missing from Special:AllMessages. ---— Gadget850 (Ed) ^talk 15:56, 5 October 2011 (UTC)[reply]

Highlighting works for me, but the green/red backgrounds are now gone. — Edokter (talk) — 16:08, 5 October 2011 (UTC)[reply]

bugzilla:28425 —TheDJ (talk • contribs) 16:10, 5 October 2011 (UTC)[reply]

You mean bugzilla:31380 :) — Edokter (talk) — 16:35, 5 October 2011 (UTC)[reply]

Yes, I meant the background colors. More difficult to pick out changes. ---— Gadget850 (Ed) ^talk 16:44, 5 October 2011 (UTC)[reply]

Fix was deployed earlier today. --brion (talk) 01:44, 6 October 2011 (UTC)[reply]

All scripts broken in IE

Resolved

– fixed

Extended content

I'm seeing these types of error messages in the IE (9) console (press F12): "SEC7112: Script from http://en.wikipedia.org/w/index.php?title=User:Shubinator/monobook.js&action=raw was blocked due to mime type mismatch". Seems like something similar to this. Shubinator (talk) 17:02, 5 October 2011 (UTC)[reply]

As intended, won't change due to Bugzilla:15461 being fixed in 1.18. If you use action=raw, you should also use &ctype=text/javascript — ☠MarkAHershberger☣ (talk) 00:29, 6 October 2011 (UTC)[reply]

I've actually found the source of the missing ctype parameter: Special:MyPage doesn't pass it on when redirecting to the actual userpage. Shubinator, you should be able to work around this by changing User:Shubinator/vector.js to reference User:Shubinator/monobook.js directly instead of Special:MyPage/monobook.js. --brion (talk) 00:56, 6 October 2011 (UTC)[reply]

Worked like a charm, thanks! :) Shubinator (talk) 03:31, 6 October 2011 (UTC)[reply]

Proper fix for this is ready, should get deployed somewhere soonish. --brion (talk) 01:17, 6 October 2011 (UTC)[reply]

Fix has been deployed. --Catrope (talk) 13:30, 6 October 2011 (UTC)[reply]

Classic skin categories

Spacing on the categories displayed in articles has become messed up.©Geni 17:07, 5 October 2011 (UTC)[reply]

It isn't real pretty in Vector at the moment, either. I think there is a section above about that. –Drilnoth (T/C) 17:10, 5 October 2011 (UTC)[reply]

See #Categories are surrounded by much more space, and they don't wrap from line to line for a chunk of CSS to restore something like the old behaviour. --Redrose64 (talk) 11:37, 7 October 2011 (UTC)[reply]

Dab solver

In Dab solver, I can no longer get (sign in) to work. The output from "Get my credentials" seems to have changed today, to a more verbose format which "Use credentials" does not accept. Dab solver informed. Certes (talk) 17:33, 5 October 2011 (UTC)[reply]

The YAML formatter was switch to JSON (since it's technically a superset of it) in rev:86302. I didn’t want write a thousand lines for YAML in JS so I just used regular expressions. — Dispenser 03:10, 6 October 2011 (UTC)[reply]

Special:Contributions formatting

Resolved

– invalid: Please report any issues with this gadget here

Extended content

I'm using Firefox 7.0.1 with the Vector skin. I've already completely cleared the cache and restarted the browser. There is some kind of issue with the Special:Contributions page. Under the "User contributions" title at the top of the page, it says "For [UserFoo]' (talk | block | block log | uploads | logs | deleted user contributions | user rights management | filter log) • Javascript-enhanced contributions lookup 0.2 enabled. You may enter a CIDR range or append an asterisk to do a prefix search." That last sentence is unusual because (1) it overlaps the "Help:User contributions" link at the right side of the screen, and (2) I'm looking at a registered account, not an IP address, so why the info about CIDR range? (Maybe it was always like this and I just noticed) -- Gyrofrog (talk) 17:51, 5 October 2011 (UTC)[reply]

References in galleries

Resolved

– fixed

Extended content

In an old version of Elizabeth II,[2] there are <ref> markers in a <gallery> that are broken. DrKiernan (talk) 18:53, 5 October 2011 (UTC)[reply]

This is almost certainly a different manifestation of the same nested ref bug described above and in bugzilla:31374. It is likely to hit most forms of nesting. Dragons flight (talk) 21:18, 5 October 2011 (UTC)[reply]

It is under discussion on Bugzilla. ---— Gadget850 (Ed) ^talk 21:21, 5 October 2011 (UTC)[reply]

Autoblock screwiness

Reported: Bugzilla:31403 — ☠MarkAHershberger☣ 15:33, 6 October 2011 (UTC)[reply]

Extended content

We're seeing autoblocks pop up in cases where the blocked user hasn't edited in a Very Long Time. For instance, at User talk:Esoglou, we see he was hit by an autoblock from an account blocked in late 2009. I've seen several other such today. --jpgordon^{::==( o )} 19:06, 5 October 2011 (UTC)[reply]

I agree, there's definitely something borked with autoblocks. --Jezebel'sPonyo^{bons mots} 19:14, 5 October 2011 (UTC)[reply]

Any other cases? I'm at a loss for now. Aaron Schulz 03:48, 6 October 2011 (UTC)[reply]

Here's another: http://en.wikipedia.org/w/index.php?title=Special:BlockList&action=search&ip=%233620311 -- note that the actual block happened 13 November 2009. Hm. Same timeframe.... --jpgordon^{::==( o )} 15:02, 6 October 2011 (UTC)[reply]

Oh, if someone lifts the autoblock, it looked like this:

14:39, 6 October 2011 Autoblock #3620311 14:39, 7 October 2011 (unblock) Jpgordon (talk | contribs | block) account creation blocked (Autoblocked because your IP address was recently used by "Jpotts15". The reason given for Jpotts15's block is: "Vandalism-only account".) --jpgordon^{::==( o )} 15:04, 6 October 2011 (UTC)[reply]

Here's another: http://en.wikipedia.org/w/index.php?title=Special:BlockList&action=search&ip=%233619641 -- this time the block was in 2010. --jpgordon^{::==( o )} 15:06, 6 October 2011 (UTC)[reply]

Links in sortable table headers

Resolved

– fixed

Extended content

Now that you can click on the column titles to sort (rather than just the icon) any links contained therein stop working. This is most problematic when it's a notes link, such as that at 2010 World Monuments Watch. violet/riga _^[talk] 19:18, 5 October 2011 (UTC)[reply]

Gah! Between this and the comments above about sortable tables, it really makes me wonder. Why was it changed at all? It was working just fine before and in a way that people would expect it to work. –Drilnoth (T/C) 19:23, 5 October 2011 (UTC)[reply]

This part of the issue should be fixed. Dragons flight (talk) 20:52, 5 October 2011 (UTC)[reply]

Excellent. –Drilnoth (T/C) 21:45, 5 October 2011 (UTC)[reply]

Font size in AfD close/relist boxes

The 1.18 change has made the text in the boxes that appear when you click the "Close" or "Relist" tabs in an AfD render in small text like this. I can kinda see the reasoning, but at the same time, it's really hard on the eyes (at least for me, and I'd bet others). Is there any way that (assuming this is a feature and not a bug) there could be a checkbox added to 'Preferences' to allow users to select 'Normal size text in AfD maintiance tabs' or somesuch? - The Bushranger _{One ping only} 19:43, 5 October 2011 (UTC)[reply]

Facepalm It'd been so long I'd completely forgotten that was a .css script and not part of the site coding. Posted on the creating user's talk page about it. Sorry for the bother! :) - The Bushranger _{One ping only} 20:04, 5 October 2011 (UTC)[reply]

Yes, I also noticed that in the AfChelper script (based on AfD helper). The font size is much smaller after the update. Alpha_Quadrant ^(talk) 20:47, 5 October 2011 (UTC)[reply]

Doesn't remember position in edit box

Reported: Bugzilla:31404 — ☠MarkAHershberger☣ 17:56, 6 October 2011 (UTC)[reply]

Extended content

After a "show preview" or "show changes", the vertical position in the edit box isn't remembered anymore. Od1n (talk) 20:07, 5 October 2011 (UTC)[reply]

Reproducible only on fr: wiki, when I'm logged. Should be due to a script of mine. Will look into that... Od1n (talk) 20:10, 5 October 2011 (UTC)[reply]

The issue was relevant to a script I use, fixed. However, even without using any user script, there is a "flickering" when the scroll position is restored, which wasn't happening before... Od1n (talk) 22:53, 5 October 2011 (UTC)[reply]

Overwritten file still shows old version

Resolved

After uploading a series of project assessment maps, the old versions which were overwritten still show on the file's page. (example) However, thumbnails show the correct version, and if you click the image, the current version shows. –Fredddie ™ 21:56, 5 October 2011 (UTC)[reply]

bugzilla:31382 " Fixed and live @ 2011-10-05 20:22:30 UTC. Confirmed by uploading a new file version over a test file. New file versions uploaded between 02:04 and 20:22:30 UTC (could) need a manual purge to update to the new file version correctly" —TheDJ (talk • contribs) 23:34, 5 October 2011 (UTC)[reply]

Old block reason doesn't pre-load

Reported: Bugzilla:31405 — ☠MarkAHershberger☣ 17:53, 6 October 2011 (UTC)[reply]

Extended content
When changing a block, the block reason used to pre-load into the "reason" box on Special:Block. This seems to have been changed – now the reason box remains blank when you wish to change a block. (e.g. [3]) Could this be changed back? —GFOLEY FOUR!— 22:11, 5 October 2011 (UTC)[reply]

If you can make IE crash pretty reliably we need your help.

Resolved

– fix being deployed likely cause was jquery 1.6.2

See next section. Comment on the the bug or leave a comment here. (Comments on the bug will be seen sooner, though.) — ☠MarkAHershberger☣ 20:02, 6 October 2011 (UTC)[reply]

XP, IE8, Vector skin. Mostly it just refreshes the tab, displaying a popup thingy for a few seconds. Sometimes, IE decides this is happening too often and gives up, doing exactly what Chris describes in Comment 7 on the bug report. This morning, for the first time, IE said the site was misbehaving and that IE needed to close down. It proposed to send a bug report to MS, which I permitted, and then IE did NOT close (this is quite unusual). What (non-technical) help do you need? --Stfg (talk) 09:32, 7 October 2011 (UTC)[reply]

Some more details: (1) After opening a brand new browser window and loading any WP page, the first time I click My Watchlist, IE doesn't complain. (So far, My Watchlist is the only page with this property). On all subsequent occasions in that window+tab, it complains even for My Watchlist. (2) It happens not only on clicking Wikilinks, but also when loading WP pages from IE Favourites. (3)It doesn't happen the first time a WP page is loaded into a new IE tab. But after it has happened once in any tab, it seems to be there for life: you can load pages from other sites for as long as you like, then then if you try to load a WP page again after that, the problem is still there. Deleting temporary internet files and history does seem to reset the tab, though. --Stfg (talk) 10:20, 7 October 2011 (UTC)[reply]

(←) It's wrong to say that IE8 is crashing, and this is leading some people on Bugzilla to say it's MJ$ not MW. Although there have apparently been some crashes (and referencing the zero address is certainly a M$ bug), the showstopper is the one where a "website problem" necessitates IE refreshing the tab, which it quite often gives up on. The browser does NOT crash, and if it doesn't give up then it does load the requested page. But when it gives up, if you're editing, you can waste work and get in a mess. The problem doesn't arise, by the way, with Classic skin, so there's something in that one. But Classic skin is hopeless. For me, this is a complete show-stopper. I've suspended all but trivial editing, and won't be trying show-preview on this one either. --Stfg (talk) 21:43, 7 October 2011 (UTC)[reply]

The "This tab has been recovered" error in Internet Explorer 8 seems to only come up for me when I get on Wikipedia from another website. If I go to Wikipedia using the Run dialog (which starts Internet Explorer if it is not already running; otherwise, it adds a new tab to the existing one), then I do not get the error. I do not seem to get the error when browsing or editing Wikipedia. I am using I. E. 8 and Windows Vista 32-bit, and use the Monobook skin here on Wikipedia. Regards, —{|Retro00064|☎talk|✍contribs|} 22:00, 7 October 2011 (UTC).[reply]

IE8

Reported: 1.18 Causes IE8 to crash — ☠MarkAHershberger☣ 15:33, 6 October 2011 (UTC)[reply]

Extended content

I've had two primary issues in IE8 on XP. One, often times when I go to a page (usually clicking on Login) the tab will refresh along with a second, possibly unrelated tab. Also, I am frequently getting errors where IE can't restore/return the page. Chris857 (talk) 00:15, 6 October 2011 (UTC) Sometimes, also, when I try to log in, it takes about three times for it to succeed. Chris857 (talk) 00:30, 6 October 2011 (UTC)[reply]

If you find a way to reliably reproduce this, please let me know — ☠MarkAHershberger☣ (talk) 02:50, 6 October 2011 (UTC)[reply]

Yes to confirm I've been having simular problems with IE8 on XP where the tab will refresh often amd sometimes drop out to an error page. This has happened on two systems. However, I've haven't had the problem in the last few minutes; will report back if I see the problem again. Edgepedia (talk) 08:07, 6 October 2011 (UTC) (UTC + 1)[reply]

I've had this problem about a dozen times in the last two days. It's affected two different machines, both of which run IE 8. This one is running version 8.0. I do not have the ability to change or upgrade browser. I'd call this frequent browser crashing, but I'm not technical. The fact that this is the only website affected, combined with the fact it's on two different machines and just after a software 'upgrade' leads me to conclude it's definitely a Wikipedia issue. I'm rather disappointed that the upgrade has been rolled out and we're experiencing so many bugs. --Dweller (talk) 12:31, 6 October 2011 (UTC)[reply]

I'm getting this on IE 8 with XP whether I run in compatibility mode or not. I use the Monobook skin. 95% of the time when I hit refresh on my Watchlist IE loses the tab and then recovers it. I don't get the error when navigating to (or refreshing) other pages, and I don't get it the first time I open my browser and navigate to watchlist. Karanacs (talk) 15:03, 6 October 2011 (UTC)[reply]

When I look at the error info collected by MS, it says this is error code 0xc000005. Karanacs (talk) 15:07, 6 October 2011 (UTC)[reply]

Pressing "refresh" on this page helpfully caused it to crash [yet again] and generated the following Microsoft goobledigook:

The instruction at 0x3fa07b98 referenced memory at “0x00000008”. The memory could not be “read”.

I may have included too many or too few zeros in that address - counting them made me dizzy. --Dweller (talk) 15:14, 6 October 2011 (UTC)[reply]

No prompt when entering a blank edit summary in my user space

Reported: No prompt when entering a blank edit summary in my user space — ☠MarkAHershberger☣ (talk) 05:57, 6 October 2011 (UTC)[reply]

Extended content
I have "Prompt me when entering a blank edit summary" checked in my edit preferences. I am no longer getting the prompt when I try to enter a blank edit summary for an edit in my user space. I get the prompt with other edits, as before. Is this an accident or an intentional feature? --Orlady (talk) 04:40, 6 October 2011 (UTC)[reply]

Change in behavior of browser "Back" button

Reported: Changed behavior of back button — ☠MarkAHershberger☣ 17:50, 6 October 2011 (UTC)[reply]

Extended content

[Firefox browser 3.6.x under various operating systems, Monobook skin.]

While editing, I am accustomed to being able to go to a new browser destination in the open tab, then use the back button to return to the open edit window to resume my work. I am accustomed to doing the same thing when I encounter an edit conflict or error message after pushing "Save Page" (that is, I return to the previous page in the history to retrieve my work).

With the advent of 1.18, this behavior has changed, After seeing the edit conflict message or a message prompting me to add an edit summary, if I step back into the history using the back button, the edit window reverts to its condition before I started my edit.

I have not tested every possible variation of this situation, but I have replicated it with the edit conflict error and with he "no summary" message, and I think I've seen it in other situations. It's annoying, as I have become very accustomed to the old behavior! --Orlady (talk) 04:54, 6 October 2011 (UTC)[reply]

Me too. It would be very annoying to not be able to do this any more. Carcharoth (talk) 05:15, 6 October 2011 (UTC)[reply]

This is happening for me as well, very annoying. - The Bushranger _{One ping only} 23:23, 6 October 2011 (UTC)[reply]

It's still happening. —Anomalocaris (talk) 20:43, 7 October 2011 (UTC)[reply]

Changed appearance of Special:Block

This is not a big deal, but does anybody know why the order of the tickboxes on Special:Block was changed? Not worth a Bugzilla or anything, but it seems a strange thing to do. HJ Mitchell | Penny for your thoughts? 11:06, 6 October 2011 (UTC)[reply]

According to the release notes: "The options on the block form have been standardised such that checking a box makes the block 'more serious'; so while "check to prevent account creation" and "check to enable autoblock" remain the same, "check to allow user-talk edit" is reversed to "check to *disable* user-talk edit", and "check to block anon-only" becomes "check to block logged-in users too". The default settings remain the same." MrBlueSky (talk) 16:59, 6 October 2011 (UTC)[reply]

The block form also no longer pre-fills with the existing block reason during block modification. This was desirable behaviour, as it made it easy to make small annotations to the original block reason when modifying it. –xeno^talk 03:45, 7 October 2011 (UTC)[reply]
- A bugreport has been made about that: bugzilla:31405. MrBlueSky (talk) 12:45, 7 October 2011 (UTC)[reply]
  - Thanks for pointing that out, commented there. –xeno^talk 12:53, 7 October 2011 (UTC)[reply]

So why was this done

Where was the discussion before deployment and can it be rolled back? Lugnuts (talk) 07:08, 6 October 2011 (UTC)[reply]

See #Simple explanation of the enhancements 1.18 brings for “why” — Preceding unsigned comment added by MarkAHershberger (talk • contribs) 18:09, 6 October 2011 (UTC)[reply]

Special pages

Resolved

– fixed

Extended content

Through 1.17, the message at the top of special pages, such as Special:DoubleRedirects, said when the page contents had last been updated. Now, under 1.18, it just says "The following information is cached and may not be completely up to date." Why was this done? Providing the timestamp for the last update can't be much of a resource burden, and it's information that has some use to some users. --R'n'B (call me Russ) 11:23, 6 October 2011 (UTC)[reply]

This was a bug. The timestamp is back now. --Catrope (talk) 13:27, 6 October 2011 (UTC)[reply]

Simple explanation of the enhancements 1.18 brings

I tried, honestly I tried, to understand this, but most of it didn't make any sense to me, as a non-techie. Where can I find a simple explanation of the enhancements? --Dweller (talk) 12:50, 6 October 2011 (UTC)[reply]

Try What's new? — ☠MarkAHershberger☣ (talk) 12:59, 6 October 2011 (UTC)[reply]

Perfect, thanks --Dweller (talk) 13:41, 6 October 2011 (UTC)[reply]

Specifically for bureaucrats, 1.18 means that the suppress redirect tickbox during the first step of usurp requests gets automatically checked, and it also brings auto-fill capability for userrights changes rationales (which has already been put to good use at WP:BRFAA). –xeno^talk 13:09, 6 October 2011 (UTC)[reply]

Nice --Dweller (talk) 13:41, 6 October 2011 (UTC)[reply]

Status Check js

It's broken; doesn't work on contrib pages, works on userpages for some reason; but it worked correctly yesterday. HurricaneFan 25 14:59, 6 October 2011 (UTC)[reply]

This is the talkpage of it's author and maintainer, you'd best ask him. —TheDJ (talk • contribs) 16:17, 6 October 2011 (UTC)[reply]

Special:EditWatchlist/raw

Resolved

– Fixed but not yet deployed —TheDJ (talk • contribs) 14:23, 8 October 2011 (UTC)[reply]

Seems broken, I use this to limit the pages I watchlist (normally last 500 + about 100 that I always want on the list) When I open it (FF 3.6) I see " instead of " in page titles. ΔT _{^{The only constant}} 16:05, 6 October 2011 (UTC)[reply]

Reported as bugzilla:31435 —TheDJ (talk • contribs) 16:21, 6 October 2011 (UTC)[reply]

Another bug with Special:EditWatchlist/raw

Opened the page in Firefox 9.0a2 as well as Chrome 16 just now and the contents appear for a millisecond and then the form is empty. The entries are still in the HTML source though: screenshot. Regards So Why 21:20, 6 October 2011 (UTC)[reply]

Toolbox missing "Contributions" at user pages/talk pages

When reading/editing a user or user talk page, we used to have a toolbox link to the user's contributions. That seems to have gone AWOL; it's a frequently used tool. Noted on both WinXP/IE7 and WinXP/FF7.0.1. Risker (talk) 16:48, 6 October 2011 (UTC)[reply]

I still see it on my browser (Win7/FF5.0). - The Bushranger _{One ping only} 18:48, 6 October 2011 (UTC)[reply]

I have the same problem, the user contributions shows up in the toolbox for about 1 second and then it disappears. Same problem in IE9 and FF 6.0.2. However, user contributions does show up as "Contributions" under one of the down arrows in the tabs at the top of page. --Funandtrvl (talk) 20:34, 6 October 2011 (UTC)[reply]

That is the "Add page and user options to drop-down menus on the toolbar" gadget doing that; it moves all user and page related options to those menus. Not a bug. — Edokter (talk) — 20:57, 6 October 2011 (UTC)[reply]

Yes, I just realized that now by resetting "my preferences" back to default. Thanks! --Funandtrvl (talk) 21:01, 6 October 2011 (UTC)[reply]

You're right; I see it's ticked on my preferences too. Strange, since I'd set my prefs to default yesterday when testing something else, but at this point I'm just glad to get rid of this. Thanks all! Risker (talk) 23:42, 6 October 2011 (UTC)[reply]

You mean you didn't see the internet gollum that went and changed back your preferences last night??!! --Funandtrvl (talk) 00:17, 7 October 2011 (UTC)[reply]

Dang cybergnomes! - The Bushranger _{One ping only} 00:31, 7 October 2011 (UTC)[reply]

"File links" on media files not updating?

I think that somehow 1.18 has fixed things so that the "File links" section isn't updating on media files' pages. For instance, I added an image to this page last night, but the File: page for the image in question still insists that "No pages on the English Wikipedia link to this file." - The Bushranger _{One ping only} 18:47, 6 October 2011 (UTC)[reply]

This may be working now. - The Bushranger _{One ping only} 22:23, 6 October 2011 (UTC)[reply]

View and edit watchlist page

Is it possible for the table of contents to be put back onto the 'view and edit watchlist' page? Otherwise, those of us with long watchlists have to keep scrolling and scrolling to get to the Category namespace group of watched pages. Thanks, --Funandtrvl (talk) 21:05, 6 October 2011 (UTC)[reply]

Math/Latex

Some strange math-LaTeX errors in MW1.18:

1: $f_{n}:(\Omega ,\Sigma ,\mu )\rightarrow ({\overline {\mathbb {R} }},B),n\in \mathbb {N}$ Example article in de-wp

2: ${\dot {\vec {B}}}$ Example article in de-wp

3: ${\text{rot}}{\vec {E}}={\dot {\vec {B}}}=0$ (The arrow and the dot is not over the letter B. If you remove the "\text{rot}" at the beginning, the parser will fail like in example 2) --wdwd (talk) 22:13, 6 October 2011 (UTC)[reply]

The fix is to add extra braces to clarify what \overline or \dot is over

1

f_{n}:(\Omega ,\Sigma ,\mu )\rightarrow ({\overline {\mathbb {R} }},B),n\in \mathbb {N}

2

{\dot {\vec {B}}}

3

{\text{rot}}{\vec {E}}={\dot {\vec {B}}}=0

This seems to be an issue for everything that goes over or under the following text: it now needs braces, perhaps if followed by something more complex than a single symbol. I fixed a bunch of them at Möbius transformation and it was noted by another editor at Wikipedia talk:WikiProject Mathematics#TeX not rendering. These are easy to fix, the problem is finding pages where this is now a issue.--JohnBlackburne^words_deeds 22:34, 6 October 2011 (UTC)[reply]

Thanks. Maybe it would be easier to fix the latex/dvipng installation instead of finding of all these pages? In older mediawiki versions/installations all these expressions worked without extra braces.--wdwd (talk) 22:44, 6 October 2011 (UTC)[reply]

It seems like the MediaWiki plugin is trying to conform more to how (La)TeX works. I suspect you might get an error there too. Time to be less sloppy in writing TeX code, folks. ;) Nageh (talk) 18:14, 7 October 2011 (UTC)[reply]

I sort of agree: stuff like this happens all the time when you deal with programming languages. But usually you get a warning in the release notes/documentation and of course when building code you're told straight away what's wrong where. The problem here is you need to load the page, and scroll through all of it, to find the problem. Even if an editor spots it they might not know how to fix it (I checked Möbius transformation after noticing some odd edits by an IP editor trying but failing to fix the problem, and it took me a few trials to work out how to fix it). So failing a fix/rollback someway to find all the pages with parser errors would be very useful (and not just for this).--JohnBlackburne^words_deeds 23:35, 8 October 2011 (UTC)[reply]

Reported as bugzilla:31442. Dragons flight (talk) 22:50, 6 October 2011 (UTC)[reply]

Crashing Internet Explorer

Resolved

– fix being deployed and duplicate of #Problem with Internet Explorer

Extended content

My Internet Explorer (Windows XP Media edition) has gone haywire since yesterday, or should I say, since 1.18. Normal editing and saving is impossible with the following message popping up with every next move. For example, in order to post this message, I had to click Save without Preview and recover it later, because the page crashed again twice:

File:IE-needs-to-close-1.jpg

When I click off the above dialog box "Send" or "Don't Send" the screen is restored by IE to its initial stage with the following message: "This tab has been recovered." And naturally, all new stuff in the edit box disapears without the trace when the page is recovered. -- A. Kupicki (talk) 23:05, 6 October 2011 (UTC)[reply]

Though I usually use firefox, I used IE 8 yesterday to edit due to problems from 1.18 and faced the same problem. --Redtigerxyz ^Talk 05:32, 7 October 2011 (UTC)[reply]

All yesterday and again today several situations have caused a Microsoft "IE needs to close" message to appear. IE 8 is what I am using & Windows XP. If save has been pressed before that messge appears saving still happens very slowly if "don't send" is selected. However after a number of these incidents the attempt to reopen the tab fails and MediaWiki stops operating completely. It will work again if opened again in another tab but usually not for very long before another breakdown.--Felix Folio Secundus (talk) 10:13, 7 October 2011 (UTC)[reply]

Please note, the new screenshot shows exactly what happens when the 'Save page' button is pressed after editing. No improvement since yesterday. -- A. Kupicki (talk) 15:11, 7 October 2011 (UTC)[reply]

Please see #Problem with Internet Explorer. Bug is reported to the server admins/devs. --Saibo (Δ) 17:21, 7 October 2011 (UTC)[reply]

Sorry for the inconvenience! We've been able to reproduce this issue in some IE8 configurations and are currently investigating a number of possible fixes.--Eloquence * 18:32, 7 October 2011 (UTC)[reply]

Javascript error in Watchlist

Using Firefox 7.0.1, I get the following error on opening watchlist (following 1.18 release): Error: item.revisions is undefined Source File: http://en.wikipedia.org/w/index.php?title=User:M/reword.js&action=raw&ctype=text/javascript Line: 143

So the customized features of watchlist do not work. --Redtigerxyz ^Talk 05:37, 7 October 2011 (UTC)[reply]

You are using a local modification written by User:M. Suggest to ask him if he can help fix the script. —TheDJ (talk • contribs) 12:41, 7 October 2011 (UTC)[reply]

Monobook Sidebar has spaces between boxes

Using IE8. Now there are big spaces betreen the boxes of the sidebar. (Example: File:MW118 Monobook Bug.jpg) --Trigonomie (talk) 08:34, 7 October 2011 (UTC)[reply]

Extra arrows over page/user menus

I use this gadget, and there are extra down-pointing arrows over them. Incidentally, earlier Twinkle had the same problem, but now the arrow for TW works right. →Dynamic|cimanyD← (contact me) 21:49, 7 October 2011 (UTC)[reply]

No minor edit tag in watchlist

I can see N and b tags on my watchlist, but not m for minor edit. All three tags appear in article history and my contributions listings. Running Firefox 7.0 on openSUSE. Vector skin with the updates for bold N, b, m tags in common.css. Page reloaded with shift-reload, still happens. --Mirokado (talk) 15:01, 8 October 2011 (UTC)[reply]

Just to verify: You do have your watchlist set to show minor edits, right? –Drilnoth (T/C) 20:24, 8 October 2011 (UTC)[reply]

Missing text when saving

Resolved

– markup typo found

Hello, I have just created and saved a draft user page (FionaSturgeon/ChangeBASE), however the saved version does not show all the content I put in at the creation stage. When I go to edit, the text in question reappears, so it definitely is there in some form but is not being displayed for whatever reason. I am using Google Chrome.

Does anyone else have this issue, or know how I go about fixing it? I am new to Wikipedia so it is likely that I'm missed something - any help would be appreciated.

Many thanks, Fiona — Preceding unsigned comment added by FionaSturgeon (talk • contribs) 13:07, 5 October 2011 (UTC)[reply]

You are closing all your references with <ref>; you need to start with <ref> and close with </ref>. ---— Gadget850 (Ed) ^talk 13:21, 5 October 2011 (UTC)[reply]

Preventing an account from becoming autoconfirmed

Is there any way to prevent one's account from ever becoming autoconfirmed? I'd like to do that with my alternative account. ― A. di M._plé^dréachtaí 13:30, 5 October 2011 (UTC)[reply]

By not exceeding 9 edits. But to what end? –xeno^talk 13:35, 5 October 2011 (UTC)[reply]

I actually have the same problem. I answer help desk questions and often log in to a non-confirmed alternative account to see what new users see. A solution to this particular problem would be to make two alternative accounts and make sure one of them never reaches 10 edits. If your concern is that somebody accesses your alternative account after use on a public computer and uses it to do inappropriate things only autoconfirmed users can do then I wouldn't worry about it. It's an unlikely scenario, it's limited how much damage they could do, and we already deal with scores of autoconfirmed bad apples. PrimeHunter (talk) 14:02, 5 October 2011 (UTC)[reply]

You can also set an edit filter to revoke autoconfirmed on the account, I believe. The edit filter could be one-use only. T. Canens (talk) 15:25, 5 October 2011 (UTC)[reply]

Alternatively, if you don't intend to ever edit from your alternate account but only view, but want to be sure you don't accidentally slip up and edit using it out of habit, you could ask the admins to simply indef-block the alternate account. - The Bushranger _{One ping only} 19:36, 5 October 2011 (UTC)[reply]

What will result in wp:autoblock Bulwersator (talk) 13:25, 6 October 2011 (UTC)[reply]

Autoblock can be disabled, but if the purpose of having a non-autoconfirmed account is to "experience what new users experience", being blocked probably wont help - unless you want to experience what it is like for a new users to be blocked. –xeno^talk 13:30, 6 October 2011 (UTC)[reply]

WP:REFNEST has stopped working properly

Resolved

– duplicate of #bug in #tag:ref parser function

Help - the code behind WP:REFNEST has stopped working properly, resulting in references embedded within notes displaying a series of random characters. Any ideas? Shem (talk) 14:49, 5 October 2011 (UTC)[reply]

See #bug in #tag:ref parser function above. ---— Gadget850 (Ed) ^talk 14:52, 5 October 2011 (UTC)[reply]

Thanks - missed that. Shem (talk) 15:30, 5 October 2011 (UTC)[reply]

Reftool 1.0 failing when filling fields from URL

~~Reported: webkit problems with reftool~~ Local mod, report errors here: Wikipedia_talk:RefToolbar

I use Reftools 1.0 because it can grab data and fill in fields when given the source URL. When I use it today, instead of filling in the fields, I find that I'm no longer in edit more and I'm looking at the "Read" version of the article. The browser is Chrome-- Whpq (talk) 15:28, 5 October 2011 (UTC)[reply]

I have the same problem, not just in Chrome but also in Safari. --joe decker ^{talk to me} 13:59, 6 October 2011 (UTC)[reply]

I have the same problem with Firefox 7.0.1. -- Alan Liefting (talk) - 07:49, 8 October 2011 (UTC)[reply]

Strange changes

Resolved

– duplicate of #"m" and "b" edit indicators aren't bold

Resolved

– duplicate of #Namespace option on contribution history

Extended content

On user contributions pages, I noticed today that the m for minor was no longer bold and has an ellipsis underneath, and also I can nolonger select a namespace to view the contributions in. Has anybody else noticed this, and if so, what is going on? Rcsprinter (rap) 15:40, 5 October 2011 (UTC)[reply]

Workaround is to add the following to your css declarations:

/* Remove the distracting underlines from N, m, b in watchlist, make 'em bold */
 
abbr.newpage {border:0; font-weight: bold;}
abbr.botedit {border:0; font-weight: bold;}
abbr.minoredit {border:0; font-weight: bold;}

With credit to Redvers and SoWhy. –xeno^talk 15:44, 5 October 2011 (UTC)[reply]

(edit conflict) Both topics are raised above. - David Biddulph (talk) 15:45, 5 October 2011 (UTC)[reply]

I am not seeing where. I hope that namespace search is restored quickly, I don't particularly care to learn css right now. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 19:33, 5 October 2011 (UTC)[reply]

No need to learn - just cuta nd past the above into the css page. Thanks for that, that works even better than the bolding script above. I can see clearly now, the dots are gone! - The Bushranger _{One ping only} 19:38, 5 October 2011 (UTC)[reply]

The "ellipsis" underneath the current unmodified display is your browser's default decoration for text associated with an abbreviation note (hence the "abbr" in the above css code), which looks a bit strange for only one character. On Firefox, for example, you get a question mark cursor if you hover over one of those letters and after a short delay an explanation pops up. --Mirokado (talk) 13:02, 6 October 2011 (UTC)[reply]

Twinkle problems

I noticed that Twinkle isn't loading. I cleaned up my js file, but that didn't work. Removing TW from my js file and enabling it as a gadget. I usually use the secure server, so I switched to the regular server, but had no luck with that. At all the times I cleared or bypassed my cache. I run an unbranded version of Firefox 7. Samuell ^{Lift me up} or _{put me down} 16:14, 5 October 2011 (UTC)[reply]

Many things are not working right now; check the massive section above to see if problems have already been reported. This one has, at #Some_JS_tools_broken. Aren't not-quite-thoroughly-tested new versions of MediaWiki great?! –Drilnoth (T/C) 16:11, 5 October 2011 (UTC)[reply]

Interesting right ? Even after having been in production on 3 wiki's for over 3 days, no one but en.wp has found many of these issues. As a user you underestimate the thousands of usage patterns that there are. Testing will only reveal so much. Also, Twinkle is a local tool. The local community is responsible for keeping it maintained. Thus it is no more than expected basically that many of the gadgets break when a release is being made. Dust will settle. —TheDJ (talk • contribs) 16:17, 5 October 2011 (UTC)[reply]

See WT:TW#No Twinkle at all? and other discussions on that page. Regards So Why 16:20, 5 October 2011 (UTC)[reply]

The funny thing is, aside from a few very minor niggling issues that are more cosmetic than anything else, my Twinkle has (so far) been working just fine... - The Bushranger _{One ping only} 19:39, 5 October 2011 (UTC)[reply]

Redirects to sections

Resolved

– bogus

Is this broken or is it just me? Links like WP:UNDUE and WP:AUTOCONFIRM lead to the correct pages, but are not navigating to the sections. Using Firefox 7.0.1. — Bility (talk) 16:38, 5 October 2011 (UTC)[reply]

Works for me ΔT _{^{The only constant}} 16:39, 5 October 2011 (UTC)[reply]

(edit conflict) Nevermind, it was me. — Bility (talk) 16:40, 5 October 2011 (UTC)[reply]

Banging my head

MediaWiki:Broken-file-category was introduced with 1.18 and Im trying to configure it so that it only lists articles/templates with missing files. (other namespaces really dont matter too much). But I cannot see to get it configured correctly. ΔT _{^{The only constant}} 17:28, 5 October 2011 (UTC)[reply]

I used {{namespace detect showall}} in {{broken ref}} to do similar for Cite errors. ---— Gadget850 (Ed) ^talk 18:17, 5 October 2011 (UTC)[reply]

Can you go ahead and adjust the page accordingly? ΔT _{^{The only constant}} 20:31, 5 October 2011 (UTC)[reply]

User-defined buttons, tabs or links

Is there any way to have a button, tab or a link that I could customize to add a certain text? I'd like to be able to "one click" my default welcome templates, and messages like this. Any suggestions? --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 17:51, 5 October 2011 (UTC)[reply]

You can do this with Twinkle, but you probably want to wait until issues with the update shake out. ---— Gadget850 (Ed) ^talk 18:39, 5 October 2011 (UTC)[reply]

Take a look at meta:User:Krinkle/Scripts/InsertWikiEditorButton. Helder 15:01, 7 October 2011 (UTC)[reply]

Numbers and letters appearing in place of link to footnote

Resolved

– duplicate of #bug in #tag:ref parser function

In Love the Way You Lie#Notes, I have a footnote, which is referenced. However, the link to the reference now shows ?UNIQb4e22634542f5cb-nowiki-00000079-QINU?18?UNIQb4e22634542f5cb-nowiki-0000007A-QINU? instead of the [citation number]. I use Google Chrome on Windows 7, but this problem is also apparent when seen on Firefox. I just noticed this today and was wondering if it is a glitch that can be fixed. Thanks! —WP:PENGUIN · ^{[ TALK ]} 17:57, 5 October 2011 (UTC)[reply]

Already reported above. –Drilnoth (T/C) 18:04, 5 October 2011 (UTC)[reply]

General notice

Resolved

– already done

Given the scale of issues introduced by this new version of software, should we consider placing a general message suggesting readers head here to add issues they're experiencing? The Rambling Man (talk) 18:29, 5 October 2011 (UTC)[reply]

That sounds like a really good idea. --Kumioko (talk) 18:34, 5 October 2011 (UTC)[reply]

Already at the top of the watchlist. ---— Gadget850 (Ed) ^talk 18:51, 5 October 2011 (UTC)[reply]

Not sure if it's possible but probably worth re-asserting the message every so often because I usually ignore these things, so I guess many other readers do too. Since we have so many issues, it'd be worth re-iterating the fact that the site's broken but won't be broken for long... hopefully... The Rambling Man (talk) 19:08, 5 October 2011 (UTC)[reply]

We need to do a better job of this

I realize that developing new changes to a widely used application like this are not at all easy and I don't mean to be overly critical but after reviewing the growing list of problems with the new release and the fact that most of us didn't even know it was coming I think we need to do a better job.

Several of the problems identified would have been obvious in some basic comparison testing and many of the common functions would have also been obvious if done (like all the problems with Twinkle). I realize that its impossible to compensate for every problem and WP has limited support of add ons like twinkle but some of these are really really obvious.

I recommend when we do updates in the future we do a couple things differently:

Put a notice on this village pump of the upcoming update
Establish a schedule of the updates in a public place like this page
Do some quality testing with some of the widely used tools like Twinkle and let the developers of those apps know that there are problems they need to fix.

--Kumioko (talk) 18:31, 5 October 2011 (UTC)[reply]

I know it's a minor part of Wikipedia but yes, some of our featured material (lists) have now been broken with the update, these feature once a week on the main page. This sort of thing should have been tested/advertised before being wholesale rolled out. RIght now we don't know whether to stick (not fix) or twist (try to fix hundreds of lists)... advice please. The Rambling Man (talk) 18:35, 5 October 2011 (UTC)[reply]

Posting a schedule in a public place was done weeks ago. --Catrope (talk) 19:22, 5 October 2011 (UTC)[reply]

Notices on the Village Pump / Template:CENT would probably have a lot more outreach than the WMF blog. Headbomb {talk / contribs / physics / books} 19:37, 5 October 2011 (UTC)[reply]

You mean like announcing it on VPT three weeks ago, Wikipedia:Village_pump_(technical)/Archive_93#MediaWiki_1.18_deployment_schedule? Dragons flight (talk) 19:42, 5 October 2011 (UTC)[reply]

Yep, missed that, not a watcher of the Village Pump. Didn't expect Wikipedia to be wrecked by a software "upgrade". Now I know what it was like when people moved to Windows Vista. Ouch. The Rambling Man (talk) 19:47, 5 October 2011 (UTC)[reply]

Or also, Wikipedia:Wikipedia_Signpost/2011-09-19/Technology_report, from just over two weeks before deployment. Dragons flight (talk) 19:58, 5 October 2011 (UTC)[reply]

So if you didn't watch the Village Pump or subscribe to Signpost, then you have no idea why Wikipedia is broken. Don't forget that this website is visited by users who don't even know that Village Pump or Signpost exist. We're just telling those who rolled out the bug-ridden version of Wikimedia software that those who are familiar with the site had no real clue it was happening and that it's broken a lot of stuff. Don't take it personally, just tell us when it'll all be fixed. The Rambling Man (talk) 20:09, 5 October 2011 (UTC)[reply]

(e/c) That is interesting, but how many regular Wikipedians read that? Perhaps a general notice for all readers, including anon IPs would be useful (if it doesn't already exist) to say that Wikipedia is currently broken and give normal users an idea when it will return to a useful state... The Rambling Man (talk) 19:38, 5 October 2011 (UTC)[reply]

(e/c)I was about to say the same thing. A general notice a week before linking to that blog and a page for problems to be listed would have been very useful I would think. --Kumioko (talk) 19:42, 5 October 2011 (UTC)[reply]

Were the developers/maintainers of tools like Twinkle and CSDHelper warned of the change and given access to an advance version to test with? JohnCD (talk) 22:11, 5 October 2011 (UTC)[reply]

Probably not directly, but it can be presumed that they have VPT on their watchlist. Remember that en.wiki is probably one of the most complex and intricate projects, and some bugs just need to be found in the wild. I appreciate all the hard work that went into this release and accept the growing pains as necessary... –xeno^talk 22:36, 5 October 2011 (UTC)[reply]

I guess this is the short term message. As Xeno says, hats off to the people that do all this work, both before and in particular after each version's rollout. Just by looking at the bugzilla reports of things I care about, it's clear to see that people are working flat out to fix the issues. I for one am very grateful. —WFC— 00:21, 6 October 2011 (UTC)[reply]

For what are you grateful? That the developers work hard to eliminate problems they themselves introduced? If so you're very easily pleased. Malleus Fatuorum 01:56, 6 October 2011 (UTC)[reply]

Were there any upsides to this "upgrade"? All I can see at the moment is the things that don't work. Is anything actually better as a result? I might feel a little better about this if there was. --John (talk) 06:10, 6 October 2011 (UTC)[reply]

See here and the full release notes. MER-C 11:38, 6 October 2011 (UTC)[reply]

An impressive list indeed. Perhaps the best course of action is to join the Italians for a few weeks, hoping that the devs will somehow switch back to 1.17. NVO (talk) 11:56, 6 October 2011 (UTC)[reply]

(←) Lines 8-11 of those relase notes (dated Oct 3):
8 THIS IS NOT A RELEASE YET
9
10 MediaWiki 1.18 is an alpha-quality branch and is not recommended for use in
11 production.
--Stfg (talk) 13:35, 6 October 2011 (UTC)[reply]

MediaWiki has always been deployed to Wikipedia before the software is released as a tarball (what the release notes cover). The blog post covering 1.18 deployment points to this page — ☠MarkAHershberger☣ 13:46, 6 October 2011 (UTC)[reply]

Just to clarify I know that its difficult to do a release like this and if it were just some problems with addons like twinkle that arent a part of the software or a few little bugs it would be fine. But when there are problems like breaking all the featured tables, screwing up the diff rendering, completely removing the ability to see namespace specific changes in contributions and a variety of others it would have been immediately obvious to any tester that these were problems if they would have done some simple comparisons. I also agree with the comments above that leaving the notice on the blog and Tecnhical village pump are noble but less than a 100 of our millions of users are likely to see either of those. I also agree with the comments that the developers are working hard to fix them but may of these should have never been put in production to begin with so now we have to live with the fallout. Personally I have a huge amount of edits and things I am trying to do in WP that now have to wait because it takes the page about 1-5 minutes to load a page every time I bring a new page up in edit mode, making it nearly useless and next to impossible to do a change. So whenever we get these problems fixed in the next couple weeks I will do the WikiProject United States Newsletter, continue working on project issues and contributing content. --Kumioko (talk) 14:57, 6 October 2011 (UTC)[reply]

Re “it would have been immediately obvious to any tester that these were problems if they would have done some simple comparisons”:

breaking all the featured tables

Agreed, but we do testing before deployment. How can we make sure all these template things are checked? (And, yes, I want to know how you think we could do it.)

screwing up the diff rendering

This was a gadget problem. If you want to make sure your gadgets are working, then you should help test.

completely removing the ability to see namespace specific changes in contributions

This was a policy decision to limit use of database resources. Obviously it should have had some more discussion with the community before hand, but it isn't a bug that we didn't know about.

☠MarkAHershberger☣ 15:57, 6 October 2011 (UTC)[reply]

I've moved the discussion about how we could improve testing before deployment. — ☠MarkAHershberger☣ 19:10, 7 October 2011 (UTC)[reply]

There was a fair number of issues with the 1.17 deployment, including an initial failed deploy and, again, a number of issues with gadgets, scripts, and breakage of some features or some configurations. You can read all about it here and here if you'd like to experience some deja vu.

There are some factors that make deploys hard for us that are fairly unique to us (for example, we give users an unprecedented level of control over the site by enabling admins to change site scripts and CSS, and we have a very powerful but also fairly fragile framework for gadgets), there are some that aren't unique to us but that aren't easily resolvable either (we're running an unusually large and complex site without the commensurate level of staffing e.g. for QA automation and testing), and there are some that are very much resolvable and in our control. Let me focus on the last ones.

Firstly, our release cycle has slowed down to the point where we push out releases with a huge number of changes that have been sitting unused in our version control system for months. See the release notes for 1.18 and 1.17. We've about cut the time between releases in half from 1.16->1.17 to 1.17->1.18, which is good progress, but we really want to get to an even more frequent cadence to achieve continuous integration of smaller increments of features, so that issues can be detected at a more granular level and be resolved close to the time when they've been caused by a code change.

Second, our unit testing is slowly becoming useful. We've put quite a bit of effort into increased unit test coverage with PHPUnit and Qunit and a new continuous integration server that regularly runs those tests, and we're starting to be bump code immediately when it fails tests (which is standard practice, but not something we've actually been doing).

Third, for gadgets, we've been working on supporting centralized publication of gadgets through the ResourceLoader 2 framework. This will make it possible to tests gadgets more systematically, and we can more easily set up test wikis that subscribe to key, frequently used gadgets. We should also start pushing gadget developers to write unit tests, and integrate them with the CI process.

Fourth, we've implemented support for heterogeneous deployment through the new multiversion framework. This has allowed us to push 1.18 out much more gradually and systematically than 1.17, and to have multiple stable testing sites that run on the production infrastructure but run different versions of the code.

Fifth, we've been working on a dedicated OpenStack-based infrastructure for all our continuous integration needs, to replace the aging and insufficient prototype VMs. The new labs console is used to manage VM instances that will increasingly resemble the production environment. These VMs will be made available to all MediaWiki developers (staff and volunteers), enabling better testing as part of the development process. We should also be able to use them for automated integration testing at some future point.

Sixth, for cross-browser testing, we've deprecated our aging local VM infrastructure in the office, and began evaluating a number of commercial solutions, both for manual and automated testing. We'll likely use CrossBrowserTesting for manual testing, and some combination of a system like SauceLabs and our existing TestSwarm setup for automated integration testing.

Seventh, we don't have a QA department yet! As we're growing our engineering staff from almost nothing to a dedicated team of a couple of dozen people, this has been high on our priority list for a long time. We've been actively recruiting for a QA lead position, and we're also going to hire some contractors both for testing and community coordination. As you know, Mark Hershberger has been helping a lot already, and I think you can see the results of this with the 1.18 deployment (bugs are being triaged and tracked more effectively than 1.17). I also completely agree that we can do more effective community outreach.

In a nutshell, the combination of shorter release cycles and improved testing methodology should help us make releases incrementally less painful. The proof will be in the pudding, but I hope you can see that we're very actively improving our development and testing methodology all the time, and we always appreciate feedback on how to do better.--Eloquence * 19:33, 7 October 2011 (UTC)[reply]

table sort headers

Resolved

– fixed

As the whole header cell is now a button to sort the table, it has killed any header text that is linked. Links still show but don't direct. For example, try clicking on the US$ link on the tables in List of countries by GDP (nominal) per capita. With some header text entirely linked, and necessarily so in many cases, it would be good to be able to override this new feature.- _J.Logan`^t: 19:01, 5 October 2011 (UTC)[reply]

Please add to #The new Sorting breaks all tables arround Wikipedia which include two headers. ---— Gadget850 (Ed) ^talk 19:04, 5 October 2011 (UTC)[reply]

This is fixed now. --Catrope (talk) 19:39, 5 October 2011 (UTC)[reply]

Sorting

Acknowledging that this function has now been corrupted, when can we expect a resolution? Are we going to be expected to re-code hundreds of articles as a result of this 'update'? The Rambling Man (talk) 19:14, 5 October 2011 (UTC)[reply]

Much of the problem is that the old code had no specification or tests at all so nobody could tell what was supposed to work or not or if any change would do anything good or bad. The new code has more test cases... but may also be yet incomplete.

The more specific things we know broke, the more we can either fix right off or replace back with the old code (with tests this time) until the new code works better. --brion (talk) 01:27, 6 October 2011 (UTC)[reply]

That's just gobsmacking. So much has been broken today that it's very obvious none of the developers have a clue about testing. Malleus Fatuorum 01:31, 6 October 2011 (UTC)[reply]

mw:Manual:JavaScript_unit_testing Your patches and bug reports are welcome! I'll certainly agree that we've had.... basically NO good testing for many years, but there've been big improvements this year so far. I wouldn't say it's ideal since, you know, it's not, so I assume that telling the truth is better than just pretending it's perfect? --brion (talk) 01:38, 6 October 2011 (UTC)[reply]

Honesty is certainly a welcome change, but surely the first rule of software development in the 21st century is to consider the tests before implementing the software. There is absolutely no excuse for today's debacle. Malleus Fatuorum 01:49, 6 October 2011 (UTC)[reply]

I can't go back in time, so I'll just hand you this thread. --brion (talk) 01:56, 6 October 2011 (UTC)[reply]

Note that I'd recommend we go back to the old sorting code until the new code gets more thoroughly resolved, but we still need to know things that broke so we can actually go test and fix them. Expect a flip back to the old sorting code tomorrow if nobody beats me to it. --brion (talk) 02:37, 6 October 2011 (UTC)[reply]

I think the suggestion being made is that you test first, see what breaks in a test environment, fix them, and then roll out. I would have thought this would be pretty much standard procedure, but I guess Wikipedia always has to be different...--Kotniski (talk) 07:06, 6 October 2011 (UTC)[reply]

Are there in fact remaining issues with sortable tables? Everything I can find cited on this page is listed as having now been fixed. If there are still other problems I'll go ahead and flip back the old code pending fixes; otherwise I suppose we'll leave it in place. --brion (talk) 18:57, 6 October 2011 (UTC)[reply]

Another issue is when clicking on the header cell of an unsortable column in a sortable table, the sort image of the last sorted column reverts to the neutral sort image, so you can no longer see in which direction and on which column the table is sorted. Pretty minor, but there it is. — Bility (talk) 22:08, 6 October 2011 (UTC)[reply]

Sortable tables still don't seem to be working. See, for example, List of federal judges appointed by Barack Obama#Courts of Appeals. The code says "sortable wikitable" and, until a few days ago, you could sort the columns without any difficulty. Now, the sort buttons don't even appear. --Lincolnite (talk) 05:18, 7 October 2011 (UTC)[reply]

References break sorting. See [4] and see how CU stats sort correctly in the September column. Then see [5] (desired revision) and notice how they don't. –xeno^talk 17:23, 7 October 2011 (UTC)[reply]

You need to specify the attribute data-sort-type on table columns, when you are using mixed content in table cells. Unfortunately, it seems someone did not deploy the change, or perhaps it's just a setting of the servers, that actually allows "data-*" on wikimedia wikis. I have create bugzilla:31527 for this problem. The tablesorter should not have been deployed without this data attribute being allowed. —TheDJ (talk • contribs) 13:39, 8 October 2011 (UTC)[reply]

Rollback WM

Resolved

– It's going far smoother than the 1.17 upgrade earlier this year, so we don't expect to roll back.

Just a question really, given the sudden swath of issues described in many sections above, is there any viability in rolling back to the previous version of Wikimedia software until such a time the major glitches are fixed? The Rambling Man (talk) 20:30, 5 October 2011 (UTC)[reply]

We do MW upgrades 1 to 3 times a year typically. They always have some teething problems that last a few days. However, as long as most of the content is usable for most readers, it is unlikely that a blanket rollback would happen. Developers are of course working to isolate the broken bits and either fix or revert the individual issues. Dragons flight (talk) 20:49, 5 October 2011 (UTC)[reply]

Cool, I'm certainly not trying to be difficult, it's just that I've never known Wikipedia to be so broken. Is there a timetable to correct the above issues, existing bugs etc? Sorry if I'm asking stupid questions but I am a mere user of Wikipedia and want to understand when it'll be as good as it was a few days ago. The Rambling Man (talk) 20:51, 5 October 2011 (UTC)[reply]

Based on past experience, most reader visible bugs should be cleaned up within a day or two. Bugs for editors may take a few more days if they are in Mediawiki's core, and up to a few weeks if they are in third party scripts (e.g. Huggle, Twinkle, etc.) since those depend on third-party developers that often don't have the time / resources of Wikimedia staff developers. A small fraction of the bugs may linger for a long time if they are either hard to diagnose (e.g. intermittent failures, specific browser versions) or if they interact with other software in a way that makes them both hard to fix and impossible to rollback without breaking other things. It is hard to put a time table on any specific bug, but most things should be back to normal within several days. Dragons flight (talk) 21:59, 5 October 2011 (UTC)[reply]

Ok, that's appreciated. I know how it goes, I'm in the mainstream industry, but where I am, we do tend to do a lot more beta testing with real end-users. Perhaps I've missed other WM updates where similar has occurred, but with a website that attracts the traffic we do, a lot of these bugs should have been ironed out before the update. But then all project managers would say that, wouldn't that? The Rambling Man (talk) 22:03, 5 October 2011 (UTC)[reply]

Just out of interest, can anyone link me to the discussions about issues when we moved to WM 1.17, just as a comparison, to see the number and nature of issues? Cheers. The Rambling Man (talk) 22:13, 5 October 2011 (UTC)[reply]

Wikipedia:Village pump (technical)/Archive 85#MediaWiki 1.17 release is tomorrow (hopefully) would be a good starting point. — Edokter (talk) — 22:22, 5 October 2011 (UTC)[reply]

{{REVISIONUSER}} not working all the sudden

Reported: Revision information not rendered in edit notices

Extended content

See Template:Editnotices/Page/Pingan International Finance Center. It works when I preview the notice, but not when I try to edit the article. Checked another edit notice I made a while back and the same thing is happening there. Beeblebrox (talk) 20:53, 5 October 2011 (UTC)[reply]

If you mean it should the name of the user viewing it, then that has been fixed. It was always considered a bug. Let me dig up some details. ---— Gadget850 (Ed) ^talk 21:17, 5 October 2011 (UTC)[reply]

Well fixed, but not fixed. Yes, the prior behavior was considered a bug, but the current behavior for REVISIONUSER in an edit notice seems to be to display an empty string, e.g. top of this page. I would consider that to also be a bug. If I understand correctly, REVISIONUSER is supposed to display the name of the user who saved the topmost revision. Dragons flight (talk) 21:28, 5 October 2011 (UTC)[reply]

bugzilla:31398. Dragons flight (talk) 23:00, 5 October 2011 (UTC)[reply]

And Template:Bug started this. ---— Gadget850 (Ed) ^talk 23:53, 5 October 2011 (UTC)[reply]

Well I'm glad others have noticed this, because I spent an unfruitful hour last nigh trying to fix my talk page edit notice, thinking it was due to vandalism to my page. --Kudpung กุดผึ้ง (talk) 00:09, 6 October 2011 (UTC)[reply]

I added a notice to WP:Editnotice. ---— Gadget850 (Ed) ^talk 02:56, 6 October 2011 (UTC)[reply]

Just make sure it's not an editnotice.

→Σ τ c. 04:25, 6 October 2011 (UTC)[reply]

Some people were relying on the previous behaviour of {{REVISIONUSER}} - see, for example, MediaWiki talk:Histlegend#New tool for consideration. --Redrose64 (talk) 10:15, 6 October 2011 (UTC)[reply]

The same thing is happening to my editnotice for my userpage. HurricaneFan 25 17:25, 6 October 2011 (UTC)[reply]

This has also broken all the policy and guideline editnotices, which use {{policy-guideline-editnotice}}, which uses {{REVISIONUSER}}. →Dynamic|cimanyD← (contact me) 20:03, 6 October 2011 (UTC)[reply]

Fixed by Σ. →Dynamic|cimanyD← (contact me) 12:11, 7 October 2011 (UTC)[reply]

logs

Resolved

– invalid

Extended content

I swear whenever a page gets moved, the log gets noted in the page that gets moved as well as the redirect. Looking at the history of Soda and candy eruption, there is no log of moves unless you look at the reirects only. Have I missed something? See here and here. Simply south...... creating lakes for 5 years 20:57, 5 October 2011 (UTC)[reply]

The move is noted in the edit summary on both pages, but there's only one log entry at the original destination. That was the case before too. Reach Out to the Truth 03:08, 6 October 2011 (UTC)[reply]

The Wikipedia Loves Libraries banner

The Wikipedia Loves Libraries banner is superimposing over other things at the tops of pages, such as geographic co-ordinates and the link to Help:User contributions on User pages. I'm using Firefox 7. The Mark of the Beast (talk) 22:17, 5 October 2011 (UTC)[reply]

Where are you seeing this banner? Is it rotating along with the maintenance message (in which case it might just not be showing for me right now?) or is it only in particular places? --brion (talk) 01:31, 6 October 2011 (UTC)[reply]

I see the WLL banner, but I'm not seeing it over other things. Maybe you have a gadget or other custom JS interfering? — ☠MarkAHershberger☣ (talk) 05:19, 6 October 2011 (UTC)[reply]

I am not using any gadgets, and I have not customized anything. The Mark of the Beast (talk) 05:41, 6 October 2011 (UTC)[reply]

What pages are you seeing the problem on? — ☠MarkAHershberger☣ (talk) 05:46, 6 October 2011 (UTC)[reply]

As I said above, on pages with geographic coordinates, and User contribution pages. Plus I keep hiding the damn banner and it keeps coming back anyway. The Mark of the Beast (talk) 06:45, 6 October 2011 (UTC)[reply]

Would you mind linking to a couple of those specific pages that you actually see a problem on? Also, what browser & browser version are you running? --brion (talk) 23:39, 6 October 2011 (UTC)[reply]

I would, but I've hidden the banner and now it seems to be actually hidden. If it shows up again, I will do that. I'm using Firefox 7. The Mark of the Beast (talk) 05:46, 7 October 2011 (UTC)[reply]

Funny, now that I've said that, it's back. See [6] and [7]. The Mark of the Beast (talk) 05:47, 7 October 2011 (UTC)[reply]

Signpost

With all the other issues happening, I realize this is minor. But has anyone else noticed that EdwardsBot didn't deliver the Signpost this week? Maile66 (talk) 23:51, 5 October 2011 (UTC)[reply]

Yeah, I noticed that as well -- seems like all the bots are put on hold ATM, pending the complete roll out of 1.18. Sp33dyphil ^{"Ad astra"} 02:07, 6 October 2011 (UTC)[reply]

Resolved

EdwardsBot has delivered the Signpost.

Namespace in Contributions

Resolved

– duplicate of #Namespace option on contribution history

Extended content

Selection by namespace has disappeared from Special:Contributions. Please re-instate instantly. There is a tick box labelled "Deleted only" - what is it supposed to do? — [[::User:RHaworth|RHaworth]] (talk · contribs) 00:28, 6 October 2011 (UTC)[reply]

Seconded - what happened? This is somewhat essential for admins! ThanksSkier Dude (talk) 00:35, 6 October 2011 (UTC)[reply]

See #Namespace option on contribution history above. --brion (talk) 01:32, 6 October 2011 (UTC)[reply]

Someone please add a notice on top of Help:User contributions: there is a slight chance some people would look there before posting here. — AlexSm 01:57, 6 October 2011 (UTC)[reply]

A short notice in MediaWiki:Sp-contributions-explain would also help to avoid confusion for a lot of people. — AlexSm 02:17, 6 October 2011 (UTC)[reply]

Good idea.

Done Anomie ⚔ 03:36, 6 October 2011 (UTC)[reply]

The box for deleted-only contributions was already there, but I've never figured out how it's helpful. Nyttend (talk) 04:09, 6 October 2011 (UTC)[reply]

The "deleted-only contributions" is for edits where RevDel was used. עוד מישהו Od Mishehu 08:59, 6 October 2011 (UTC)[reply]

Is using an ombox really necessary? That just makes it very distracting. I suggest changing it to something less attention-grabbing like "Note: The option to filter the contributions list by namespace has been removed in the upgrade to MediaWiki 1.18. Discussion is ongoing at Wikipedia:Village pump (technical)#Namespace option on contribution history and Template:Bug." →Σ τ c. 04:26, 6 October 2011 (UTC)[reply]

Who moved the feedback section?

Reported: … at top of page in colognblue skin — ☠MarkAHershberger☣ (talk) 05:11, 6 October 2011 (UTC)[reply]

Extended content
I use the Cologne Blue skin for WP. Yesterday, I think it was, the useless RATE THIS PAGE gibberish started appearing at the TOP of the page instead of the bottom, in all its real estate hogging glory. Where was the consensus for this?!? Or how does this bug get undone??? Carrite (talk) 04:24, 6 October 2011 (UTC)[reply]

toolbar buttons not working on IE?

Resolved

– Now deployed —TheDJ (talk • contribs) 13:15, 8 October 2011 (UTC)[reply]

Reported, fixed, not yet deployed: toolbar buttons not working — ☠MarkAHershberger☣ 14:57, 6 October 2011 (UTC)[reply]

Extended content

The toolbar buttons (signature, markup, etc.) aren't working for me on IE. Is anyone else experiencing this? --Ixfd64 (talk) 04:54, 6 October 2011 (UTC)[reply]

toolbar buttons not working — ☠MarkAHershberger☣ (talk) 05:14, 6 October 2011 (UTC)[reply]

They don't work for me either and apparently don't work in IE 7 and 8 period (some else also tried). See the discussion above. Voceditenore (talk) 07:47, 6 October 2011 (UTC)[reply]

Same for me, using IE 8. Ruigeroeland (talk) 08:02, 6 October 2011 (UTC)[reply]

No such special page

Reported: no such special page -- ☠MarkAHershberger☣ 15:13, 6 October 2011 (UTC)[reply]

Extended content

Clicking on a Recent changes entry with the URL http://en.wikipedia.org/w/index.php?title=Sameera_Mallawarachchi&curid=33321830&action=history caused an unexpected response. The link is to an article I had just deleted. Strangely, the link shows a Wikipedia page with a title of Error, an article-like title of No such special page and content of You have requested a special page that is not recognized by Wikipedia. A list of all recognized special pages may be found at Special:Specialpages. If the &curid field is removed, it responds more sensibly showing deletion information.

I don't know if this is new behavior since the Wikimedia upgrade, but it seems a bit ungraceful. Either it should ignore the &curid= and report the page deletion, or say that the specific history items is not available. Naturally it should not mention anything about a Special: namespace operation. —EncMstr (talk) 09:22, 6 October 2011 (UTC)[reply]

How unusual; I've never seen such a thing before. Nyttend (talk) 10:50, 6 October 2011 (UTC)[reply]

subpage for new code deployment

It looks like there are going to be a lot of issues that need to be worked through. Should we create a separate subpage for reporting issues related to this deployment? John Vandenberg ^(chat) 09:37, 6 October 2011 (UTC)[reply]

Tab bars and apostrophes

Can someone maybe help out with a bug in a template? I've been rolling out {{start tab}} as a generic implementation for all these tab bars that are so popular with WikiProjects. See the one on Wikipedia:WikiProject Israel for an example: one central tab template which modifies its appearance automatically based on the page it's transcluded to. The problem is that it doesn't seem to work properly if the page title has an apostrophe in it: see Wikipedia:Romanian Wikipedians' notice board, where the current tab isn't styled differently. {{start tab}} draws its detection logic from {{tab}}, so that'd be the most likely place to look for a fix. Any thoughts? Chris Cunningham (user:thumperward) - talk 09:48, 6 October 2011 (UTC)[reply]

{{FULLPAGENAME}} outputs the apostrophe as "'" (the HTML numeric entity for the apostrophe character). In the actual HTML output, Tidy seems to change this to the apostrophe character, but that hasn't happened by the time it gets to your {{#ifeq:}}. If you pass the page name in your {{start tab}} invocation with apostrophes replaced by "'", it should work. BTW, the same happens for double-quotes (by """) and ampersands (by "&"). Anomie ⚔ 11:07, 6 October 2011 (UTC)[reply]

Awesome: works perfectly. Meh, entities. Chris Cunningham (user:thumperward) - talk 13:19, 6 October 2011 (UTC)[reply]

Wikipedia Vulnerable for Attack

FYI I guess you know but, anyway : [removed per WP:BEANS] 87.64.24.15 (talk) 11:38, 6 October 2011 (UTC)[reply]

This kind of thing should be reported to security

wikimedia.org. I'm emailing them now. MER-C 11:46, 6 October 2011 (UTC)[reply]

Done. Thanks, but please avoid posting such information in public fora before the problem(s) are fixed. MER-C 11:54, 6 October 2011 (UTC)[reply]

Problem with Internet Explorer

Reported: 1.18 Causes IE8 to crash — ☠MarkAHershberger☣ 14:47, 6 October 2011 (UTC)[reply]

Extended content

When opening a page on the English wikipedia with Internet Explorer, an error message appears and the page has to be re-opened. When making changes and visualising them, the changes are lost, so that I had to make the changes again and to save them without visualising them.

Please solve this issue. --Réginald alias Meneerke bloem (To reply) 12:24, 6 October 2011 (UTC)[reply]

[[File:foo.ogg|noicon]]: noicon ignored

Reported: Noicon parameter for audio files is broken — ☠MarkAHershberger☣ 14:47, 6 October 2011 (UTC)[reply]

Extended content
It seems the parameter `\|noicon` in the code `[[File:Accordian chords-01.ogg\|noicon\|right]]` is no longer observed; vide: noicon The template {{Listen/core}} issues this parameter and ignoring it changes the appearance of {{Listen}}. What caused this change and how can it be reverted? -- Michael Bednarek (talk) 13:27, 6 October 2011 (UTC)[reply]

Fix is queued up in trunk: mw:Special:Code/MediaWiki/99167. --brion (talk) 23:35, 6 October 2011 (UTC)[reply]

Yet another problem caused by the archiving — something wrong in the software about section editing

Hello,

Following of this discussion.

The discussions get stupidly archived by date, even when they are still very recent and very relevant. And so the links to the discussions get broken. And the archived page tells not to edit the page, but to start a new discussion if one wants to say something.

On the page Wikipedia talk:Manual of Style, there was the section Making MOS:ENDASH happen. I clicked its edit link. I landed into the edit form of the section Specific–vague axis in choosing article titles, a completely different section !

What happened ? The section I intended to edit was still on the main page, but someone had archived some other section(s), and so my intended section's order number had changed. And the software, not very clever, uses only the section's order number to identify a section, and believes this is sufficient.

There is something wrong in the software about section editing. The software has to handle sections better than that !

--Nnemo (talk) 14:31, 6 October 2011 (UTC)[reply]

liquidthreads problem at en.wiktionary

Reported: Bugzilla:31251 — ☠MarkAHershberger☣ 14:41, 6 October 2011 (UTC)[reply]

Extended content

Hi, on en.wiktionary, I see "my new messages (1)" in bold, but when I click on it, it says "There are no new messages for you.".

Is there a way to unbold the link, since there aren't actually any messages there? -- Liliana-60 (talk) 14:34, 6 October 2011 (UTC)[reply]

No section edit links

Resolved

{{resolved|invalid}} — ☠MarkAHershberger☣ 17:31, 6 October 2011 (UTC)[reply]

See Jesse Jackson. There are no section edit links and I tried, but couldn't find a __NOEDITSECTION__ anywhere (I gave up after a while). Anyone else care to check? Thanks. howcheng {chat} 16:42, 6 October 2011 (UTC)[reply]

They are showing for me. –Drilnoth (T/C) 16:50, 6 October 2011 (UTC)[reply]

I see them too. Though one one occasion, I did see them disappear from another article as well, only to reappear after an edit. — Edokter (talk) — 16:53, 6 October 2011 (UTC)[reply]

...and now they're back. I'll chalk it up to a fluke, then. howcheng {chat} 16:56, 6 October 2011 (UTC)[reply]

This happened to me yesterday as well, at WP:AN (Wikipedia talk:AN#Section edit buttons gone?). They re-appeared after I made another edit to the page. –xeno^talk 17:01, 6 October 2011 (UTC)[reply]

This is happened again on 2PM page.--Lpmfx (talk) 19:11, 6 October 2011 (UTC)[reply]

This is not 'invalid' but I'm not sure how to reproduce. See below subsection. The edit links re-appear upon subsequent edits to the page. –xeno^talk 19:20, 6 October 2011 (UTC)[reply]

We figured this one out at last. The secret to reproduce was something like this:

go to a printable page
if necessary, force an action=purge on the printable URL to make sure you've recached
go back to the non-printable view

Things like the printable view or viewing when you don't have edit permissions had forced the section edit links off, but because _most_ code paths no longer actually turn section edit links off it was colliding in the parser cache with the regular version.

The fix was to update things a little more so that when rendering for output that shouldn't have section edit links, we go ahead and prep them in the cached output but then don't include them at final output. This was already being used for, for instance, letting people with section edit links disabled not have to split the cache.

You might have to null-edit or action=purge affected pages, but they'll all clear themselves out over time. :) --brion (talk) 01:05, 8 October 2011 (UTC)[reply]

Can't edit sections of semiprotected articles

I now do not see an "edit" link next to the section titles of semiprotected articles, like Great Famine (Ireland), or Barack Obama, although I am logged in. If it matters, I am using the old-style Monobook view. Comet Tuttle (talk) 19:14, 6 October 2011 (UTC)[reply]

Combined with #No section edit links. –xeno^talk 19:20, 6 October 2011 (UTC)[reply]

Tables now going "off screen" (and no scroll bar in Internet Explorer)

Reported: wider table columns causing problems in IE — ☠MarkAHershberger☣ 17:31, 6 October 2011 (UTC)[reply]

Extended content

Something has happened to the sortable table columns. They have become much wider, leading the table at Snooker world ranking points 2011/2012 to go off the side of the page. In Firefox this isn't so bad because you can at least scroll along. However, in Internet Explorer 8 it is impossible to even scroll along meaning we lose half the table. I can see the whole chart in IE8 if I set my scale to 75% (on a 1024x768 screen), but at 100% some of the columns off the screen and it doesn't have a scroll bar at the bottom to move along like in Firefox. I'm sure our table isn't the only one affected on Wikipedia if the columns have been widened (which I didn't think was necessary to be honest because the chart looked better when it was fully on the page), but by not being able to scroll along in IE it has become virtually useless. It would be great if someone could address the IE issue. Betty Logan (talk) 17:14, 6 October 2011 (UTC)[reply]

You could wrap it in an overflow div, or remove the nine empty columns. — Bility (talk) 17:16, 6 October 2011 (UTC)[reply]

Diff Categorizer Gadget

We are looking for some technical feedback on a gadget for letting users categorize edits. Please have a look at the gadget proposals page for details. We will be grateful for any comments. Also look at the user instructions. Fikonträd (talk) 17:35, 6 October 2011 (UTC)[reply]

Block log entry behaving erratically

Resolved

– Fixed by bugzilla:31352.

Extended content
This entry of an 2008 block (presumably for notation purposes) shows an expiry time in 2011. Moreover, the expiry time shown seems to be actually the current time - it actually changes over time. T. Canens (talk) 17:41, 6 October 2011 (UTC)[reply]

Parentheses pipe shortcut doesn't work in <ref>

Wikipedia allows the shortcut of simplifying the piping of wikilinks containing parentheses, for example, ''[[Nature (journal)|Nature]]'' (Nature) can be simplified to ''[[Nature (journal)|]]'' (Nature). This works inside templates, including most importantly the various {{cite}} templates.

But it doesn't work when nested in a <ref>. For example, the reference

{{cite journal |author=Joe Shmoe |year=2011 |title=Piped Wikilinks with parentheses |journal=[[Nature (journal)|]] |volume=333 |issue=1 |pages=551–552}}

displays correctly in running text as

Joe Shmoe (2011). "Piped Wikilinks with parentheses". Nature. 333 (1): 551–552.

and incorrectly as a footnote.^[1]

Bare ''[[Nature (journal)|Nature]]'' displays OK in a <ref>^[2] — but ''[[Nature (journal)|]]'' displays in a <ref> as if everything but the apostrophes were nested in an <nowiki></nowiki>.^[3]

Is this a known issue and are there any plans to fix it? —Anomalocaris (talk) 18:43, 6 October 2011 (UTC)[reply]

^ Joe Shmoe (2011). "Piped Wikilinks with parentheses". [[Nature (journal)|]]. 333 (1): 551–552.
^ Nature
^ [[Nature (journal)|]]

This is a very old known bug: bugzilla:2700. Not very high priority, apparently. :) --brion (talk) 18:51, 6 October 2011 (UTC)[reply]

Losing my editing when I go to other pages

Resolved

– Duplicate of #Change in behavior of browser "Back" button

(sounds like the same issue) — ☠MarkAHershberger☣ 20:24, 6 October 2011 (UTC)[reply]

It may be resolved in the sense that we know it's a duplicate of another issue, but it is not resolved in the normal sense, i.e. that it is fixed. —Anomalocaris (talk) 20:55, 7 October 2011 (UTC)[reply]

Extended content

Argh! For years, I would edit a page, click "Preview", and click a link in the text I just typed to make sure it didn't go to a disambig page or the wrong page; or would research a little more on the topic of the link; then I would click my browser's "Back" button until I was back on the editing page. This all worked until today! My editing changes are lost when I get back to the editing page, as though I had *just* clicked the "edit" link in the section header and had not done any typing yet. What changed? Comet Tuttle (talk) 18:43, 6 October 2011 (UTC)[reply]

Thanks, I was about to report this same issue! The crazy thing is, it's intermittent. I just edited Parentheses pipe shortcut doesn't work in <ref> above, and went to Show preview and back many times and never lost anything, but in editing other articles, I've found myself in Comet Tuttle's situation several times in the past day or two. —Anomalocaris (talk) 18:53, 6 October 2011 (UTC)[reply]

Are either of you running twinkle? Because since I turned it off, I seem to be able to edit as normal. DrKiernan (talk) 19:00, 6 October 2011 (UTC)[reply]

I'm not. Here it's Firefox 3.6.23 under Windows Vista with AdblockPlus and various other plugins that I don't think will modify the page being viewed. I'm set to Monobook, old school style. Comet Tuttle (talk) 19:11, 6 October 2011 (UTC)[reply]

I don't think so, but what is twinkle and how do I know if I'm running it? —Anomalocaris (talk) 19:21, 6 October 2011 (UTC)[reply]

WP:TWINKLE. Check the the "Twinkle" gadget in the Gadgets section of your Preferences page. --Tagishsimon (talk) 19:35, 6 October 2011 (UTC)[reply]

I don't use Twinkle; in fact I don't use any Gadgets. —Anomalocaris (talk) 20:14, 6 October 2011 (UTC)[reply]

Oh dear, it was going so well but now it's just happened again. DrKiernan (talk) 19:46, 6 October 2011 (UTC)[reply]

See the comment Problem with Internet Explorer I wrote earlier today. The bug is identified and has still to be solved. --Réginald alias Meneerke bloem (To reply) 19:26, 6 October 2011 (UTC)[reply]

Réginald alias Meneerke bloe, your Bugzilla note says "When opening a page on the English wikipedia with Internet Explorer, an error message appears and the page has to be re-opened. When making changes and visualising them, the changes are lost, so that I had to make the changes again and to save them without visualising them." I'm sorry for your difficulties, but my problem is different. I'm using Firefox, and I don't get any error message. My changes just disappear, both in the main editing window and in the edit summary. —Anomalocaris (talk) 20:00, 6 October 2011 (UTC)[reply]

I don't get a problem, but I open the link with right click and Open in new window, then before I read it, I click Back on the first window. I'm just naturally suspicious... This is in Firefox. Peridon (talk) 16:38, 8 October 2011 (UTC)[reply]

Section erroneously hidden

The section #Improved diff view not working has been hidden in side the extended content of the previous section, #Wikilinks in diffs no longer clickable, which is listed as fixed. However, they are different (no pun intended) problems, and improved diff view is still not working. --Stfg (talk) 18:58, 6 October 2011 (UTC)[reply]

Now dealt with. Thanks, Optimist on the run. --Stfg (talk) 21:09, 6 October 2011 (UTC)[reply]

preloaded deletion reasons

Resolved

– duplicate of #Old block reason doesn't pre-load

— ☠MarkAHershberger☣ 19:43, 6 October 2011 (UTC)[reply]

Extended content
Normally, when deleting a CSD-tagged page the reason in the tag is automatically preloaded when one goes to delete the page. Doesn't seem to be happening today. Beeblebrox (talk) 19:30, 6 October 2011 (UTC)[reply]

Hardly extended content, but whatever. Is it going to be fixed or what? Also, did the new software solve any problems, or is it specialized to only cause them? Beeblebrox (talk) 23:17, 6 October 2011 (UTC)[reply]

The biggest improvements in MW1.18 are for wikis in languages other than english. You can judge for yourself whether any of the other changes are of interest to you; but I'd suggest that [8], [2] and [3] are probably obvious candidates to be qualified as 'improvements'. Happy‑melon 10:08, 7 October 2011 (UTC)[reply]

I can't really make any sense out of those three links, so I have no idea whether they represent improvements or not, but I'm willing to take your word for it. Was just venting a bit as there seem to be a lot issues springing up that apparently were not anticipated. Beeblebrox (talk) 19:15, 7 October 2011 (UTC)[reply]

Check out what's new for a more readable list of improvements. — ☠MarkAHershberger☣ 22:34, 7 October 2011 (UTC)[reply]

I've been getting this - and it coincides with times when my compressing of 'discussion' to 'talk' doesn't come in (it's some .js thing - no idea how it works), and the Twinkle buttons don't arrive either. I've been reloading the window to get things back - sometimes with Ctrl-Reload if it doesn't work the first two times (usually does). Damned irritating. Peridon (talk) 16:44, 8 October 2011 (UTC)[reply]

Category bloating

Hi. I noticed today that the categories have now got wider spacing between them. I just changed my skin to Cologne Blue and its buggered the alignment and looks ridiculous at the article now features further down with an ugly gap at the top. Especially for articles with a lot of categories and wiki links it looks horrendous (check out Austria in Cologne Blue for example).♦ Dr. Blofeld 21:02, 6 October 2011 (UTC)[reply]

I noticed that too, it seems like there's too much space between lines and between links, even on regular Vector skin. --Funandtrvl (talk) 21:14, 6 October 2011 (UTC)[reply]

Can we

a] Go back to the neat category alignment
b] Modify the Cologne blue skin to place categories and interwiki links at the foot of the page instead of at the top?

♦ Dr. Blofeld 21:18, 6 October 2011 (UTC)[reply]

- All the skins now have an annoying amount of extra spacing, although it does look particularly annoying for skins with cats at the top. –Drilnoth (T/C) 21:39, 6 October 2011 (UTC)[reply]

As I mentioned in the 1.18-bug section above, the new spacing - while the "no wrap" part is good - makes some articles look horrendous. - The Bushranger _{One ping only} 22:22, 6 October 2011 (UTC)[reply]

See #Categories are surrounded by much more space, and they don't wrap from line to line for a chunk of CSS to restore something like the old behaviour. --Redrose64 (talk) 11:38, 7 October 2011 (UTC)[reply]

Sorting update question

Under the old table sorting feature, the sorting image could be placed under the column heading with a line break (<br>). This was useful for keeping column width in large sortable tables as slim as possible. After the recent update the line break has no effect and the sorting image is now horizontally aligned to the right and vertically aligned to the center of the top row. Under the new update, is it possible to place the sorting image below the column heading? – Zntrip 22:24, 6 October 2011 (UTC)[reply]

Personally I prefer the fixed position of the user interface element actually. —TheDJ (talk • contribs) 12:34, 7 October 2011 (UTC)[reply]

But regardless, is there are way to change it? Like I said, it takes up a lot of space lengthwise that some tables can't spare; for such tables width usually isn't an issue, so there is a solution if the sorting image can be reoriented. Additionally, uniformity can still be maintained within the table. – Zntrip 20:31, 7 October 2011 (UTC)[reply]

autoblocking weirdness

See User talk:Esoglou#Unblock-auto. User was somehow autoblocked for the mere act of logging into an old sock account to check its watchlist. Hasn't edited with it since late 2009. Beeblebrox (talk) 23:22, 6 October 2011 (UTC)[reply]

Turning off fade-in/out effect

== watchlist javascript "upgrade" ==

When I expand/contract grouped watchlist edits now, I get a fancy fade-in/fade-out effect. This might look pretty, but it just seems to waste time. Is there a way I can shut this off? The un-pretty method was fine with me... --Fru1tbat (talk) 23:41, 6 October 2011 (UTC)[reply]

Try setting jQuery.fx.off in your common.js:

$.fx.off = true; //turn off all jQuery animations

— AlexSm 01:25, 7 October 2011 (UTC)[reply]

Nifty. I was a bit annoyed by the watch/unwatch "slide" effect, this took care of that. Thanks! - The Bushranger _{One ping only} 01:29, 7 October 2011 (UTC)[reply]

Sorry, my posts tend to come out a bit snarkier than I realize when I'm overworked. Thanks for the tip, though. Works like a charm! --Fru1tbat (talk) 01:58, 7 October 2011 (UTC)[reply]

Gadget time! — Edokter (talk) — 11:52, 7 October 2011 (UTC)[reply]

Gadget added. —TheDJ (talk • contribs) 12:32, 7 October 2011 (UTC)[reply]

Also of interest: bugzilla:30401. — Edokter (talk) — 15:26, 7 October 2011 (UTC)[reply]

Another option: mw:Snippets/Toggle animations. Helder 01:38, 8 October 2011 (UTC)[reply]

MathBot is broken

Resolved

Among the multitude of borked bots on account of 1.18, User:MathBot is one I'd like to draw particular attention to - since it's important to the workings at AfD. The bot's owner doesn't appear to check in too often, is there anyone else who can fix at least the AfD-related parts of its operation? (It's creating the new AfD logs just fine, but claiming the old logs all have "0 open/0 closed/0 total" AfDs in them, which makes it troublesome to pinpoint AfDs that are "stale" and need closing/relisting in those logs). - The Bushranger _{One ping only} 00:39, 7 October 2011 (UTC)[reply]

MathBot's AfD function is working now. Thanks to whoever fixed it. :) - The Bushranger _{One ping only} 15:40, 7 October 2011 (UTC)[reply]

Wikipedia articles not on Wayback

I find Wikipedia's co-founder Larry Sanger complaining on Twitter that this page prevents old versions of Wikipedia articles from appearing on Wayback. (BTW, it occurs to me that maybe persons of youngness might fail to recognize the obvious humorous allusion to Rocky and Bullwinkle....) The concern expressed in the file is Wikipedia user pages, but apparently it affects everything on Wikipedia including articles. Should this be done something about? Michael Hardy (talk) 01:14, 7 October 2011 (UTC)[reply]

No, we regularly upload full database dumps to archive.org. which is far far better than crawling the site. ΔT _{^{The only constant}} 01:16, 7 October 2011 (UTC)[reply]

There is another person also complaining at the archive.org forum about this problem for another website. Perhaps archive.org changed their configuration ? —TheDJ (talk • contribs) 12:25, 7 October 2011 (UTC)[reply]

I am looking for a deleted article, even though I regularly d/l dumps, it would be far easier to use Wayback than trawl through old dumps, possibly having to spend 8 hours grabbing each, and about an hour search time for every refinement of the search terms. But finding Sanger complaining about Wikipedia on Twitter is hardly a surprise.

Rich Farmbrough, 16:15, 7 October 2011 (UTC).[reply]

Indeed, I make many quite legitimate complaints about Wikipedia on Twitter. You're welcome to follow me if you find the thought amusing.

OK, I'll simply ask: why was there only one snapshot of http://en.wikipedia.org/ in July, and why was that the last one? http://wayback.archive.org/web/*/http://en.wikipedia.org --Larry Sanger (talk) 19:38, 7 October 2011 (UTC)[reply]

Huh--the problem may be with archive.org. http://wayback.archive.org/web/*/http://www.citizendium.org --Larry Sanger (talk) 19:48, 7 October 2011 (UTC)[reply]

NOW, I find the thought amusing :D sorry, couldn't help saying that. —TheDJ (talk • contribs) 20:28, 7 October 2011 (UTC)[reply]

What bit of the robots.txt looks like it excludes the Internet Archive bot? Only reference I see for ia_archiver is commented out, and that's to try to exclude the User namespaces only. --brion (talk) 00:55, 8 October 2011 (UTC)[reply]

I don't know the answer, Brion, but look at http://web.archive.org/web/20110721203834/http://en.wikipedia.org/w/index.php . I'm just quoting archive.org: "Page cannot be crawled or displayed due to robots.txt." That's what made me think there was something wrong with robots.txt. But I don't know what bit excludes the bot, if any. The problem indeed could be with archive.org, but right now, it looks like nobody knows why that "page cannot be crawled" message is appearing. --Larry Sanger (talk) 01:04, 8 October 2011 (UTC)[reply]

We exclude everything of the form /w/ from crawling because those are for active scripts. You should look for pages of the form http://en.wikipedia.org/wiki/ ... As I recall (from a couple years ago), the Internet Archive used to have a multi-month delay between when something would be crawled and when it would appear in their online archive. If that is still the case then it could explain the lack of recent records. Dragons flight (talk) 04:58, 8 October 2011 (UTC)[reply]

Well, that completely clears that up. I'll post a Twitter correction. --Larry Sanger (talk) 18:57, 8 October 2011 (UTC)[reply]

Banners

Just lately I'm being assaulted by banners, usually asking me to share my story for the 2011 fundraiser, but occasionally it's something about libraries or a survey about the mobile site, although these two are relatively infrequent. Clicking [X] helps for a moment, but the banner usually reappears a few pages later. Is there a way to block these? I didn't see anything under the gadgets menu in preferences. I may or may not have had something in my monobook.js that usually hid them, which may or may not have been disabled by the recent server upgrade. Thanks. --Bongwarrior (talk) 02:33, 7 October 2011 (UTC)[reply]

Its gotten so bad with all of the annoying global notices using CentralNotice that I added a rule about it to Adblock Plus. ΔT _{^{The only constant}} 02:38, 7 October 2011 (UTC)[reply]

Agree with Bongwarrior, but I don't think the upgrade caused this – I've never had any js to stop banners and it's never been this bad. The problem is I don't necessarily want to hide all notices, I just want them to stay away for more than a minute once I've clicked on the [X]. Jenks24 (talk) 02:44, 7 October 2011 (UTC)[reply]

I'd like to figure out a way to get rid of them too. I think, back when they had the Big Honking Banners with the pictures of people in them, there was a checkbox in Preferences that did it, but I can't find it now... - The Bushranger _{One ping only} 02:43, 7 October 2011 (UTC)[reply]

There was. After the fundraiser ended, it was removed "until next year". Anomie ⚔ 02:48, 7 October 2011 (UTC)[reply]

(EC x2) This is getting aggravating and i have come to the VPT to find if there is a solution. Before, when I closed it once, it would stay closed, but it seems to be ignoring that this time. hbdragon88 (talk) 02:44, 7 October 2011 (UTC)[reply]

Same problem for me. In fact a banner I've repeatedly clicked away popped up on this edit page. The behavior seems random and buggy. I've also noticed that when a banner you've clicked away reappears, if you navigate to another page without clicking it away again, chances are it won't be on the new page. They pop up randomly, it seems. Pfly (talk) 03:47, 7 October 2011 (UTC)[reply]

It looks like the problem is that they have the banner marked as "not a fundraising banner", but the 'hide' link is for hiding a fundraising banner. See here. It's probably intermittent because other banners in the rotation aren't broken. Anomie ⚔ 04:01, 7 October 2011 (UTC)[reply]

I think I got it. Add div.siteNotice {display:none !important} under preferences > (your current) skin > Custom CSS. It appears to not work if you use HTTPS to browse the Wiki. hbdragon88 (talk) 04:12, 7 October 2011 (UTC)[reply]

It's not working for me. :( - The Bushranger _{One ping only} 04:18, 7 October 2011 (UTC)[reply]

~~Hm. Removing the "!important" part of the code seems like it might have made it work. - The Bushranger _{One ping only} 04:21, 7 October 2011 (UTC)~~ ...and ironically, the post I made to say that, proved me wrong. Not working here. - The Bushranger _{One ping only} 04:22, 7 October 2011 (UTC)[reply]

My apologies. Do this div.globalWrapper#div.column-content#div.siteNotice { display:none !important} that worked for me. hbdragon88 (talk) 05:22, 7 October 2011 (UTC)[reply]

It still popping up :(--♫Greatorangepumpkin♫_Hey^{it's me} 10:21, 7 October 2011 (UTC)[reply]

I personally use #centralNotice {display:none !important;}, and that seems to work nicely for me. ^Avic_ennasis @ 13:02, 9 Tishrei 5772 / 13:02, 7 October 2011 (UTC)[reply]

So I'm not the only one who can't get the banners to stay even if I click the [x], huh? Dear WMF, if you'd like to keep your volunteers happy, then MAKE SURE YOUR DISMISSABLE ADS CAN ACTUALLY BE DISMISSED. /ƒETCH COMMS / 04:40, 7 October 2011 (UTC)[reply]

I'm currently employing Δ's method of using Adblock Plus to squash them, and it seems to be working nicely. I didn't have any luck with Hbdragon88's solution, although I appreciate the suggestion (and it's eminently possible that I was doing something incorrectly when I tried it). Thanks. --Bongwarrior (talk) 07:24, 7 October 2011 (UTC)[reply]

It didn't work for me. Can you explain what you did?--♫Greatorangepumpkin♫_Hey^{it's me} 10:15, 7 October 2011 (UTC)[reply]

Click the Adblock Plus icon in the bottom corner of your browser -> click "Open blockable items". In the list that appears, look for any entries that mention banners. Right click on the entry and choose "Block this item", choose "Custom:url" and then "Add filter". I did this for two entries. --Bongwarrior (talk) 19:27, 7 October 2011 (UTC)[reply]

Shouldn't this be solved centrally, for all users? It is very annoying not being able to actually dismiss the banner. One should be able to remove such banners. Manxruler (talk) 09:47, 7 October 2011 (UTC)[reply]

There is also a problem that the "Get involved" button on the fundraiser banner appears in exactly the same place as a {{coord|display=title}}. Monobook, Firefox 3.6.23, Windows XP. --Redrose64 (talk) 10:27, 7 October 2011 (UTC)[reply]

Massive pain in the arse, to the point where I'm tempted to post a hail of troll-like abuse on whatever links appear that I'm asked to contribute toward. I'd be ecstatic if I never had to read another one of these stupid fucking notices again. Parrot of Doom 10:52, 7 October 2011 (UTC)[reply]

I'm with Parrot on this. What utter retard is responsible for this huge fuck-up? Lugnuts (talk) 12:12, 7 October 2011 (UTC)[reply]

The words, the words. Just because someone is not an editor right here, he is part of our community. Be more considerate with your words. —TheDJ (talk • contribs) 12:23, 7 October 2011 (UTC)[reply]

He? Well you've failed your equal opps too. 24hrs is more than enough time for this abortion to be fixed. Thanks. Lugnuts (talk) 12:24, 7 October 2011 (UTC)[reply]

When you have to keep click close on a banner like 40 times an hour this really is not good enough. Sort it out sombody please..♦ Dr. Blofeld 12:59, 7 October 2011 (UTC)[reply]

I think I have solved the issue with the particular banner now; if anyone is still having problems, please report them at m:Talk:Fundraising 2011 (for fundraising banners) or m:Talk:CentralNotice (for other banners, or issues regarding both fundraiser banners and other banners), where it is more likely to be seen by the relevant people. Jsoby (talk) 14:26, 7 October 2011 (UTC)[reply]

This is a pain in the arse. Could someone please fix it? --John (talk) 15:35, 7 October 2011 (UTC)[reply]

Does it still not work for you, John? It works for me, but if it's still broken for you I don't know what's wrong. :/ Jsoby (talk) 15:46, 7 October 2011 (UTC)[reply]

I assume it is something to do with the recent "upgrade". It would be great if it could be fixed, it is highly irritating. --John (talk) 15:54, 7 October 2011 (UTC)[reply]

Maybe, but my question still stands: Does it still not work for you? Because I thought I had fixed it. Jsoby (talk) 16:02, 7 October 2011 (UTC)[reply]

Hey, thank you, it seems to be fixed. Nice work. --John (talk) 16:47, 7 October 2011 (UTC)[reply]

They're baaack

I have the javascript/CSS thing below installed in addition to whatever fix was done here...but they're starting to pop up again. Not quite as often, but... - The Bushranger _{One ping only} 19:44, 7 October 2011 (UTC)[reply]

Template:Infobox civil conflict

I don't think this templates way of doing images and pixel sizes is good. Can someone help? Thanks. - Peregrine Fisher (talk) 04:15, 7 October 2011 (UTC)[reply]

There's nothing in the template which mandates large image sizes. You've just misunderstood the documentation. See the talk page. Chris Cunningham (user:thumperward) - talk 09:22, 7 October 2011 (UTC)[reply]

Unwatching with Popups now has additional (unwelcome) prompt

I don't know if this is related to the recent upgrade or is just another odd issue with popups. Until recently, I could remove an article from my watchlist by hovering over it and selecting "unwatch" from the popups menu with one click that opened a page confirming the article had been removed. Now, that same menu option opens a page that requires me to confirm that I want to remove the article. What used to already be slightly annoying and took two clicks - one to unwatch the article and another to close the unnecessary new page confirming its removal - now takes three clicks. We've gone from bad to worse. Any ideas how to fix this or to whom I should direct my annoyance? ElKevbo (talk) 05:34, 7 October 2011 (UTC)[reply]

This is a result of bugzilla:27655 and bugzilla:29070. T. Canens (talk) 07:33, 7 October 2011 (UTC)[reply]

You should post at Wikipedia talk:Tools/Navigation popups to try to get the problem fixed. Anomie ⚔ 10:59, 7 October 2011 (UTC)[reply]

I'm confused and I seem to be getting mixed messages. Is this a bug in the new software that is being fixed or is this an issue with popups that needs to be fixed locally? Or both? ElKevbo (talk) 14:22, 7 October 2011 (UTC)[reply]

Because of an extra security measure in 1.18, the popups functionality is no longer working, and popups will need to be fixed locally. —TheDJ (talk • contribs) 14:27, 7 October 2011 (UTC)[reply]

Ok. Thanks so much! ElKevbo (talk) 14:29, 7 October 2011 (UTC)[reply]

Sortable Tables glitch

Hi,

Since the 1.18 update, my sortable table on my user page has a few problems with secondary sort key. eg if you press age, then name, some are correct(eg Amanda Kimmel), but others arent (eg Ami Cusack). Any help would be appreciated. --Kangaross1989 (talk) 05:39, 7 October 2011 (UTC)[reply]

The behavior changed, because we use a new, more advanced tablesorter. This new system requires using the shift-key in order to do multiple column sort. bugzilla:31255. —TheDJ (talk • contribs) 12:08, 7 October 2011 (UTC)[reply]

Fundraiser

This latest box-at-the-top is really annoying me. I've read it, I'm not sharing my story, and I want it to go away. Usually there's a 'hide' button on these things at the top so you can get rid of notices you've seen and don't want any more. This damn thing can be closed, but it reappears in the very next window. It's not a life threatening problem - just irritating. This probably isn't the right place, but I don't know of another off hand. Hopefully the person that set it up will hear about this and alter it so it can be tidied away by people who don't like being nagged. Peridon (talk) 12:34, 7 October 2011 (UTC)[reply]

I agree. Also, the "suppress fundraiser banners" option in the preferences seems gone. Regards So Why 12:49, 7 October 2011 (UTC)[reply]

I also want these annoying messages to go away. Any help on how to achieve this would be appreciated. Toshio Yamaguchi (talk) 12:53, 7 October 2011 (UTC)[reply]

I click hide and then 2 pages later it will come up again or another banner will come up about mobile phone. What the hell is wrong with them? I looked in my preferences for the supress banners and its not there. ♦ Dr. Blofeld 12:57, 7 October 2011 (UTC)[reply]

Can someone copy paste and list here the exact text of any banner that is doing that ? I'm not seeing them myself, perhaps they are geotargeted or something. —TheDJ (talk • contribs) 13:15, 7 October 2011 (UTC)[reply]

Adding the following to special:Mypage/skin.css should hide it -

#centralNotice  .siteNoticePic {
    display: none;
}

There's a bunch of other stuff you can hide, check User:Xeno/monobook.css. Of course you will need to accept whatever risks may come along with hiding central, site, watchlist, and edit notices. –xeno^talk 13:30, 7 October 2011 (UTC)[reply]

I do want to see notices - but once only. A hide button is all I ask. I know this is a WikiMedia thing (I tried opening it, but it doesn't seem to accept that as proof that I've read it...), but is it possible for someone to tell them how annoying (and counter-productive) it is? Peridon (talk) 13:54, 7 October 2011 (UTC)[reply]

I think I have solved the issue with the particular banner now; if anyone is still having problems, please report them at m:Talk:Fundraising 2011 (for fundraising banners) or m:Talk:CentralNotice (for other banners, or issues regarding both fundraiser banners and other banners), where it is more likely to be seen by the relevant people. Jsoby (talk) 14:26, 7 October 2011 (UTC)[reply]

I am still having problems, and have posted at meta about it. Peridon (talk) 20:20, 7 October 2011 (UTC)[reply]

Don't know what they've done, but the banner hasn't appeared today. Peridon (talk) 15:28, 8 October 2011 (UTC)[reply]

Persisting bug with IE

The persisting bug with IE precludes the "Show preview" of modifications/corrections. This involves that errors/typos made during these modifications/corrections are not detected before saving and that these possible errors/typos have to be corrected in a second step.
Please solve this issue ASAP. --Réginald alias Meneerke bloem (To reply) 10:35, 7 October 2011 (UTC)[reply]

I am also encountering this one, along with the "crashes every two or three pages" that everybody has who's stuck with IE8. --Orangemike (talk) 19:07, 7 October 2011 (UTC)[reply]

Thumb images next to sortable table pushes the table underneath it

Thumb images next to sortable table pushes the table underneath it. and increase the inside of the table. Prior to the update it wasn't the case. If you look at the exemple bellow you will see that until the page fully loads the text and images sit well next to the table but once the sorting images kicks in it pushes it and make the inside table bigger bcuz of the arrow images.

– HonorTheKing (talk) 12:00, 7 October 2011 (UTC)[reply]

This depends on the width of your screen, the table will take up as much space as it requires. That might be slightly more that before, but you should never depend much on the width of an element. (Think also about mobile phones for instance). —TheDJ (talk • contribs) 12:16, 7 October 2011 (UTC)[reply]

References look diffrent in Firefox and IE

References in firefox have two refs in one line. while in IE only one ref in one line. I refer when it uses - {{reflist|colwidth=30em}} OR {{reflist|2}} Not talking about the normal {{reflist}} which post 1 ref per line in both browsers.
– HonorTheKing (talk) 12:00, 7 October 2011 (UTC)[reply]

This is because many browsers (including IE) don't properly support columns yet. It also explains this in the documentation of Reflist. —TheDJ (talk • contribs) 12:06, 7 October 2011 (UTC)[reply]

"Many" browsers? As far as I was aware IE is the only modern browser which doesn't support CSS columns (at least using the -moz and -webkit implementation hacks, which we include in all of the relevant templates). Chris Cunningham (user:thumperward) - talk 13:57, 7 October 2011 (UTC)[reply]

Actually the chrome and safari implementations are a tad buggy as well (cutting of some lines in incorrect ways), and Opera ahs also had it's issues. Especially the colwidth variants of them. —TheDJ (talk • contribs) 14:07, 7 October 2011 (UTC)[reply]

IE10 supports columns; see WP:REFCOLS. Chrome and Safari appear to be mishandling the column-width selector, thus |n= works, but |colwidth= renders oddly. ---— Gadget850 (Ed) ^talk 16:54, 7 October 2011 (UTC)[reply]

connection difficulties

I'm having problems connecting to Wikipedia using IE8. A box appears inviting me to report the problem to Microsoft, which I have done several times. If I click the "debug" button, IE often (not always) manages to display the page I want. This has been going on for several days. All the other sites I use work fine. I saw a bar a few days ago that said that maintenance work was being done that might cause connection difficulties. The bar has now gone, but the difficulties persist. Can this be fixed, please?! DOwenWilliams (talk) 15:06, 7 October 2011 (UTC)[reply]

It's been funny for a while. Probably the roll out of Media-wiki 1.18? If so the fix is to wait. Rich Farmbrough, 15:54, 7 October 2011 (UTC).[reply]

We just rolled out a fix for an 'IE8 crashes a lot' bug today, so check if this is now resolved for you. --brion (talk) 00:49, 8 October 2011 (UTC)[reply]

Yes. It works. Thanks. DOwenWilliams (talk) 03:00, 8 October 2011 (UTC)[reply]

Script not working on Watchlist

Using Firefox. Opening my watchlist I get a message to say that a script on the page has stopped working - http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=20111005T084642Z:99 pablo 15:51, 7 October 2011 (UTC)[reply]

This is another "bits.wikimedia.org" problem similar to the one I reported here a few days back. I'm still not sure why the browser spends so much time "waiting for bits.mediawiki.org". Rich Farmbrough, 15:57, 7 October 2011 (UTC).[reply]

I'm reporting this as as something to keep track of, but I'd like more reports before I take it further. — ☠MarkAHershberger☣ 20:44, 8 October 2011 (UTC)[reply]

Parts of the toolbar seem shy

I have had about half the toolbar vanish on a number of occasions today. No big deal, but a singular occurrence.Rich Farmbrough, 15:53, 7 October 2011 (UTC).[reply]

A plural occurrence, surely ;) --Tagishsimon (talk) 16:50, 7 October 2011 (UTC)[reply]

Maybe the same as this problem on ptwiki? — ☠MarkAHershberger☣ 21:01, 8 October 2011 (UTC)[reply]

Tab underlining

Could a tech-savvy user tell me please how to stop the WP tabs from being underlined? "Project page"/"Article", "Discussion", "Read", "Edit" and "View history" are all underlined now when they weren't before. This is not the case when logged-out, but when I'm logged in, I have the preference for wiki-links to be underlined... It's just that I don't want the tabs underlined at the top of each page – and I'm not familiar with CSS in order to help myself. Jared Preston (talk) 18:47, 7 October 2011 (UTC)[reply]

If you're using Vector, the following CSS code will get rid of the underlines:

#mw-head a {
  text-decoration: none;
}

— Edokter (talk) — 21:51, 7 October 2011 (UTC)[reply]

If they were not underlined before, then I would consider that to be a bug and the behavior now fixed. The preference talks about underlining ALL links, not just wikilinks. —TheDJ (talk • contribs) 12:51, 8 October 2011 (UTC)[reply]

Bug with piped links

I just spotted an odd bug with using piped links. If the pipe is immediately followed by the word "revision"

[http://en.wikipedia.org/w/index.php?title=List_of_plants_used_in_herbalism&oldid=452788457|revision at 01:14, 28 September 2011]

Gives at 01:14, 28 September 2011

[http://en.wikipedia.org/w/index.php?title=List_of_plants_used_in_herbalism&oldid=452788457|other word at 01:14, 28 September 2011]

Gives word at 01:14, 28 September 2011

in the first the link gets messed up and the word revision is not displayed.--Salix (talk): 22:34, 7 October 2011 (UTC)[reply]

Pipes aren't used in links using single brackets; the first space character is the delimiter instead. 28bytes (talk) 22:39, 7 October 2011 (UTC)[reply]

Category Navigation

I've got an issue with navigating through a large category using the next & prev links.

If I view any large category which has a category toc (for example: Category:Hidden categories but any with a table of contents will do) and then select a letter from the table of contents. When I then try to use the previous 200 link, it does not work. -- WOSlinker (talk) 15:15, 8 October 2011 (UTC)[reply]

I can confirm that. Right now I'm using Firefox. Chris857 (talk) 19:22, 8 October 2011 (UTC)[reply]

This sounds like a recurrence of a problem which appeared soon after the MW1.17 deployment (see Wikipedia:Village pump (technical)/Archive 87#categorically random categories) - the URLs are constructed incorrectly, and it concerns whether &from= or &pagefrom= should be used in the URL. The workaround is to click the letter in the category TOC, then go to your browser's address bar and alter the &from= to a &pagefrom= and press Return. The "previous 200" link should then work until you next select a letter in the category TOC. --Redrose64 (talk) 19:23, 8 October 2011 (UTC)[reply]

You have to use &subcatfrom= when navigating Category:Hidden categories though. Is the a bug enter for this issue in Bugzilla? -- WOSlinker (talk) 20:25, 8 October 2011 (UTC)[reply]

Not all the tools display

Not sure if this is the right place to report this, but I've noticed since the recent upgrade that not all the tools are displayed whenever a new article is created or some articles are edited. This is particularly true with the redirect and ref tools. I thought at first it might be because I'd recently changed my username, but this doesn't appear to be the case as it works with some long-established articles. Apologies if this has already been reported. Cheers Paul MacDermott (talk) 19:02, 8 October 2011 (UTC)[reply]

Maybe the same as this problem on ptwiki? — ☠MarkAHershberger☣ 21:01, 8 October 2011 (UTC)[reply]

[2] [1]

[1] Fixed now!

[3] Joe Shmoe (2011). "Piped Wikilinks with parentheses". [[Nature (journal)|]]. 333 (1): 551–552.

[4] Nature

[5] [[Nature (journal)|]]

[note 1]

[1]

[1]

[2]

[3]

@@ Line 503: / Line 503: @@
 :Fixed in [[mw:Special:Code/MediaWiki/99097|r99097]]. It was a stray comma, no less ^^ . --[[User:Catrope|Catrope]] ([[User talk:Catrope|talk]]) 13:36, 6 October 2011 (UTC)
 {{collapsed bottom}}
+I'm still having this problem. I have cleared my cache and restarted the program since the announcement that it was resolved was made, but to no avail. <font face="Lucida Calligraphy">[[User:LadyofShalott|<font color="#ee3399">Lady</font>]]<font color="#0095c6">of</font>[[User_Talk:LadyofShalott|<font color="#442288">Shalott</font>]]</font> 23:41, 8 October 2011 (UTC)
 ===Editing "insert" box not showing===