Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla.

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.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Plan to reduce Template:Convert

11-Feb-2011: The essay about redesigning Template:Convert, to use condensed subtemplates, rather than 3,400 (of 24,000 needed) is titled "WP:A plan to reduce Convert subtemplates".
Currently, {Convert} is a vast contraption, so immensely huge that no single person really understands all of it, and parts of Convert are used (incorrectly) deep in the innards of some other templates, but never used directly by people writing articles. Hence, the improvements to Convert are chasing a moving target, of over 15 types or sub-families of conversion formats.
The redesigned, extended prototype has suffix "-x" as Template:Convertx which would allow comma=in, comma=out, comma=off, and other new features:

• {{convertx|9,250|km|mi|comma=in}} → Template:Convertx
• {{convertx|9,250|km|mi|comma=out}} → Template:Convertx

The only hope is this hybrid approach which "morphs" the current Convert subtemplates into updated forms, which allow passing new parameters to handle the new options. Essentially, each unit (such as: ft, m, km, sqft, oz-f) would choose between the new or old style of processing conversions. Unused units would not change (because who cares). The performance overhead is perhaps 5 levels lower for the expansion depth, but about 100 bytes more in post-expand size, for the new features, such as Convert using 300 bytes when Convertx would use 400 bytes of post-expand size. -Wikid77 05:46, 11 February 2011 (UTC)

"Comma in" and "comma out" contradict everything about proper number formatting and WP:MOSNUM. If you want to write 9250 km, then you need to write 5720 mi. Mixing styles is not appropriate. Headbomb {talk / contribs / physics / books} 06:05, 11 February 2011 (UTC)

Yes, I think mixing of styles was requested by people wanting to put direct quotes from some ignorant imbecile like Isaac Newton, or Max Planck, or Albert Einstein, who only spoke 5 languages, and did not understand the life-critical importance of using commas. Those guys never did anything more than develop reflector telescopes, or Planck's law, or relativity theories (E=mc^2). There's even talk of how they wrote unformatted equations, by hand, without using the Unicode &minus! Perhaps if WP:MOSNUM had existed centuries ago, then those guys could have been stopped, most certainly, before they became notable. -Wikid77 13:18, 11 February 2011 (UTC)

Yeah, and if you want to quote them verbatim, you don't need convert templates, because I doubt Newton et al. wrote things like "A sphere of Template:Convertx, ...". If an editorial note, parentheses should not be used for this, but rather square brackets. "A sphere of 9250nbsp;km [5,750nbsp;mi / 5750 mi], ..." And take that crass attitude of yours elsewhere. Headbomb {talk / contribs / physics / books} 15:06, 11 February 2011 (UTC)

• Sorry, I thought the joke was obvious, but I should have said how Template:Convert, for years, has been used inside direct quotations, with equivalent amounts in editorial brackets "[ ]" despite no commas in the quoted text. -Wikid77 14:12, 14 February 2011 (UTC)

This outburst is not helpful to your cause, and I think you know it. You should be encouraging people to focus on the issue at hand, not encouraging them to follow you down a tangent. Happy‑melon 13:57, 11 February 2011 (UTC)

I guess I forgot how some people dislike jokes about WP:MOS. Perhaps I should have said that Convert supports conversions going back over 3,000 years ago, with or without commas in their stone carvings. -Wikid77 14:12, 14 February 2011 (UTC)

Any plans on using the convert extension mentioned in Wikipedia:Wikipedia Signpost/2011-01-31/Technology report? -- WOSlinker (talk) 13:24, 11 February 2011 (UTC)

I was planning on starting a discussion about that soon on Template talk:Convert, but there are a few more features I wanted to implement and stabilise in it [the extension] first. Happy‑melon 13:57, 11 February 2011 (UTC)

• Template:Convert currently allows dynamic definition of thousands, and thousands, of new units (within a few minutes each), depending on which measurement units are used in each culture, as described in millions of articles of the other-language Wikipedias. We recently added the famous Egyptian cubit, and also added the French arpent (there are other arpents, both linear and square), due to widespread use in French colonial culture. Google estimates 143 million webpages about the word "measurement", but Convert also handles calendar dates, gun-barrel calibre, and musical notes, so we had to make Convert be a highly dynamic system, to allow users to add new units every hour of the day, and convert the words, not just numbers. Reality is so much more complex than just a list of 400 or 900 commonly used units. -Wikid77 14:12, 14 February 2011 (UTC)
• When reducing the internal structure of Convert, then some new features will also be added. For example, numbers will be displayed up to whole billions, with end-zeroes, to allow showing $billions of dollars, but then use scientific notation for larger amounts. For example, converting billions of dollars-per-pound:

• {{convert|32,000,000,000|$/lb}} → $32,000,000,000 per pound ($7.1×10¹⁰/kg)

Adding new features, while reducing the structure, will take full advantage of changing the fully-protected subtemplates in Convert, to test both the reduction of old subtemplate structures, as well as adding the new features, at the same time. -Wikid77 17:50, 18 February 2011 (UTC)

Transclusion of Special:Watchlist

How can I transclude Special:Watchlist onto my userspace? I want to make a page with my article alerts, watchlist for the past 12 hours, and other useful stuff that I make use of commonly. However, transcluding Special:Watchlist creates a plain link to it.

How can I do this? If it can't be done, can we make it possible? Even if it just transcludes the watchlist of the user looking at it (or "you are not logged in" for IPs), that would work for privacy concerns. - ʄɭoʏɗiaɲ ^τ _¢ 02:54, 14 February 2011 (UTC)

I don't believe it's currently possible, perhaps the reason being that if someone were to come across a random page that shows their watchlist, then they'd be quite alarmed. That's why nothing that is personalized to a single individual can be entered onto any page. Gary King (talk · scripts) 07:13, 14 February 2011 (UTC)

Seems a silly reason. They'd come to the village pump and be informed that "somebody is transcluding special:watchlist. Whoever is viewing it will see their own watchlist." The ability to create a customized watchlist with your own gadgets. - ʄɭoʏɗiaɲ ^τ _¢ 14:43, 14 February 2011 (UTC)

Not silly at all. Imagine browsing Facebook and seeing comments from your profile posted on another person's profile, or your email from Gmail posted on another person's Google profile. If you browsed around here and came across Example and it showed your watchlist because a vandal transcluded it, and you were a newbie and so never heard of the village pump (I can certainly attest that it's quite difficult to find, considering someone had to point me there early in my wiki days when I screwed up a few times), then it can be quite difficult to grasp that someone merely "transcluded" your watchlist to a page. It's also hard for a newbie to explain what exactly is going on when the page looks a bit different to everyone who sees it. Gary King (talk · scripts) 16:09, 14 February 2011 (UTC)

The real reason it can't be done is because it would break caching. The transcludable special pages are the ones that don't have different output depending on which user visits them. Mr.Z-man 23:26, 14 February 2011 (UTC)

Anyway, methods of achieving your desired effect:

1. Write a script to querying the API and insert it into the page. Unfortunately, the parse API is rather broken [1]. Using iframe or AJAX also works.
2. Create a sub-page linking to page and use {{Special:RecentChangesLinked/User:Floydian/Watching}}. More cumbersome to add pages.
3. Just use bookmarks or have a script to add links/HTML to Special:Watchlist.

See guys that wasn't so hard. — Dispenser 02:45, 15 February 2011 (UTC)

The API has a specific method for grabbing the watchlist [2] Platonides (talk) 20:43, 15 February 2011 (UTC)

Er... Ok, I get 2 and 3... But how do I call a php script from within wiki? Would it be something I'd write into my .js?

Better yet, are there any examples of code calling the API onto a wiki page that I can take a look at? - ʄɭoʏɗiaɲ ^τ _¢ 15:09, 18 February 2011 (UTC)

(e/c)You have to write a JavaScript to get your watchlist from the API (https://secure.wikimedia.org/wikipedia/en/w/api.php?action=query&list=watchlist) then parse that, and dynamically add it to wherever you want it added in Wikipedia. —TheDJ (talk • contribs) 15:20, 18 February 2011 (UTC)

Gah! I can't wrap my head around javascript. It's the most confusing programming language to me. It doesn't help that the way it must be implemented on wikipedia just makes my brain explode. Just put a script on the page doesn't work, it just displays it as a piece of code. You can't just call a script from a page either, because that requires a script to call the script function. Its seems you have to set up the javascript to (using that script) detect when you are on the correct article, and insert it onto the page in the correct place.

User:Floydian/callwatchlist.js is one of a few attempts. I've tried longer more complicated codes that have a bunch of stuff that makes no sense on them. I've tried ajaxinclude, function include, plain ol' include, and the results is it displays the link of the api query. - ʄɭoʏɗiaɲ ^τ _¢ 20:02, 18 February 2011 (UTC)

User losing text and data when uploading

Can someone technical have a look at the two Help desk threads by Catchthedream (talk · contribs)? One, Two. It looks like text and data is being randomly damaged/truncated on its way from the user's PC to the Wikipedia servers. -- John of Reading (talk) 10:16, 15 February 2011 (UTC)

Reverting images with API

I cannot find any documentation under mw:API:Changing wiki content on how to revert an image to an earlier version. It is in fact written in the software: (click here to see what I'm talking about). Is there a way to do it through the API? Magog the Ogre (talk) 22:05, 15 February 2011 (UTC)

Not directly. The workaround is to do a query like [3] then feed the image or the URL to upload. MER-C 02:20, 16 February 2011 (UTC)

I don't believe Wikimedia/Wikipedia have URL based uploads enabled; am I wrong? Magog the Ogre (talk) 07:33, 16 February 2011 (UTC)

You are correct. —TheDJ (talk • contribs) 11:37, 16 February 2011 (UTC)

search messages tidyup proposal

I have suggested a couple of minor adjustments for the search result messages here, partly aesthetics, partly logic... hopefully short yet sweet. Lee∴V (talk • contribs) 00:08, 16 February 2011 (UTC)

Did the appearance just change for anybody else?

Right in the middle of editing DYKs (as in, preview on the prep, fine, then go to another hook on the talk page, and wha?!) the appearance of the editing window changed. I have 'monobook' set as my skin, but all of a sudden the editing window has the "fancy" appearance of Vector/default, but everything else is the same? (I'm using Firefox 3.6.10) - The Bushranger _{One ping only} 06:23, 16 February 2011 (UTC)

...aha. I just found the 'enable enhanced editing toolbar' thing in the Beta section of Editing Preferences, unchecked it, and it's back to normal. Panic averted, I've found my towel. - The Bushranger _{One ping only} 06:46, 16 February 2011 (UTC)

was fine for me until about 5 mins ago, then it went and broke, Everything was there, but it appeared that all the page formatting had broken. Pages taking ages to load too. I swapped to IE, and that is taking forever to load (one reason I use Firefox) so I abandoned the attempt to use IE. Seems to have settled now. Mjroots (talk) 10:23, 16 February 2011 (UTC)

This was due to maintenance. There was an attempt to switch to 1.17 again, first one was problematic, the last one succeeded. —TheDJ (talk • contribs) 11:42, 16 February 2011 (UTC)

• Pages are showing up in monobook for me, but I'm getting the hideous Vector edit window. I'd just got used to it and then the RefToolbar buggered off. Can I get the monobook edit window, or at least the gadgets, back somehow? HJ Mitchell | Penny for your thoughts? 12:31, 16 February 2011 (UTC)

Well, I'm using Monobook and I followed the advice in 2nd post above and it  Works for me - Special:Preferences → Editing → Beta features - make sure that "Enable enhanced editing toolbar" is not checked. --Redrose64 (talk) 13:22, 16 February 2011 (UTC)

Ahh, I thought it was just me. Thanks, I've switched it back. More to the point - why on earth was it changed? Any discussion links about this? Lugnuts (talk) 19:13, 16 February 2011 (UTC)

Bloody awful appearence

All the gadgets stopped working, the stuff from the top of the page (my talk, prefs, etc, and all the page/discussion/edit etc) all jumped down to the bottom of the page, and it ll generally looked hideous. Now in the edit screen, it's almost back to normal but the edit box toolbar has changed its appearence and the cite hutton etc has disappeared. Is this one of the regular "improvements"? I would upload a screenshot, but the upload screen seems to have changed again and I can't find the option for WP screenshots (which I'm sure there was for a while). DuncanHill (talk) 10:18, 16 February 2011 (UTC)

That was another attempt to deploy MW 1.17. They've already reverted it. MER-C 10:23, 16 February 2011 (UTC)

IT's still taking ages for pages to load, the "discussion" and "edit" tabs at top of page are overlapping. Mjroots (talk) 10:28, 16 February 2011 (UTC)

• Well, the blackscreen gadget is working again, but the tbs and links are still in the wrong place. Edit screen (I unchecked the beta thing referred to in the post above) now has no edit toolbar at all, and the special characters are all showing up at once with no drop-downs, and no clickability. DuncanHill (talk) 10:39, 16 February 2011 (UTC)

We're in software upgrade mode, and various parts of the server structure are getting hammered. Hold on to your hats, and hopefully things will settle down again soon. Happy‑melon 10:53, 16 February 2011 (UTC)

Indeed, it's called a maintenance window for a reason, and some strangeness was expected. Good news, all ok now, and were running 1.17. —TheDJ (talk • contribs) 11:43, 16 February 2011 (UTC)

All ok, except blackscreen gadget not working (except in edit screen, when the pge loads without the blackscreen and then the blackscreen "switches on" after it loads), pop-ups not working, and the clock gadget not shoing up on watchlist (or anywhere else except in the edit screen). So not all OK at all. DuncanHill (talk) 12:00, 16 February 2011 (UTC)

I think he means that, unlike the previous attempts to deploy MW 1.17 which crashed the entire cluster, this deployment has been successfully implemented. There was plenty of warning that there would be bits of user JS and CSS which would need fixing after deployment. Happy‑melon 12:04, 16 February 2011 (UTC)

And HotCat isnz't working either. Are any of the gadgets in user preferences working? DuncanHill (talk) 12:05, 16 February 2011 (UTC)

And, for the record, where were these warnings? I never had any warning that all the gadgets would stop. DuncanHill (talk) 12:09, 16 February 2011 (UTC)

The CentralNotice that you've probably hidden :P And all over wikitech-l, the techblog, etc. Happy‑melon 12:10, 16 February 2011 (UTC)

No offense to you personally, but using centralNotice as the only onwiki channel for critical issues is very stupid. It has so often been abused for trivialities and outright spam that many editors have disabled it. — Gavia immer (talk) 12:16, 16 February 2011 (UTC)

(ec)If a Central Notice is the same thing as the bloody fundraising banners, then of course it's hidden. I'm pretty sure it's not been on a watchlist notice. No idea what wikitech-l is, and not an habitué of the techblog. DuncanHill (talk) 12:18, 16 February 2011 (UTC)

It's been posted to every major Wikimedia mailing list, and here at the tech village pump. And if you're at all interested in Wikimedia technical matters, the techblog is an excellent way to keep up. I'll admit that a watchlist notice might have been a good idea though. the wub "?!" 12:24, 16 February 2011 (UTC)

My interest in Wikimedia technical matters extends to "does it work?" and "will someone please make it work again?" DuncanHill (talk) 12:29, 16 February 2011 (UTC)

Then you should read the many other venues that the wub pointed out. We can't read peoples minds and magically figure out who wants what information directly delivered to his brain at what time. —TheDJ (talk • contribs) 19:48, 17 February 2011 (UTC)

I shouldn't have to traipse around "many other venues" to find out if Wikipedia is working, or if anything is being done to fix things that are broken. DuncanHill (talk) 22:22, 17 February 2011 (UTC)

Yet you would complain if we constantly had banners stating what was broken (couple dozen things every day), because they would be constantly in your face and you wouldn't be able to use the encyclopedia. I mean, you can't have it both ways. In situations where things constantly change, break and get repaired, there is no informing that will ever satisfy your criteria of not being spammed, yet being constantly informed of everything. Perhaps not ever making a change would be an idea ? But then developers would of course be shouted at by the other users clamoring for new functionalities and worried that the non-patched security issues are exposing their private information. I leave you all in this discussion, with this very nice column I once read. If Architects would work like software engineers. —TheDJ (talk • contribs) 13:49, 19 February 2011 (UTC)

Hey, how about a venue where people could come and ask what's gone wrong without being blamed for not reading the notice that was hidden from them? And to be frank, if you can avoid demanding money from me with disturbing pictures, I really wouldn't mind too much getting messages! DuncanHill (talk) 14:20, 19 February 2011 (UTC)

It's very easy to make the mistake of thinking that the MediaWiki world revolves entirely around enwiki and that everyone should use enwiki's preferred notification methods to inform about changes like these. This deployment affected all 850 wikis in the Wikimedia cluster; there is no justification for saying that the sysadmins should have laboriously gone around and identified the preferred channels for each and every wiki, including those in languages they don't even speak; and equally no reason for enwiki to get any special treatment. Rather, the sysadmins used the channels which are already set up to allow crosswiki communication. It's unfortunate that you've chosen not to receive those messages, but really not anyone's fault but your own. Happy‑melon 12:35, 16 February 2011 (UTC)

I chose not to receive poorly written and offensive begging messages. I don't see why editors and readers should be expected to spend their time on a techblog just in order to have some idea of what is happening. When you find that your method of communication is not working, blaming the people you have failed to communicate with just comes across as arrogant. DuncanHill (talk) 12:45, 16 February 2011 (UTC)

I'd say that it would be claiming that one particular person, group or community should be given special treatment in that communication, which comes across as arrogant. By hiding the CentralNotice you have also hidden information about the Steward elections, Wikimania, and various other Wikimedia-wide issues. It's entirely reasonable to say that you are not interested in crosswiki issues, and to hide the entire CentralNotice. Or it's reasonable to say that you only dislike the fundraiser banner, and to hide that specifically. But to say that you want to be kept informed of crosswiki issues, and then to deliberately block out the communication channel which has been created for those issues, is counterproductive at best. Happy‑melon 13:04, 16 February 2011 (UTC)

Had Centralnotice not been abused for those ridiculous Jimbo fundraising banners, few people would have disabled it. From then on, Centralnotice has been perceived as spam. And the WMF has only itself to blame for it. --Morn (talk) 13:16, 16 February 2011 (UTC)

I'm sorry, Happy-Melon, I didn't realise that we weren't allowed to want to know about changes to Wikipedia unless we also wanted to know about lots of other irrelevant stuff. And, FWIW, I have seen messages about the Steward elections, and Wikimania. Like (I suspect) most editors and readers I really do not care much about cross-wiki stuff, but I do care about the reading and editing environment here. You obviously don't regard that as acceptable - it's "all or nothing". DuncanHill (talk) 13:30, 16 February 2011 (UTC)

Anyway, the thing I've got suppressed is "display of the fundraising banner", according to my prefs/gadgets. Doesn't say anything about "suppress notice of planned cross-wiki disruption" DuncanHill (talk) 14:34, 16 February 2011 (UTC)

You certainly don't seem to realise that you're not allowed to expect other overworked and un- or under-paid people to alter their professional behaviour to accommodate your personal definition of what is and is not "irrelevant", no. Essentially this is a "the world does not revolve around you" discussion, and I doubt it's going to go anywhere productive. Happy‑melon 14:45, 16 February 2011 (UTC)

Umm, just a note here - I am not sure what you mean by CentralNotice, since I also have only the Fundraising banners disabled (and that only after a glitch appeared that made them reappear immediately after they were dismissed). I can see and do notice all the other stuff at the top of pages, such as the Stewards' election notice. And I didn't see word one about this rollout on en.wiki; in fact I specifically looked for a notice about it after I saw it on de.wiki. I suspect you will find it did not actually get advertised on en.wiki. (Whether users should have been alerted that "We are enabling a new feature" means "Your preferences may get mucked up" in addition to "Things will be a bit wonky while we fine-tune this" is a separate issue.) Please stop assuming bad faith when folks tell you they didn't see the notification. Yngvadottir (talk) 22:15, 16 February 2011 (UTC)

According to this the generic maintenance CentralNotice about this upgrade ran from 06:00 to 12:00 UTC on the 16th. Now, I am certain that I didn't see it when I came online on the 16th. Is it possible to check if it actually deployed properly? Also, does the "suppress the fundraising banner" option given to all logged-in users also suppress other notices, such as this one? DuncanHill (talk) 14:30, 17 February 2011 (UTC)

This is actually my mistake. Because the fundraising people didn't use proper CSS ids and classes, i was forced to adapt the fundraiser gadget to suppress all centralnotices. The idea was that the gadget would be removed after the fundraiser, so it wouldn't be a problem, but I (nor anyone else though) remembered. That's the problem with these kinds of hacks, they have a way of backfiring. I'm removing the gadget now. —TheDJ (talk • contribs) 19:52, 17 February 2011 (UTC)

Firstly, six-hours is an inadequate time-scale, as the disruption was somewhat longer. Try leaving it up until the major issues are fixed. Secondly - thanks for the apology. Next time someone says they didn't get any notification, check first that you actually did notify them. DuncanHill (talk) 22:22, 17 February 2011 (UTC)

As long as we're reporting issues here, I have another one: loading my watchlist in Firefox 3.6.13 now renders almost all of the way and then hangs briefly, obviously due to some javascript not loading properly. I haven't been able to work out the exact cause, so I will simply note that it is definitely a 1.17 issue. — Gavia immer (talk) 12:16, 16 February 2011 (UTC)

There's another change under Help, which gives the user a lot fewer options when searching Help. Now you get "Browsing", "Editing", "Guidelines", "Communication", "Questions", "Technical". OK for somebody Wikipedia savvy enough to know words or phrases to narrow their search. But what about someone who has never used Help before? If you want to narrow your search down to, say, only finding a template or a wikiproject, you need prior knowledge of Wikipedia to know to put it all in the search bar. The user does not have check boxes to help him/her narrow their search. Maile66 (talk) 12:37, 16 February 2011 (UTC)

I suspect that's a completely separate issue - someone tried redesigning Help:Contents (it's been reverted for now). Discussion at Help talk:Contents.

Thanks. Maile66 (talk) 13:01, 16 February 2011 (UTC)

The new messages bar appears to be partly broken, it still links ok, but the colour is wrong (Firefox). Mjroots (talk) 14:30, 16 February 2011 (UTC)

Yes, mine too (baby blue instead of the "orange bar of death" we've come to know and love). This is in IE. Ruhrfisch _><>°^° 15:43, 16 February 2011 (UTC)

That's the expected behaviour (r76017, Template:Bug). No comment on whether it's a positive development... Happy‑melon 16:59, 16 February 2011 (UTC)

Hm, it's definitely not the best colour choice. Would have missed it if someone didn't mention it. It really should be more of an obnoxious blue, like the {{talkback}} template uses. — Preceding unsigned comment added by Dorsal Axe (talk • contribs) 17:12, 16 February 2011 (UTC)

You can change it. I changed mine to screaming bloody red as a joke a few months ago and realized I liked it so I never switched back. Just add

.usermessage {

background-color: #ff0000

border: 1px solid #ffa500;

color: black;

font-weight: bold;

margin: 2em 0 1em;

padding: .5em 1em;

vertical-align: middle;

}

anywhere in your CSS file and it will override the default appearance. (I don't remember if the attributes for things other than the colors are redundant or not.) —Soap— 22:09, 16 February 2011 (UTC)

This has already all been sorted out down at #Blue_new_message_bars.3F.21 :) - Kingpin¹³ (talk) 22:13, 16 February 2011 (UTC)

Esams

And now the esams bits cache is dead again.[4] Secure WP server to the rescue...[5] --Morn (talk) 10:36, 16 February 2011 (UTC)

Try browser text-size smaller with MW 1.17

If your browser text size gets very large, then try setting Text-Size as smaller, to continue editing, when {{CURRENTVERSION}} = "1.17wmf1 (r82223)" or similar. Version now: 1.43.0-wmf.6 (5e1ad30). Most likely, the text will not appear quite as normal as before, but it will be similar in size, to resume work on updating pages (without too much mindfry from the changed screen appearance). Try to be patient, and imagine some improvements that will come with MW 1.17. Or not, if you prefer. -Wikid77 10:59, 16 February 2011 (UTC)

Editing

The new editing template is a disaster. Clicking on Advanced, Special characters and Help does nothing (Windows XP). Please don't tell me that I need to change my IE8 settings. I want them as they are. As a chemist I need to have superscript and subscript readily available for chemical formua such as O₂⁺, not two clicks away. Also the Courier font is unpleasant to use. BTW the special characters did not work with the previous edit template, but one could get round that. Petergans (talk) 11:06, 16 February 2011 (UTC)

Another issue: the link to citation template gives an old version. Petergans (talk) 11:23, 16 February 2011 (UTC)

The preferences were temporarily incorrect after the upgrade, the preferences are being restored as we speak to their pre-upgrade settings. —TheDJ (talk • contribs) 11:47, 16 February 2011 (UTC)

12:47 < RoanKattouw> thedj: Known issue, running a script to (partially) fix it like right now. The ones still having the issue will, unfortunately, have to switch it off again —TheDJ (talk • contribs) 11:48, 16 February 2011 (UTC)

Clarification: the script fixed most of the mess, but due to a minor FUBAR we were unable to fix the fact that certain users that had previously disabled the edit toolbar will now have it enabled again. These users will have to go to Preferences -> Editing -> Beta features and uncheck "Enable enhanced edit toolbar". There are about 4,200 affected users on English Wikipedia, if memory serves.

I realize this is an annoyance to these people, and I apologize for messing up. However, I'm sure you would've been more annoyed if you'd gotten the new toolbar and the preferences interface would refuse to turn it off, which is what would've happened if we hadn't done anything at all :) --Catrope (talk) 15:12, 16 February 2011 (UTC)

Actually, that is exactly what is happening to me. Regardless of the state of the checkbox, I have the enhanced edit toolbar active. There is no way for me to get the old one back. -- Whpq (talk) 15:15, 16 February 2011 (UTC)

Could you try again now? --Catrope (talk) 15:25, 16 February 2011 (UTC)

I followed the instructions given above and I am back in working order again. Thanks! ---RepublicanJacobite_{The'FortyFive'} 15:29, 16 February 2011 (UTC)

Reply - Still doesn't work for me. I am using Firefox version 3.6.13 on Windows XP. I shut down the browser and started it again. The checkbox was clear, but I had the enhanced edit tool bar. I checked the box and saved my preferences; opened a page to edit and confirmed I had the enhanced edit tool bar. I then unchecked the box and saved my preference. I opened a page to edit, and the enhanced edit tool bar is still there. -- Whpq (talk) 16:16, 16 February 2011 (UTC)

Try WP:BYPASS? –xeno^talk 16:18, 16 February 2011 (UTC)

Reply - Still broken for me. I cleared my entire cache and it made no difference. For extra fun, I switched to Chrome. Same problem. I then switched to IE8, and again, the same problem. Note that with IE8, I've never even visited Wikipedia so there's no way anything is cached. No matter which browser I am using, I only see the enhanced edit toolbar regardless of my preference setting. -- Whpq (talk) 16:32, 16 February 2011 (UTC)

UPDATE - I found a way to get the toolbar back! In your preferences, under the editing tab, there are two checkboxes that are related to beta features. The first is supposed to toggle between the old edit toolbar and the advanced edit toolbar. The second relates to some features. Previously, the state of the second checkbox was irrelevant. Now, in order to get the old toolbar back, you need to uncheck both boxes. -- Whpq (talk) 21:15, 16 February 2011 (UTC)

Yes, this is what the real issue was: the behavior of the second box change. The whole database thing turned out to be a red herring. I've deployed a prospective fix that should restore the old behavior, please tell me if it works. --Catrope (talk) 22:48, 17 February 2011 (UTC)

I am able to toggle between the classic toolbar and the advanced toolbar regardless of the state of the state of the "Enable Dialogs" checkbox. This is the behaviour that is expected and matches the behaviour prior to the upgrade. So inthat way, it works. This may perhaps be unrelated. The classic toolbar itself seems to have changed. The "cite button" which is the one most used by me, is on the far left of the toolbar instead of on the far right, next to the "ref" button. And when the "cite button" is clicked, the toolbar formatting gets whacky. The "cite" button moves to the top on its own. The series of template buttons are below that with their bottom edge overlapped with the rest of the classic toolbar (minus the "cite" button. -- Whpq (talk) 18:25, 18 February 2011 (UTC)

Edit toolbar preference no longer works

The new editing toolbar will not go away even when "My preferences" -> "Editing" -> "Show edit toolbar (requires JavaScript)" is cleared. :( —Lowellian (reply) 11:53, 16 February 2011 (UTC)

See thread above, this is in the process of being fixed. the wub "?!" 12:04, 16 February 2011 (UTC)

What has been done by now to fix it? Who was that who coercively enabled this so called "enhanced editing toolbar" ? And when this is going to be reverted? — Klimenok (talk) 06:58, 17 February 2011 (UTC)

Automated template updates on talk pages

There are 45 entries in the Category:Unknown-importance Pittsburgh articles, with

{{WikiProject Baseball|class=stub|importance=low}}
{{WikiProject Pittsburgh|class=Stub|importance=|auto=yes}}

templates on the talk pages. I would like to learn how to make all of these talk pages say

{{WikiProject Baseball|class=stub|importance=low}}
{{WikiProject Pittsburgh|class=Stub|importance=low}}

in an automated way. Please provide me with the tools and technical assistance to do this task.

I want to learn how to do it, not have it done for me, because I have other instances where I need to do likewise.--DThomsen8 (talk) 13:34, 16 February 2011 (UTC)

WP:AWB and/or WP:BOTREQ is the third door down. ΔT _{^{The only constant}} 13:57, 16 February 2011 (UTC)

Some revisions didn't make 1.17

It seems the changes to the diff-engine didn't make it into 1.17, especially revisions 75658 and 75662, which would have fixed some minor display issues in diffs. Were they entered in the wrong branch? — Edokter (talk) — 14:07, 16 February 2011 (UTC)

They were reverted because they changed the wrong piece of software: Wikipedia uses wikidiff2, not the PHP difference engine. The fixes were ported to the latter, but I don't know if it's been upgraded. I'll ask. --Catrope (talk) 15:14, 16 February 2011 (UTC)

Resource loader and Tracing CSS

With the new resource loader, all CSS is loaded through load.php, making it impossible to trace the origin of CSS declarations. Adding the ?debug=true to the URL does not change that. Is there another solution that enables me to trace CSS to its origin? — Edokter (talk) — 14:27, 16 February 2011 (UTC)

There's currently no way, no, though I guess it would be helpful. You can find some information in the modules= parameter to load.php, but that's it. Comments indicating where a file ends and the next one starts could be useful here. You can file a enhancement request on Bugzilla. --Catrope (talk) 15:16, 16 February 2011 (UTC)

Comments wouldn't help; the files are still loaded seperately as modules. However, if the module names were to match the filenames (or add a dummy parameter indicating it's origin), it would solve my problem. — Edokter (talk) — 15:24, 16 February 2011 (UTC)

Actually, ?debug=true does work for me. Using that tells me the correct line number for CSS declarations. If the URL already has a "?", then you need to use &debug=true instead, though. Gary King (talk · scripts) 01:28, 17 February 2011 (UTC)

I still get the same cryptic URLs (starting with load.php), except that it shows 'debug=true'. I don't see linenumbers or what else. I'm using Webkits Web Inspector. What are you using? — Edokter (talk) — 12:56, 17 February 2011 (UTC)

You don't see any line number next to load.php? It should tell you line number 1 if you have debug disabled (by default). With debug enabled, it should give you the line number. It works for me in Safari, Chrome, and Firefox. In Web Inspector, try enabling resource tracking with the Resources panel to see if that helps. Gary King (talk · scripts) 16:44, 17 February 2011 (UTC)

OK, I see them. I still have to skim the entire file to find the original location though. — Edokter (talk) — 16:57, 17 February 2011 (UTC)

If you click on the line number it should jump you directly to it in the file. Gary King (talk · scripts) 19:08, 17 February 2011 (UTC)

I know, but I still have to find out what file it comes from. Modules are merged in one big load, hence why I need to skim the file for the filenames. — Edokter (talk) — 19:16, 17 February 2011 (UTC)

I need to load debugged scripts. How can I load debugged resources? Kwj2772 (talk) 10:05, 18 February 2011 (UTC)

You add debug=true to you page url. It's only been mentioned 3 times in this very thread. :D —TheDJ (talk • contribs) 10:18, 18 February 2011 (UTC)

Links aren't being underlined

See above. I've force-refreshed, I've gone into my preferences and set from 'Always' to 'Never' and back again, and still links aren't being underlined. --Golbez (talk) 14:31, 16 February 2011 (UTC)

They underline fine for me. Have you checked your browser settings? — Edokter (talk) — 14:34, 16 February 2011 (UTC)

Broken for me since the upgrade too. Not a browser issue. tedder (talk) 14:42, 16 February 2011 (UTC)

Me as well. I haven't changed a thing considering it happened sometime while I slept. ♫ Melodia Chaconne ♫ (talk) 14:45, 16 February 2011 (UTC)

What browser are you using? — Edokter (talk) — 14:57, 16 February 2011 (UTC)

Firefox 3.6.13. No browser settings were changed between yesterday and today. --Golbez (talk) 15:00, 16 February 2011 (UTC)

3.6.13 here too. I fired up Chrome and it's broken there too. tedder (talk) 15:02, 16 February 2011 (UTC)

I have FF 3.6.13 as well. But IE Tab also doesn't underline them. ♫ Melodia Chaconne ♫ (talk) 15:01, 16 February 2011 (UTC)

What skin are you guys using ? —TheDJ (talk • contribs) 16:26, 16 February 2011 (UTC)

MonoBook. tedder (talk) 16:31, 16 February 2011 (UTC)

Same for me, no underlining under Firefox or IE 8.0 using the MonoBook skin. Beyond My Ken (talk) 17:48, 16 February 2011 (UTC)

Same here, I'm on Minefield (Firefox 4 pre-release) and Monobook. -- King of ♥ ♦ ♣ ♠ 18:21, 16 February 2011 (UTC)

Same for me, on Monobook and no underlining on both Opera 11.01 and Chrome 9.0.597.98. Nate • (chatter) 21:28, 16 February 2011 (UTC)

Filed as bugzilla:27468. —TheDJ (talk • contribs) 20:35, 16 February 2011 (UTC)

This is still a problem (I dunno how much who's changing what, granted), and honestly it gives me a headache. ♫ Melodia Chaconne ♫ (talk) 14:37, 17 February 2011 (UTC)

Since it's only a visual bug, it will get low priority from people. We can fix this in two weeks if we have to, more important broken things require attention atm. —TheDJ (talk • contribs) 19:42, 17 February 2011 (UTC)

Low priority? Huh. Some people won't edit Wikipedia until you bother to fix it. --Ghirla^-трёп- 21:11, 17 February 2011 (UTC)

Meanwhile, plenty of other people will. No need to take it personally, but minor interface issues (on the no-longer-default skin) are just lower on the priority list than some of the other upgade-related issues. That doesn't mean that the people having the issues are lower priority, just that fixing underlined links isn't the most important thing. In the meantime, I'd think tweaking your monobook.css page would fix it. (yes, it's not the best long-term solution, but it'll work in a pinch) EVula // talk // ☯ // 21:17, 17 February 2011 (UTC)

For the moment you can add a { text-decoration:underline !important; } to your monobook.js (or inject the same using appendCSS or GM_addStyle). ―cobaltcigs 21:47, 17 February 2011 (UTC)

Doesn't seem to fix it. ♫ Melodia Chaconne ♫ (talk) 23:08, 17 February 2011 (UTC)

I meant .css, oops. ―cobaltcigs 00:30, 18 February 2011 (UTC)

Oh I see what you did. You need the “a” in front as it represents the tag-name of the links, to wit:

a { text-decoration:underline !important; }

―cobaltcigs 00:33, 18 February 2011 (UTC)

Thanks very much for that work-around. I certainly understand why the developers would downgrad the problem in favor of other, more pressing fixes, but it was surprisingly difficult to edit without the underlines! Beyond My Ken (talk) 01:01, 18 February 2011 (UTC)

Yes, THIS seems to work. Thanks. ♫ Melodia Chaconne ♫ (talk) 01:12, 18 February 2011 (UTC)

Thank you! Sorry, I'm one of those who is still stubbornly stuck in 2006 and need the woobie that is underlining. Nate • (chatter) 10:16, 18 February 2011 (UTC)

Incidentally, has anyone said what the big benefit we're getting from this software upgrade is, that justified the multiplicity of problems created? Is this an upgrade for the sake of an opgrade, or what? Beyond My Ken (talk) 11:01, 18 February 2011 (UTC)

Yes developers spend a couple of hundred thousand hours of their collective time because they are plain bored and ponder whole days about how to mess up your life with a little missing line. The links have been posted a couple of times on this page and many other places, I'm all out of silver platters though, so please go look for them yourself. —TheDJ (talk • contribs) 11:06, 18 February 2011 (UTC)

Dude, I understand that you're getting frustrated, but seriously, you're coming across as a total dick at times. Comments like that don't help anything. EVula // talk // ☯ // 21:43, 18 February 2011 (UTC)

I know. I just get tired of answering the same question over and over and people demanding to be informed while they don't invest time to inform themselves by following the channels that are provided for informing them. It's not OK of me though, I should know better. Luckily the software switch will soon be over, and I can descend from my developer role back to my reader role and comment from afar, how editors haven't yet finished writing their articles before putting them online, that they haven't had their prose reviewed by an expert yet, that there are lots of errors, 'destroying' peoples lives, that there are many missing articles and that 'the editors' aren't correcting those problems soon enough. </trying to communicate my frustration to a domain the average editor might understand> —TheDJ (talk • contribs) 23:43, 18 February 2011 (UTC)

ResourceLoader is awesome

It took literally one second to log in, usually it takes 30 seconds or so to load all the js.

However, I have a gadget or script that shows a UTC clock at the top right with a purge link, and while the clock is fine, it no longer links. Any ideas? It might be the Twinkle clock, I'm not sure. /ƒETCHCOMMS/ 14:57, 16 February 2011 (UTC)

I believe it is MediaWiki:Gadget-UTCLiveClock. And now it is smaller and doesn't purge. –xeno^talk 15:02, 16 February 2011 (UTC)

Had the same issue with the clock, but it is now working. ---— Gadget850 (Ed) ^talk 16:12, 16 February 2011 (UTC)

I fixed the UTC clock. —TheDJ (talk • contribs) 16:15, 16 February 2011 (UTC)

Confirmed. Back to the original size too. –xeno^talk 16:16, 16 February 2011 (UTC)

Predictive search suggestions not working in Monobook anymore?

Is there a reason that the predictive search suggestions aren't working in Monobook anymore? –xeno^talk 15:04, 16 February 2011 (UTC)

I disabled it because of a bug, fixed the bug, then forgot to re-enable it. Should be fixed now (immediately for logged-in users, may take time to propagate for anons). --Catrope (talk) 15:19, 16 February 2011 (UTC)

Only works for me in the edit screen. Monobook, Chrome, WinXP. DuncanHill (talk) 15:32, 16 February 2011 (UTC)

Try WP:BYPASS. Working again for me, thanks Catrope. –xeno^talk 15:49, 16 February 2011 (UTC)

I tried BYPASS, and now it doesn't work in the edit box either :( DuncanHill (talk) 15:59, 16 February 2011 (UTC)

Search suggestions work for me in Monobook right now. Gary King (talk · scripts) 16:59, 16 February 2011 (UTC)

Bottom notice displaying in navigation bar in Monobook

The bottom wikipedia notice (disclaimer, privacy policy, and About Wikipedia) are being displayed on the left in the navigation bar instead of being displayed at the bottom of the page. I am using Monobook, I tried vector and it appears correctly. Also, the section edit buttons are displaying on the left instead of the right. Alpha Quadrant ^talk 15:22, 16 February 2011 (UTC)

I tried Monobook on this page, and the section edit links are appearing on the right for me. I also can't reproduce the different location of the footer. Please try disabling user scripts and gadgets one at a time, and see if that fixes it. --Catrope (talk) 15:36, 16 February 2011 (UTC)

Found the issue, it is MediaWiki:Gadget-edittop.js in gadgets. After disabling this script it appears correctly. Alpha Quadrant ^talk 15:53, 16 February 2011 (UTC)

StupidNah, it's not stupid, it's just annoying banner is not working

Resolved

The stewards elections banner keeps appearing and disappearing whenever I reach a page. Before I can click it, it disappears. --Perseus8235 15:43, 16 February 2011 (UTC)

It's probably an old banner that you already dismissed. You can clear your cookies for en.wikipedia.org to make them all reappear again. — Edokter (talk) — 15:52, 16 February 2011 (UTC)

The fact that the banner appears before it disappears was fixed recently; it was a problem with the steward elections banner borrowing very old code. --Catrope (talk) 22:49, 17 February 2011 (UTC)

Spurious/unwanted watchlist RSS token

I'm still trying to work through a problem that's causing my watchlist to hang briefly on load, but in the course of investigating it I that the watchlist RSS token field in my preferences had been filled with a random value. This could have lead to my watchlist being read by someone willing to try a lot of brute force, though of course in practice it's not very likely. The token was probably generated by various work that was done to fix preference breakage, and there's probably no way to fix erroneous tokens without clobbering good ones, but it's worth letting people know that they might have an unwanted token set. — Gavia immer (talk) 16:32, 16 February 2011 (UTC)

Code update finished?

Is the code update finished. If so, I am still having problems with inoperative scripts and gadgets (WikEd, Twinkle, Navpopups, UTC clock). --ukexpat (talk) 16:36, 16 February 2011 (UTC)

Yes finishes. Try disabling them one by one to find out which script EXACTLY is your problem, or use a javascript console. UTC clock was fixed, twinkle was fixed, popups works for me, so it's likely something other than that. —TheDJ (talk • contribs) 16:40, 16 February 2011 (UTC)

Wow, all my top links (my user page, my talk, my watchlist, etc.) are gone. Time to fiddle with the CSS again. Gary King (talk · scripts) 16:43, 16 February 2011 (UTC)

No gadgets working for me, AFAIK. Blackscreen, popups, twinkle, clock/purge, all not working. Preferences page doesn't have the tabs, it is just one long page with all the different bit under each other. Have tried bypass, logging-out-and-again. Monobook, Chrome, WinXP. DuncanHill (talk) 16:49, 16 February 2011 (UTC)

None of mine are either. In fact, unless I hit the stop button just before any page loads fully, the page disappears completely and I just get a blank white page. Something is afoot.--ukexpat (talk) 16:58, 16 February 2011 (UTC)

Also, it seems like the !important keyword in CSS doesn't work, after some quick testing. This is a crucial keyword to have. Gary King (talk · scripts) 16:56, 16 February 2011 (UTC)

Neermind, it looks like they've added "&version" to the CSS's URL, so that you won't always be loading the latest stylesheet. Which makes debugging more difficult—unless there's a way to set &debug to true? Gary King (talk · scripts) 17:10, 16 February 2011 (UTC)

Yep, just set debug=true in your query string; it will be passed to load.php and enable debug mode. It still passes version though. Reach Out to the Truth 17:37, 16 February 2011 (UTC)

Where do I do this? The wiki loads the CSS, not me, so I'm not quite sure? Gary King (talk · scripts) 17:41, 16 February 2011 (UTC)

D'oh nevermind, figured it out. Gary King (talk · scripts) 19:02, 16 February 2011 (UTC)

Change the "new section" tab text to instead display the much narrower "+". gadget looks broken (Vector, no personal js/css games). Tried unchecking (and saving) the rechecking/saving, and purging local cache and force-reloading everything. Still have "New section" instead of "+". Other gadgets (popups, UTC clock) are working correctly. DMacks (talk) 16:50, 16 February 2011 (UTC)

Well, gadgets now seem to be working, but the blackscreen is clunky - the page loads in whitescreen, then jumps to blackscreen. It used to load smoothly in blackscreen. DuncanHill (talk) 17:13, 16 February 2011 (UTC)

That's probably because all JavaScript files have been moved to the bottom of the page now, so I think all scripts will experience this "choppiness". Gary King (talk · scripts) 17:19, 16 February 2011 (UTC)

I have the same problem as DMacks; I get new section rather than +. /ƒETCHCOMMS/ 17:34, 16 February 2011 (UTC)

Fixed now —TheDJ (talk • contribs) 20:40, 16 February 2011 (UTC)

Not for me, and I am still having the other problems I mentioned above...--ukexpat (talk) 20:52, 16 February 2011 (UTC)

Better now ? I did some fixes. BTW you have a gigantic amount of userscripts installed, many VERY old and just bound to break on the smallest changes. —TheDJ (talk • contribs) 00:11, 17 February 2011 (UTC)

Haven't checked in the past few hours, but "+" is now working correctly for me. Thanks for all the hard work on this update! DMacks (talk) 01:17, 17 February 2011 (UTC)

I removed some scripts and all appears to be working fine now, thanks! – ukexpat (talk) 03:16, 17 February 2011 (UTC)

Missing on toolbar - Cite button and cite templates

Resolved

Once again, the cite option on the Editing toolbar is missing, as are the cite templates. Maile66 (talk) 16:53, 16 February 2011 (UTC)

... and for me. Tried changing skin, toggling refTools, edit toolbar with cache clear. Fiddling with vector.js didn't help either. Thincat (talk) 18:04, 16 February 2011 (UTC)

... and for me. I've really become quite dependent on the availability of the Cite button and templates. Darrell_Greenwood (talk) 19:16, 16 February 2011 (UTC)

And for me. --j⚛e decker^{talk to me} 20:22, 16 February 2011 (UTC)

Following this advice above, here is a faltering start towards a work-round (for me). In My preferences, Editing turn off the two options very near the bottom under beta features "Enable enhanced editing toolbar" and "Enable dialogs for inserting links, tables and more". Save. Then, when editing, position the cursor appropriately in editing window, scroll up the window (not merely the editing box) and click the button marked {{CITE}} (last on the right). Select appropriate button appearing underneath. "Preview citation" works but, sadly, "add citation" seems to do nothing. I still have "Show edit toolbar (requires JavaScript)" and "RefTools" on and I don't know whether their status matters. Thincat (talk) 22:31, 16 February 2011 (UTC)

Thanks, but this does nothing for me. I have Firefox. Since today (and not before), if I uncheck the suggested boxes in Preferences and Save, it tells me the Preferences were saved. But it puts the check marks right back. I have the old toolbar. It's just the Cite button that is missing. Also, some interesting funky stuff that is probably related to what they are working on. On any edit page, on the upper right, I get a red lettered "Page notice", and if I click on it, it tells me there is no Template with the name "Template/EditNotices/Page/whatever page I have open". So, I think they're still working - because I don't think that Page Notice is supposed to be there. Hopefully, the Cite button will come back soon. Maile66 (talk) 00:06, 17 February 2011 (UTC)

This is (mostly) fixed now. You'll have to bypass your cache. They removed the variable that I was using to detect whether the toolbar was enabled. The script will still be broken if you have dialogs disabled as I don't know how to detect whether the dialogs are enabled or not. Mr.Z-man 01:12, 17 February 2011 (UTC)

Consider this a virtual dancing in the aisles. The Cite button is fixed!! Thanks. Maile66 (talk) 01:16, 17 February 2011 (UTC)

I'm still a wallflower waiting for a dance;-( For the last three options in My Preferences, Editing ("Beta Enhanced toolbar", "Beta Enable dialogs for inserting" and "Labs Enable preview dialogs"), if all are off I get a {{CITE}} button which goes fine until the last moment when "add citation" does nothing. This has functionality for fillling in other fields from data extrracted from the supplied URL. However, if the last two options are off and on (in order) I get no cite option. Otherwise, I get the previous "Cite" tab (after "special characters...help") which seems to work as before. Thincat (talk) 09:28, 17 February 2011 (UTC)

Ah ha! I have switched from Vector to MonoBook skin after reading this. Now, with the three options I mentioned above Off, Off, On I get a working "Cite" button (new style). I have kept "edit toolbar" and "RefTools" On and I think this is also a requirement. Thincat (talk) 09:46, 17 February 2011 (UTC)

RefTools not working

Hi there. Since Wednesday, 18th February 2011, I've noticed that reftools is no longer working on my browser (I'm using Windowx XP, Firefox 3.6.13). Been using reftools since 2009 without any issues. I've tried out all options both in "Appearance" and "Gadgets" in the Preferences menu, yet the reftool bar doesn't appear each time I edit an article. (btw, I have java installed on my system as well). Any idea why I can't access reftools anymore? Amsaim (talk) 09:36, 17 February 2011 (UTC)

This side of the dateline: confirming. They're broken. --Old Moonraker (talk) 10:52, 17 February 2011 (UTC)

For the original edit toolbar, the only way to make it work is to disable wikEd either in gadgets or on the fly with the on/off button on the wikEd toolbar. For the enhanced toolbar, it works more often, but sometimes the cite window becomes wider than my browser window and there's no horizontal scroll bar. I greatly prefer the original toolbar & refTools plus anyway. I actually don't need the rest of the toolbar because I have wikEd, I just need the cite button. I don't like the ProveIt UI. I'm running FF 3.6.13. —UncleDouggie (talk) 11:15, 17 February 2011 (UTC)

This is also being discussed above at Wikipedia:Village_pump_(technical)#Missing_on_toolbar_-_Cite_button_and_cite_templates. Thincat (talk) 12:22, 17 February 2011 (UTC)

I see I am not alone in being affected by the recent media wiki and reftools changes. See Wikipedia talk:RefToolbar 1.0#broken since 14 February 2011? where I tested various Gadget combinations. I still wish that the old toolbar was brought back ([6] [7]), but this combination at least gets me the new-style Cite button working on Firefox 3.6.13 with monobook:

"Show edit toolbar" off

"refTools" Gadget ON

"Enable enhanced editing toolbar" ON

"Enable dialogs for inserting links, tables and more" ON

-84user (talk) 12:45, 17 February 2011 (UTC)

Also on FF 3.6.13 and having gone to Monobook (for exactly this reason), this gives me the Cite tab as previously but not the new Cite button. For this I need (as I reported above)

"Show edit toolbar" ON

"refTools" Gadget ON

"Enable enhanced editing toolbar" OFF

"Enable dialogs for inserting links, tables and more" OFF

"Enable preview dialog" ON

I would prefer your setup if it worked for me. Thincat (talk) 13:06, 17 February 2011 (UTC)

Maybe something changed in media wiki very recently but I can now get the old edit toolbar plus the old "cite" icon with this combination:

Preferences / Editing / Advanced options : ON: Show edit toolbar (requires JavaScript)

Preferences / Editing / Beta features  : OFF: all options

Preferences / Gadgets / Editing gadgets  : ON: refTools

I tested the icons B, I, #R, <ref /ref> and <<CITE>> for web and news.

Here is the combination that gets a working new-style toolbar plus working new style cite (it previewed and inserted citations for {{cite web}}):

Preferences / Editing / Advanced options : OFF: Show edit toolbar (requires JavaScript)

Preferences / Editing / Beta features  : ON: Enable enhanced editing toolbar

Preferences / Editing / Beta features  : ON: Enable dialogs for inserting links, tables and more

Preferences / Editing / Labs features  : OFF: Enable preview dialog

Preferences / Gadgets / Editing gadgets  : ON: refTools

I have no other Editing gadgets on, but I do have Browsing gadgets / Navigation popups ON; I also have this monobook.js. -84user (talk) 13:47, 17 February 2011 (UTC)expanded the prefs. -84user (talk) 13:55, 17 February 2011 (UTC)

Correction to my preferences above. It appears that the above preferences do not get the old CITE working. Instead I forgot that I still had "importScript('User:Apoc2400/refToolbar.js');" in my User:84user/monobook.js. That line is essential. Without it there is no CITE icon displayed in the old style edit toolbar. -84user (talk) 20:11, 17 February 2011 (UTC) strike through correction; I can confirm Kaldari's report that the old settings work again. Thanks all. -84user (talk) 10:53, 18 February 2011 (UTC)

OK, all the RefTools stuff should be fixed now. Feel free to go back to your old settings. Kaldari (talk) 02:45, 18 February 2011 (UTC)

For remaining issues with wikEd compatibility, see Wikipedia_talk:RefToolbar_1.0#wikEd_compatibility. —UncleDouggie (talk) 07:58, 18 February 2011 (UTC)

Clear buffer if page shifted?

Hi,
This has happened to me countless times, so presumably others see it too.

The page is drawn. I click on something I want to see.
Then, it happens that WP is seeking donations, or I have new messages.
Page shifts downward.
But my mouse click is still active.
So I get something I didn't ask for.

Isn't it straightforward just to clear the input buffer in cases where you do a page redraw?
Or shift the co-ordinates of the pending click(s) to reflect the fresh page layout?
Clearly the former option is simpler.
Cheers, Varlaam (talk) 17:42, 16 February 2011 (UTC)

This is a browser-related issue, I believe. I don't think JavaScript can control what element is activated when the mouse is clicked on something else. Gary King (talk · scripts) 17:48, 16 February 2011 (UTC)

Freenode

I've just had access difficulties for quite some time - enough to make a hot drink and feed the cat. Whilst this was going on, all I could get was the standard message beginning "WIKIMEDIA FOUNDATION Error Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. You may be able to get further information in the #wikipedia channel on the Freenode IRC network.". I have two problems here.

First, the #wikipedia link doesn't do anything at all in Chrome; in Firefox it asks me to choose an application, but I have no idea which application would be correct for this; whereas in Opera, I get to a "New account wizard". I don't necessarily want to post anything yet: I just want to find out what's wrong.

My second problem is that Freenode IRC network takes me to an "About the Network" screen, and there doesn't seem to be anywhere where I might enter this "#wikipedia" channel name, other than the Google search box upper right, which gives me a whole heap of irrelevant and out-of-date stuff. --Redrose64 (talk) 17:50, 16 February 2011 (UTC)

IRC. Prodego ^talk 17:53, 16 February 2011 (UTC)

You might want to try the Freenode webchat. --Morn (talk) 18:14, 16 February 2011 (UTC)

@Prodego: I had already worked out that it meant "internet relay chat". The point is, I can't get to anything that might tell me what's wrong with the Wikimedia servers.

@Morn: this wants me to create an account. Wikipedia (normally) allows non-registered users to read pages, so does Bugzilla. I would like to do similarly with Freenode. --Redrose64 (talk) 18:24, 16 February 2011 (UTC)

It asks you to supply a nickname, not to create an account. You'll need a nickname to connect to an IRC server, you can't connect otherwise. –xeno^talk 18:26, 16 February 2011 (UTC)

Also if you connect to freenode, your IP address will be publicly viewable by anyone else in the chat. Prodego ^talk 18:27, 16 February 2011 (UTC)

But if you have an account you can apply for a cloak. --Ron Ritzman (talk) 02:31, 17 February 2011 (UTC)

Disable smaller font size of elements gadgets no longer works without javascript

The gadget "Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists" worked fine without javascript until today with Mediawiki 1.17. I prefer to leave javascript off most of the time, but I also love being able to read the references etc text at the same font size. Is there a way to resolve this (new) issue? TransUtopian (talk) 17:52, 16 February 2011 (UTC)

What browser and skin are you using? —TheDJ (talk • contribs) 20:45, 16 February 2011 (UTC)

I'm using Opera 10.60 and Monobook. TransUtopian (talk) 23:09, 16 February 2011 (UTC)

It should work even without JS enabled for your browser, since it uses CSS, not JS. Gary King (talk · scripts) 01:25, 17 February 2011 (UTC)

Actually, it now relies on the resource loader, which is javascript, to load all the gadgets. I don't know if gadgets required javascript before the update. — Edokter (talk) — 01:32, 17 February 2011 (UTC)

Since I disable JS unless I specifically need it for something, I'd say this gadget didn't require it before. Is there something I can add to my CSS that'll duplicate the gadget, or can specific gadgets be removed from using the resource loader (or have a duplicate version that doesn't use it)? TransUtopian (talk) 12:01, 17 February 2011 (UTC)

(←) Put the following line at the top of your skin CSS file:

@import url(http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-NoSmallFonts.css&action=raw&ctype=text/css);

That should do the trick. — Edokter (talk) — 12:46, 17 February 2011 (UTC)

That workaround works. Thank you very much, Edokter! And thanks to everyone else for helping in the process. TransUtopian (talk) 16:25, 17 February 2011 (UTC)

Update: The NoSmallFonts works, but it disables the non-display of citation needed tags I added long ago to my skin CSS. (I briefly reverted to confirm.) My CSS includes

.Template-Fact {display:none;}
.Inline-Template {display:none;}

Can you please tell me if there's a way to make this work again? TransUtopian (talk) 18:18, 17 February 2011 (UTC)

That is weird, but try the following:

.Template-Fact {display:none !important;}


.Inline-Template {display:none !important;}

— Edokter (talk) — 20:09, 17 February 2011 (UTC)

I tried it but I'm afraid it didn't work. FYI, I also have .ambox {display:none;} in there to suppress maintenance boxes, which still works fine. I tried the two lines you suggested atop the ambox line, and then with ambox in the middle (its original position). Do you have any other ideas? TransUtopian (talk) 21:30, 17 February 2011 (UTC)

There were some chages in CSS with regards to specificallity; that may be the cause. Try the following:

span.Template-Fact {display:none;}


span.Inline-Template {display:none;}

— Edokter (talk) — 23:03, 17 February 2011 (UTC)

Tried it and a couple variations (moving them around, adding a period before span), saving the CSS each time and force-refreshing a page with [citation needed]s. I can still see them. I'm willing to try more ideas if you've got them. TransUtopian (talk) 00:19, 18 February 2011 (UTC)

OK, I need to know what you ar trying to hide, so I can come up with the proper CSS. — Edokter (talk) — 00:21, 18 February 2011 (UTC)

(←) OK, I found what you need:

sup.Template-Fact {display:none;}


sup.Inline-Template {display:none;}

— Edokter (talk) — 00:25, 18 February 2011 (UTC)

I'm afraid that didn't work either. You're correct that I'm trying to hide the superscripted templates (I assume that's what sup means) at Wikipedia:WikiProject Inline Templates, primarily Template:Citation needed. "View source" told me it's based on Template:Fix so I tried sup.Template-Fix {display:none;} after I tried Fact, but no dice. TransUtopian (talk) 02:09, 18 February 2011 (UTC)

YES! It finally works, after reordering the elements, like so

@import url(http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-NoSmallFonts.css&action=raw&ctype=text/css);
.ambox {display:none;}
sup.Template-Fact {display:none;}
sup.Inline-Template {display:none;}

Result: No small text, no maintenance amboxes, no citation needed inline templates. I don't know why only that order works, but I'm thrilled it does. Thank you again, Edokter, for your invaluable and patient help. TransUtopian (talk) 19:01, 18 February 2011 (UTC)

Glad it works. Yes, the @import line should be at the top, but I already said that :) — Edokter (talk) — 21:04, 18 February 2011 (UTC)

Yes, you did. :) I played around with it afterwards just to see if everything would quirkily work in another position. The .ambox has to be above the sups to make everything work. Having it below or between the sups was making the sups not work. TransUtopian (talk) 21:11, 18 February 2011 (UTC)

I can't explain that one. Oh well... — Edokter (talk) — 22:05, 18 February 2011 (UTC)

The signature button is not working

The "Your signature with timestamp" button on the toolbar above editor window as well as signature sign in Wiki markup, is not working properly. When I press it while editing, nothing happens, expect my screen moves upwards towards start of the discussion. In case where I am starting a thread (like now), when I pushed the button or Wiki markup symbol, the signature appeared in Subject/headline textbox.Redtigerxyz ^Talk 18:14, 16 February 2011 (UTC)

Seems to be working in Monobook (nb with "Enable enhanced editing toolbar" disabled) - --Redrose64 (talk) 18:26, 16 February 2011 (UTC)

Horizontal scrollbar on nearly all pages

Now that the new updates have been installed, my browser places a horizontal scrollbar on nearly all pages I view while logged in. This happens in both Firefox and IE. Is this a known issue and is there a known solution? It's minor but annoying. ElKevbo (talk) 18:27, 16 February 2011 (UTC)

I'm having the same experience here; does anybody have any input? — Fourthords | =/\= | 22:05, 16 February 2011 (UTC)

I'm not experiencing this. Which skin are you guys using? Most people are using Vector and don't appear to have any problems regarding this. I'm using Monobook and don't have this problem. Gary King (talk · scripts) 01:25, 17 February 2011 (UTC)

I finally figured it out after some trial and error: in my preferences, I had enabled the gadget to widen the Wikipedia search box ("Widen the search box in the Vector skin."). Once I disabled that, my stupid horizontal scrollbar went away! Hope this works for you! — Fourthords | =/\= | 01:31, 17 February 2011 (UTC)

Yup, that's it! Thanks! ElKevbo (talk) 01:52, 17 February 2011 (UTC)

Thank you. I was wondering about that. I'm actually using a different searchbox-widening script; it looks like 1.17 forces the searchbox to grow to the right rather than touch the pristine empty space to the left. — Gavia immer (talk) 01:43, 17 February 2011 (UTC)

Mobile site redirects to regular site first now

Since JavaScript files are moved to the bottom of the page now, whenever a mobile device visits the wiki, it first loads the entire regular page, then is redirected to the mobile version. It seems better to at least move the mobile redirect code to the top of the page like it was before. Gary King (talk · scripts) 18:48, 16 February 2011 (UTC)

This is not possible at the moment I think. What is needed is that the squids take care of redirecting. JS is just an ugly bandaid that we really shouldn't use for this. There is a bugzilla ticket for that bugzilla:24859. —TheDJ (talk • contribs) 20:51, 16 February 2011 (UTC)

Blue new message bars?!

Is there a CSS snippet I can get to change it back to orange? /ƒETCHCOMMS/ 19:09, 16 February 2011 (UTC)

Better still, change it back. I don't remember seeing any discussion or consensus for this change. Mjroots (talk) 19:15, 16 February 2011 (UTC)

(edit conflict) Is there a good reason (or consensus, for that matter) for the change in the first instance? Should be restored in the common css, imo. –xeno^talk 19:15, 16 February 2011 (UTC) (FWIW, it is still orange for me, on monobook)

Yeah, I like the orange one better too. Catches your eye better. --T H F S W (T · C · E) 19:25, 16 February 2011 (UTC)

I don't care what color the bar is, but if someone is going to change the 'new message' notice, could I make a plea for the addition of a history button? "Last change" fairly often leads me to miss messages (when multiple edits are made to the page in short succession). WhatamIdoing (talk) 19:32, 16 February 2011 (UTC)

div.usermessage { background-color: #FFCE7B; border: 1px solid orange; } in your css would change it back, I suspect. @WhatamIdoing, there's some script to do that I believe, I'll see if I can find it for you (here you go) . - Kingpin¹³ (talk) 19:38, 16 February 2011 (UTC)

Whose decision was this? Bad. Very bad. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 19:49, 16 February 2011 (UTC)

Someone isn't reading what is written. I don't want to have to go round fiddling with codes that I don't understand to get back something that appears to have been changed without discussion and therefore without consensus. I want the message bar changed back to how it was. A RFC or similar should then be opened on whether or not the community desires the change, or whether it should be an option, like the [edit] button at the end of header text instead of at the right side of the page. Mjroots (talk) 19:55, 16 February 2011 (UTC)

I believe this can be easily fixed by editing Mediawiki:Common.css (or maybe just MediaWiki:Vector.css) and I have suggested it be changed back at MediaWiki talk:Common.css#MW 1.17 now live, juicy style/script excitingness for all. –xeno^talk 19:58, 16 February 2011 (UTC)

Mr. MediaWiki 1.17 isn't very nice. --Perseus8235 19:56, 16 February 2011 (UTC)

Now that's not very fair, I wouldn't put it down simply because it changes the colour of the new messages banner. Just to better explain how to apply my piece of css up above, simply visit Special:MyPage/vector.css, click edit, paste in div.usermessage { background-color: #FFCE7B; border: 1px solid orange; } and then select save. Everything will be back to normal for you. If we placed this code in the MediaWiki:Vector.css as xeno mentions, it would be back to normal for everyone, but we'd need consensus for that. For those asking why this was changed, it was originally changed at another wiki (they do exist) specifically for vector, because it works better with the colour scheme. It was discussed briefly at bugzilla (I believe). - Kingpin¹³ (talk) 20:11, 16 February 2011 (UTC)

I don't think we need consensus to restore the status quo. Why was it changed globally, instead of for the particular wiki that requested it? –xeno^talk 20:14, 16 February 2011 (UTC)

Consensus???? Per Xeno. Despite your sracasm Kingpin most of us are aware that other wikis exist. Pedro :  Chat  20:23, 16 February 2011 (UTC)

Could you clarify what you mean by "consensus??"? I think xeno meant it wasn't needed to restore it at enwiki, not that there was no need for consensus to restore it globally.. - Kingpin¹³ (talk) 20:28, 16 February 2011 (UTC)

Yes, that would be the "per Xeno" bit. Pedro :  Chat  20:38, 16 February 2011 (UTC)

Well it was to start with, you see it was changed for that particular wiki first, and they decided it worked well enough to make it global. Yeah, maybe we can just change it back, I guess the only problem is we want to be sure, so we're not going backwards and forwards with the common css files - Kingpin¹³ (talk) 20:21, 16 February 2011 (UTC)

I must admit, I'm fairly confused as to why that this change was made without local consensus. I understand that en.wiki is not the only Wikimedia project, but it is the largest. And we have a hard enough time getting changes through where unanimous local consensus exists - why was this changed without so much as a "hey, we're planning on doing this?" (I realize you personally were not responsible, do please don't take this as shooting the messenger - my question is to whoever knows the answer) –xeno^talk 20:24, 16 February 2011 (UTC)

this is the dumbest thing I've seen lately; this bar is not supposed to blend in, it's supposed to pop out at you. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:22, 16 February 2011 (UTC)

Geez, people could show some appreciation for the work that went into this update, it's not particularly "dumb". After-all you don't want it flashing-bright-pink do you? :). It's really a matter of personal preference, and I've given you some code up above which allows you to set it on a personal level. - Kingpin¹³ (talk) 20:28, 16 February 2011 (UTC)

As a matter of fact, flashing-bright-pink would be even better than orange. People are supposed to see it. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:30, 16 February 2011 (UTC)#

If you say so, but I doubt many would agree with you about that, - Kingpin¹³ (talk) 20:45, 16 February 2011 (UTC)

I appreciate the hard work that developers do, and generally cringe when I see them being bitten; but I think that they would be even more appreciated (and incur less bite marks) if they asked us, or gave us a heads up, prior to making a sweeping change like this. The new messages bar is a central component of Wikipedia that has been orange for as long as I can remember. Do you happen to have any links to where this was discussed? I couldn't find anything using an advanced bugzilla search. –xeno^talk 20:34, 16 February 2011 (UTC)

Don't worry, it's not your comments I have an issue with. Yeah, bugzilla's search is impossible to use, here's a link to a discussion about it. I got that from searching through my history, I think I originally went there from another discussion on-wiki about the changes. Apparently my memory may be a little bit wrong, and the German Wikipedia didn't actually implement it as a standard, just as a common change users made. - Kingpin¹³ (talk) 20:45, 16 February 2011 (UTC)

Thank you for the link. Based on that, I'm still pretty astonished that it went through on a global basis despite the objections raised there. –xeno^talk 20:49, 16 February 2011 (UTC)

← I've initiated an editprotected request at MediaWiki talk:Vector.css#Change "You have new messages bar" back to orange. –xeno^talk 20:49, 16 February 2011 (UTC)

Status Quo restored. However might I suggest we look at ways to make the messages bar more "vector" like, but keeping it more visible ? I think that is the least we can do. —TheDJ (talk • contribs) 21:04, 16 February 2011 (UTC)

That sounds reasonable, as long as the discussion is well-trafficked and widely-advertised and so any changes have consensus and do not take users by surprised. Thanks for fulfilling the editprotected request. –xeno^talk 21:11, 16 February 2011 (UTC)

They've been made aware of our displeasure at the lack of discussion over at bugzilla. As I stated earlier, this should really be the subject of a RFC, with all options explored (status quo, change to blue, enable blue [and possibly other colours] as a user option etc). Mjroots (talk) 21:19, 16 February 2011 (UTC)

Parkinson's Law of Triviality is in full effect. the wub "?!" 22:35, 16 February 2011 (UTC)

Sometimes the color of the bike shed really does matter (it might seem trivial to you, but the neighbors have to see it too). —Emufarmers^(T/C) 23:32, 16 February 2011 (UTC)

In this instance, a better analogy might be "the color of the life raft." The bar's appearance was based upon something other than aesthetics, and it appears that this fact was overlooked/ignored (even after it was pointed out). —David Levy 00:28, 17 February 2011 (UTC)

The orange has always driven me crazy, but I agree that the light blue was worse because it didn't stand out at all. Thanks to this thread, I now have my own pleasing medium purple. It might be a good candidate for other vector users as well. I rounded the corners slightly, but less than the blue version. —UncleDouggie (talk) 11:00, 17 February 2011 (UTC)

You have new messages (last change).

I've reverted it in revision 82315. (X! · talk)  · @064  ·  00:32, 17 February 2011 (UTC)

Is Phase3 the live version? Or do we have to wait until 1.18? — Edokter (talk) — 00:40, 17 February 2011 (UTC)

"Phase 3" simply means MediaWiki. The key part of that path is "trunk", which is the current development branch (1.18alpha). Wikimedia sites are running the 1.17wmf1 branch, and it hasn't been reverted there. Reach Out to the Truth 03:04, 17 February 2011 (UTC)

Yay, this seems to be fixed. However, is it just me or are redlinks appearing in a darker red? Can I have the CSS snippet to change that back to #CC2200, or is this not possible? /ƒETCHCOMMS/ 03:11, 17 February 2011 (UTC)

They look identical to this text sample that is #CC2200 for me. —UncleDouggie (talk) 09:14, 17 February 2011 (UTC)

Hmm, it was different before (I compared) but looks back to normal now to me. /ƒETCHCOMMS/ 22:23, 17 February 2011 (UTC)

I like the purple bar, but I just don't know if it's obnoxious enough. Amazingly, some people claim to not even notice the retina-burning orange bar. :/ --Dorsal Axe 21:20, 17 February 2011 (UTC)

Perhaps you would prefer one of these? —UncleDouggie (talk) 01:11, 18 February 2011 (UTC)

You have new messages (last change).

You have new messages (last change).

You have new messages (last change).

This might be even more obvious:

<div style="background-color:#5aed43; border:1px solid #ff570a; color:#cc0bbd; font-weight:bold; margin:2em 0 1em; padding:.5em 1em; text-align:left; Template:Border-radius; Template:Box-shadow; 3px;">You have new messages (last change).

Unfortunately, the text-decoration:blink property is apparently blocked by MediaWiki. Sadness :( /ƒETCHCOMMS/ 21:21, 18 February 2011 (UTC)

No it's not, but it isn't support by Internet Explorer or Google Chrome. — Dispenser 22:47, 18 February 2011 (UTC)

Can I make a suggestion here? something I used to do was resize the message bar and make it fixed position, so that it would always pop up on my browser window in the same position. I'm not suggesting anything that drastic, but, we could keep the vector blue message bar (which looked nice) but add in a small, separate fixed-position div of some bright color that would always be visible onscreen when you have a message waiting. best of both worlds that way. I'd give a demo, but (if I remember correctly) fixed position divs get flagged by the vandalism software because of abuses. --Ludwigs2 23:02, 18 February 2011 (UTC)

Wiki loads older CSS version

Okay, so after fixing up my monobook.css, everything looks like it's back to normal now. However, the only problem is that the wiki is loading an older version of my stylesheet. What I am currently doing right now, as a (hopefully) temporary solution, is I created a Greasemonkey script to remove the "&version=" where the wiki calls my monobook.css, so that it will always grab the latest version rather than grab a version that's a few hours old. However, does anyone have a more permanent fix for this, or should I just always wait for the cached CSS on the server-side to catch up to the actual version? Gary King (talk · scripts) 20:11, 16 February 2011 (UTC)

This shouldn't happen. RL was written so that this would not be necessary. —TheDJ (talk • contribs) 20:59, 16 February 2011 (UTC)

Things seemed to have settled down regarding this. Initially, I did spend a few hours working on it, though, noticing that CSS appeared differently in Firefox and Chrome, whether debug was enabled or disabled, and whether &version= was there or not. Gary King (talk · scripts) 01:19, 17 February 2011 (UTC)

Preload text may be incorrect

1.17 includes a fix for Template:Bug, which means that "preload" pages will now honor <noinclude>. This can cause breakage if the preload page includes <noinclude> text that should be included in the newly-created page. It can be fixed easily enough, to output a into the editbox use something like <noin<noinclude/>clude>. If you understood that, please check any preload texts to ensure they still generate the correct edit box contents. Anomie⚔ 20:14, 16 February 2011 (UTC)

The new edit box

...sucks. How can I change it back? Ten Pound Hammer, his otters and a clue-bat • ^{(Otters want attention)} 20:56, 16 February 2011 (UTC)

Agreed. Why does it take huge amounts of consensus to activate even the tiniest useful features, yet all these garbage front-end visual changes are shoved down our throats with asking? Change the vertical linespacing to the same as the regular edit window and get the vector-style tool bar out of monobook. - ʄɭoʏɗiaɲ ^τ _¢ 21:00, 16 February 2011 (UTC)

See Wikipedia:Village pump (technical)#Editing above. -- Whpq (talk) 21:09, 16 February 2011 (UTC)

(e/c)Because errors are made and not everything can be fixed after an error. See comments by catrope in #Editing. And for the last FREAKING TIME assuming some god damn good faith on part of the developers. OR F'ing leave. —TheDJ (talk • contribs) 21:10, 16 February 2011 (UTC)

I mean it by the way, I have totally had it with people complaining about the work that the developers are doing. I've warned some of these people multiple times on this page, I can't believe I would have to go towards throwing official warnings on talk pages and entering the process towards a block of a user, don't make me go that way. You people should know better. —TheDJ (talk • contribs) 21:14, 16 February 2011 (UTC)

By all means, and lose your privileges for making a shitty decision based on your emotional reaction to the situation. I have every right to complain and assert that no consensus was attained to make such changes. I have every right to assert that the new appearance looks shitty in my eyes. Please, start blocking users by this reasoning so we can open an WP:RFC/U and you can become a regular user. Developers act on a job that is given to them. Who told the developers to do this? That's who I am criticizing, not the developers that merely programmed the code as they were instructed to. - ʄɭoʏɗiaɲ ^τ _¢ 22:19, 16 February 2011 (UTC)

And don't vandalize my talk page either, TheDJ. Disagreeing with others opinion is not assuming bad faith. Nobody has to like what the developers make. We aren't obligated to applaud what they put out. Just as you placed a warning on my page, I have now placed one on yours; both are equally unwarranted. - ʄɭoʏɗiaɲ ^τ _¢ 01:50, 17 February 2011 (UTC)

If we required consensus for each and every little thing (including wiping one's butt), then nothing new would ever get implemented due to the fact that some people just don't like change, period. –MuZemike 21:13, 16 February 2011 (UTC)

And that's why reftools still isn't turned on by default, despite actual consensus? You're right, people don't like change. The correct action to such a situation is to give users the option of "upgrading" to the new appearance. - ʄɭoʏɗiaɲ ^τ _¢ 22:19, 16 February 2011 (UTC)

The reason RefTools have not been turned on is that we were waiting for the 1.17 rollout to happen to enable it. But don't let the facts get in the way of a good rant. Titoxd^{(?!? - cool stuff)} 01:59, 17 February 2011 (UTC)

I think the point is that this change is seen as an attempt to "Vectorize" the monobook style. It seems bizarre why this change would be made in the first place. At the very least, these types of changes should be opt-in, not opt-out. SnottyWong ^confer 21:15, 16 February 2011 (UTC)

Read !!!!!. —TheDJ (talk • contribs) 21:20, 16 February 2011 (UTC)

DJ, I know this is stressful on your end, and the unnamed developers. Sometimes, unless somebody like you puts that directive about "Read!!!", it's not always easy to find on this page who is saying what that impacts one's particular case. And sometimes...the issue is not about this upgrade, but it just seems to be. So, thanks to the developers and what they are trying to accomplish. Hope it gets better for us all.Maile66 (talk) 21:42, 16 February 2011 (UTC)

FWIW - I was dismayed to find the new toolbar when I logged in; but found what I needed here to unclick the button I had set in my preferences & it's back. So, no big deal, really. As long as we can get back the toolbar we're used to seeing, life is good. Truthkeeper88 (talk) 22:25, 16 February 2011 (UTC)

I totally agree. Thanks to the other users who helped me retrieve my sanity by actually making the effort to explain what to do to get it working properly again. I am, however, concerned about the hundreds of users who must be having the same experience and the same difficulty in tracking down a sensible answer. Deb (talk) 08:23, 17 February 2011 (UTC)

Yeah, it seems really bizzare that they would enable this for everyone again. Surely the only people who had it disabled in the first place are the people who want it disabled? --Dorsal Axe 21:24, 17 February 2011 (UTC)

If you would read the other section linked by TheDJ above, you'd see this was an accident affecting about 15% of the users who had turned off the new toolbar, and it happened because I was totally wrong about the cause of a bug I was trying to fix. We change the default value of a preference sometimes (affecting all users who had set the preference to the old default), but I don't think we would ever change the preferences of users who consciously opted out of a feature that some people seem to hate with a passion; we're not evil, you know ;) --Catrope (talk) 22:57, 17 February 2011 (UTC)

Broken file

See File:Blinx Time Controls.png. When I go there, I get a weird SQL error. Any ideas? SnottyWong ^talk 21:12, 16 February 2011 (UTC)

Interestingly enough, the image displays just fine, just can't go to its page: — SnottyWong ^converse 21:14, 16 February 2011 (UTC)

Fixed

!log catrope synchronized php-1.17/wmf-config/db.php  'Depool srv178 from ES'

. —TheDJ (talk • contribs) 21:19, 16 February 2011 (UTC)

Thanks. SnottyWong ^prattle 21:34, 16 February 2011 (UTC)

Underlined links and a more general changes query

How comes i can no longer have links underlined? Frankly, something as seemingly small as this was actually one of the biggest reasons i could tell whether i was logged in or not.

Whilst we are on the subject of links, can someone point me in the direction of the changes to the user interface that have taken place today? Also what does global account do? Simply south...... 22:02, 16 February 2011 (UTC)

See #Links aren't being underlined. — Edokter (talk) — 22:20, 16 February 2011 (UTC)

Table show/hide disfunction

If I am on the right place: when asking for an uncollapse, it does not happen and my screen jumps to top-of-page. Example: (see also page Unicode character property):

General Category (Unicode Character Property)
Value	Category Major, minor	Basic type	Character assigned	Count (as of 15.1)	Remarks
L, Letter; LC, Cased Letter (Lu, Ll, and Lt only)
Lu	Letter, uppercase	Graphic	Character	1,831
Ll	Letter, lowercase	Graphic	Character	2,233
Lt	Letter, titlecase	Graphic	Character	31	Ligatures or digraphs containing an uppercase followed by a lowercase part (e.g., Dž, Lj, Nj, and Dz)
Lm	Letter, modifier	Graphic	Character	397	A modifier letter
Lo	Letter, other	Graphic	Character	132,234	An ideograph or a letter in a unicase alphabet
M, Mark
Mn	Mark, nonspacing	Graphic	Character	1,985
Mc	Mark, spacing combining	Graphic	Character	452
Me	Mark, enclosing	Graphic	Character	13
N, Number
Nd	Number, decimal digit	Graphic	Character	680	All these, and only these, have Numeric Type = De
Nl	Number, letter	Graphic	Character	236	Numerals composed of letters or letterlike symbols (e.g., Roman numerals)
No	Number, other	Graphic	Character	915	E.g., vulgar fractions, superscript and subscript digits
P, Punctuation
Pc	Punctuation, connector	Graphic	Character	10	Includes spacing underscore characters such as "_", and other spacing tie characters. Unlike other punctuation characters, these may be classified as "word" characters by regular expression libraries.
Pd	Punctuation, dash	Graphic	Character	26	Includes several hyphen characters
Ps	Punctuation, open	Graphic	Character	79	Opening bracket characters
Pe	Punctuation, close	Graphic	Character	77	Closing bracket characters
Pi	Punctuation, initial quote	Graphic	Character	12	Opening quotation mark. Does not include the ASCII "neutral" quotation mark. May behave like Ps or Pe depending on usage
Pf	Punctuation, final quote	Graphic	Character	10	Closing quotation mark. May behave like Ps or Pe depending on usage
Po	Punctuation, other	Graphic	Character	628
S, Symbol
Sm	Symbol, math	Graphic	Character	948	Mathematical symbols (e.g., +, −, =, ×, ÷, √, ∊, ≠). Does not include parentheses and brackets, which are in categories Ps and Pe. Also does not include !, *, -, or /, which despite frequent use as mathematical operators, are primarily considered to be "punctuation".
Sc	Symbol, currency	Graphic	Character	63	Currency symbols
Sk	Symbol, modifier	Graphic	Character	125
So	Symbol, other	Graphic	Character	6,639
Z, Separator
Zs	Separator, space	Graphic	Character	17	Includes the space, but not TAB, CR, or LF, which are Cc
Zl	Separator, line	Format	Character	1	Only U+2028 LINE SEPARATOR (LSEP)
Zp	Separator, paragraph	Format	Character	1	Only U+2029 PARAGRAPH SEPARATOR (PSEP)
C, Other
Cc	Other, control	Control	Character	65 (will never change)	No name, <control>
Cf	Other, format	Format	Character	170	Includes the soft hyphen, joining control characters (ZWNJ and ZWJ), control characters to support bidirectional text, and language tag characters
Cs	Other, surrogate	Surrogate	Not (only used in UTF-16)	2,048 (will never change)	No name, <surrogate>
Co	Other, private use	Private-use	Character (but no interpretation specified)	137,468 total (will never change) (6,400 in BMP, 131,068 in Planes 15–16)	No name, <private-use>
Cn	Other, not assigned	Noncharacter	Not	66 (will not change unless the range of Unicode code points is expanded)	No name, <noncharacter>
		Reserved	Not	824,652	No name, <reserved>

-DePiep (talk) 22:03, 16 February 2011 (UTC)

Collapsable and Sortable don't mix very well. — Edokter (talk) — 22:28, 16 February 2011 (UTC)

Metoo: seems to be related (so: combination => bug) -DePiep (talk) 23:39, 16 February 2011 (UTC)

Since? -DePiep (talk) 22:29, 16 February 2011 (UTC)

This is probably caused by a conflict between MediaWiki:CollapsibleTemplates.js and the new MediaWiki 1.17 JS code. Kaldari (talk) 22:29, 16 February 2011 (UTC)

Sorry, that's on Commons. The code here is in MediaWiki:Common.js. Kaldari (talk) 22:32, 16 February 2011 (UTC)

Well, it looks like it is introduced (broken) by 1.17. What do we do? -DePiep (talk) 22:34, 16 February 2011 (UTC)

Best ask Krinkle, he made some modifications to common.js today. — Edokter (talk) — 22:53, 16 February 2011 (UTC)

Are we 100% sure this ever worked ? —TheDJ (talk • contribs) 22:57, 16 February 2011 (UTC)

Yes, it worked. btw, I asked Krinkle at their Commons talkpage. -DePiep (talk) 23:01, 16 February 2011 (UTC)

Eh, TheDJ, why the question? Anything strange in template's history or usage? -DePiep (talk) 23:16, 16 February 2011 (UTC)

Strangely, this bug doesn't happen if you're looking at the table in an edit preview, only on live pages. Kaldari (talk) 23:34, 16 February 2011 (UTC)

Come to think of it, this probably is because the sortable code breaks the collapse code. Krinkle will probably deal with that tomorrow. load order will probably matter in this case. —TheDJ (talk • contribs) 23:47, 16 February 2011 (UTC)

The sortable code hasn't changed and is deprecated (soon to be replaced, for now the legacy ts_sortable will just continue to work). The collapsing code is not part of core and made on Wikipedia. Neither has changed recently, so I'm not sure how I can be of help. I doubt this ever worked. Since there's a lot of my agenda right now so I'm going to skip this for now since it's deprecated. The new collapser part of core (will be released in 1.18 or sooner) works fine with the tablesortable code as you can see on this demo page which has sortable and collapsible tatbles and what not all working fine. Krinkle (talk) 19:34, 17 February 2011 (UTC)

Again, yes it did work. Very unsympathic, this suggestion (and no more than that) (earlier written by TheDJ here), that it might not have worked before. If you doubt it, please reinstate the previous situation. E.g. the template here did sort&hide well since last August. Other formerly well functioning templates: {{Bidi Class (Unicode)}}, {{Unicode blocks}}, {{ISO 15924 script codes and Unicode}}. This is just my own catalog.

Whatever the code background, it was broken recently. "deprecated" is no reason to break it. "is not part of core" is not so either.

In general: a working thing is broken. So we should restore somehow. If Krinkle is short in time, just revert or ask someone else. -DePiep (talk) 20:02, 17 February 2011 (UTC)

This is probably caused by the JS using killEvt() which is deprecated now. See http://www.mediawiki.org/wiki/ResourceLoader/JavaScript_Deprecations. Kaldari (talk) 05:17, 18 February 2011 (UTC)

So: deprecated yes, unavailable no. If I read the link well, the deprecated functions are still available now (in 1.17), but not for ever. This gives "us" the time to replace then with modern variants. All right then. Replace with something new if and when it works, I'd say. On top of this, is it required to push these changes while 1.17 is rolled out as it is? Is there something in this development-to-production stream I do not get? -16:55, 18 February 2011 (UTC)

I have an explanation. This edit replaced addOnloadHook(createCollapseButtons) (which means onload these days) with $(createCollapseButtons) (which means $(document).ready) making it run a bit sooner than before. As a result, sortables_init() from wikibits is now executed after createCollapseButtons() and the code cell.innerHTML += ... of course removes the handler. — AlexSm 18:29, 18 February 2011 (UTC)

Is there any way to fix this problem? Lonelydarksky (暗無天日) _{contact me (聯絡)} 09:32, 19 February 2011 (UTC)

Sure, just ask any sysop to revert that particular change: addOnloadHook() is going to stay with us for a while. Another option is to switch collapsible code back to href=javascript just like in other type of collapsible (NavigationBar). P.S. Looks like the sortable innerHTML issue was fixed in wikibits.js but did not make it to 1.17. — AlexSm 19:27, 19 February 2011 (UTC)

What is sysop? Probably theDJ, Kaldari, Krinkle, maybe even Edokter -- all present in this thread, should have reverted at first notice, instead of deflecting. But hey, they seem to have toes. -DePiep (talk) 20:28, 19 February 2011 (UTC)

In order to keep things related to this central, I will respond to this message over here. I apologize if I broke anything during my "migration"-edit. My intention was and still is to prepare the wikis for the upcoming change. Some may think that moving away from deprecated functions now is too soon, but I don't think so. Right now we can move away from them and move back and forth whenever we want, because both old and new are available now. Therefore this is, in my opinion, the perfect time to atleast attempt to switch, and test to see if everything still works like it should. Anything that broke ? Revert me, please do so, and then let me know what exactly broke with 1.17 and/or my edits. I love bug reports (that is, if something brakes, I rather hear about it so that it can be prevented in the future then it be silently fixed).
AlexSm is right in that the replacing of HTML is cause (atleast one of the causes) of any handlers being removed (such as collapsing and/or sortable clickable images and texts). I noticed during the development of another plugin in MediaWiki that it was being canceled somehow in table cells. It was caused by innerHTML and was fixed in trunk (rev:78893) which I've tagged to be merged to the live site, this will hopefully fix this!

I didn't mean to sound uncaring about this problem, but I can't fix everything everywhere and this particular script issue does not seem to be caused by something I did. I'm happy to check it out and perhaps be able to fix it, however from what I can see this issue may not have been noticed before but is not new and doesn't occur in most cases. Since a jQuery plugin has added to the repository (jquery.makeCollapsible) which does not seem to have any of the bugs, it would make sense to migrate to that instead of fixing or rewriting the current script. If you like I could install jquery.makeCollapsible locally on en.wikipedia (as it was not deployed) so you can check it out and start using it. That way, when it is deployed for real, it can simply be removed and everything will still work great. Let me know what you think, thanks, Krinkle (talk) 22:23, 19 February 2011 (UTC)

RSS feeds?

Why have RSS feeds stopped working? Specifically the one for new pages. — [[::User:RHaworth|RHaworth]] (talk · contribs) 22:06, 16 February 2011 (UTC)

Another unrelated regression. When I am doing speedy deletions, I used to get the reason supplied automatically for me from th speedy tag. This has stopped. Why? (I believe it was a bit of javascript.) — [[::User:RHaworth|RHaworth]] (talk · contribs) 22:11, 16 February 2011 (UTC)

I don't know but it's working for me. —Soap— 22:34, 16 February 2011 (UTC)

Worksforme. Happy‑melon 22:49, 16 February 2011 (UTC)

Which is working for you? Deletion reasons or RSS feeds? Atom feeds also seem to be broken. — [[::User:RHaworth|RHaworth]] (talk · contribs) 01:21, 17 February 2011 (UTC)

See Wikipedia:Village_pump_(technical)#Speedy-deleting_oddity for speedy deleting issue. Atom feeds seem to work for me, in Chrome 9. Gary King (talk · scripts) 01:31, 17 February 2011 (UTC)

This is crazy! I have tried with Chrome and all I get is about a dozen links to http://en.wikipedia.org/wiki/ . Same with rss. I have e-mailed you specimens. These were created with Lynx which, I think, can be trusted to give the raw feed as sent by Wikipedia. Nothing has changed my end - as far as I know. What is happening? — [[::User:RHaworth|RHaworth]] (talk · contribs) 14:52, 17 February 2011 (UTC)

Please compare and contrast:

• http://starwars.wikia.com/index.php?title=Special:NewPages&feed=rss - generated by MediaWiki 1.16.2
• http://en.wikipedia.org/w/index.php?title=Special:NewPages&feed=rss - generated by MediaWiki 1.17wmf1

But why is no-one else complaining - that is what puzzles me. — [[::User:RHaworth|RHaworth]] (talk · contribs) 15:38, 17 February 2011 (UTC)

I received your email. What you sent to me is what I see in my browser, which outputs nothing, so yes, that is definitely broken. What does work for me are feeds for page histories. Gary King (talk · scripts) 16:36, 17 February 2011 (UTC)

The new pages RSS feed is fixed now. --Catrope (talk) 23:18, 17 February 2011 (UTC)

Rollback quirk

Today's changes affected the rollback "button". In Firefox, I used to be able to <Ctrl><Click> on the rollback button to roll back vandalism from my Watchlist in a new tab. Today that no longer works. <Ctrl><Click> rolls back the vandalism in the current tab.

Not a big deal, but it was a convenience to preview the edit in Pop-Ups, roll it back in another tab, and continue down the Watchlist. — Malik Shabazz ^Talk/_Stalk 22:47, 16 February 2011 (UTC)

I don't have any issue doing this still. As far as I know ctrl+click is a browser thing. Killiondude (talk) 07:26, 17 February 2011 (UTC)

What browser are you using? I'm experiencing this problem on Firefox 3.6.13 and 4b11 on different machines, and it started yesterday. As far as I know, nothing changed in my browsers on Tuesday night. Thanks. — Malik Shabazz ^Talk/_Stalk 19:41, 17 February 2011 (UTC)

 Works for me in FF 3.6.6 (monobook). Try disabling all user .js and gadgets maybe, then re-enable one-by-one if the functionality comes back? –xeno^talk 19:46, 17 February 2011 (UTC)

Thank you for that suggestion. (I'm kicking myself for not thinking of it myself.) Unchecking the gadget "After rolling back an edit, automatically open the contributions of the user rolled back" solved the problem. Thanks again. — Malik Shabazz ^Talk/_Stalk 20:08, 17 February 2011 (UTC)

No problem =) –xeno^talk 20:09, 17 February 2011 (UTC)

Disambigs, main topics, and dablinks

Today, I had to go through and about 200 links of proper names to a table, knowing that on initial entry many of these links would be "wrong", pointing to the wrong topic or a disambig page. No problem, I thought, I'll just dablinks on the toolserver to resolve them. However, I realized that dablinks only checks if the link goes to a disamb page and that's it, and so only 11 of what I'd estimate are 50 problem links were caught.

I was wondering if dablinks can be modified with two features:

• First, taking the case where "Topic" and "Topic (disambiguation)" exist, Dablinks should recognize that the disamb page exist and highlight that area for the user, likely a different color, using the dab page to get that data. The user may have intended "Topic" in which case the user ignores the change, but if not this gives them the chance to change it.
• Second, in cases where "Topic" exists, there is no "Topic (disambiguation)" but one or more "Topic (other term)" exist, it would be helpful for dablink to at least notify the user that other pages like "Topic" exist; I wouldn't expect Dablinks to list out them all but at least notification would be helpful.

I would expect this could be easily done with dablink programming and the addition of a hidden template on the affected pages, but this can be done automagically through the {{otheruses}} family of templates. --MASEM (t) 22:58, 16 February 2011 (UTC)

(edit conflict)I don't get all of your question, but this might be relevant. {{dablinks}} is a part (only) of Hatnotes world. Another metatemplate used is {{rellink}}, btw. All in all there are ~100 hatnote templates, based on these two meta T's (mostly actually using one of these). The automated (dab)-check you are mentioning, is currently applied by using multiple intrinsic options per template (overloaded templates, software speaking). So the 100 different templates can produce 200+ different hatnotes. Before we would apply your proposal, I'd like to get how the current situation will be covered, and how non-dab links (such as {{main}}) can go along. Hatnotes are not just disambiguation, really. -DePiep (talk) 23:54, 16 February 2011 (UTC)

He's talking about the Dablinks tool. I had at least partial implementation of both method in Dab solver, but found they unsatisfactorily solved the problem. I since removed the kludge that was the code and an unfortunately busy reimplementing stuff that mw 1.17 broke :-(. — Dispenser 02:56, 18 February 2011 (UTC)

CSS for new edit toolbar

Where is the CSS for the new (ajax) edit toolbar located? I suspect it's not editable, but it does have an error that needs adressing. — Edokter (talk) — 23:46, 16 February 2011 (UTC)

Where in the toolbar and how is it wrong ? Then I an use webkit inspector to find which part loads it. —TheDJ (talk • contribs) 07:29, 17 February 2011 (UTC)

I also use the webkit inspector; it shows the URL for the edit page. Anyway, to see the problem (which I already fixed in common.css), click Help on the toolbar; the 'What you type' column suffers the same (now fixed) monospace fontsize bug. — Edokter (talk) — 12:23, 17 February 2011 (UTC)

The resourceloader inserts that into the head of the document when it is actually needed. It is in extension, WikiEditor/modules/jquery.wikiEditor.toolbar.css —TheDJ (talk • contribs) 18:04, 17 February 2011 (UTC)

Cheers for finding that. I've filed a bugreport. — Edokter (talk) — 18:48, 17 February 2011 (UTC)

Show commons categories on Wikipedia image page

When one clicks on a Commons image in Wikipedia, one gets a page of metadata along with a note that says "This is a file from the Wikimedia Commons. Information from its description page there is shown below." Most of the information in the Commons file is copied over, but the Commons categories are not and I often find I need to go to the Commons file to see those categories. It would save me a lot of time if the Common category links could be shown on the initial Wikipedia image page, perhaps in the same box as the "This is a file from the Wikimedia Commons..." note.--agr (talk) 00:26, 17 February 2011 (UTC)

Make a feature request in bugzilla: —TheDJ (talk • contribs) 07:28, 17 February 2011 (UTC)

Done. Bug 27501. --agr (talk) 18:19, 17 February 2011 (UTC)

Speedy-deleting oddity

(boldly moved from WP:AN, Magog the Ogre (talk) 00:56, 17 February 2011 (UTC))

I am an admin. Until recently, when I speedy-deleted a page, the start of the contents of the text box created by the speedy-delete tag, appeared on the deletion window as the reason for the deletion. That saved much time. But, after today's Wikipedia downtime, the reason for the delete always appears as "Other reason", and I must type a reason in. Anthony Appleyard (talk) 23:25, 16 February 2011 (UTC)

This seems to be an erratic problem, it works fine for me. What skin are you using? Have you tried purging your cache? Happy‑melon 23:28, 16 February 2011 (UTC)

This is happening for me as well. The original tagger's deletion criteria no longer appears when I hit the 'delete' tab from the article page. --Jezebel'sPonyo^{bons mots} 00:06, 17 February 2011 (UTC)

That's not been working for a while now but at least I can pick one of the reasons from the box rather than having to type it in. CambridgeBayWeather (talk) 00:43, 17 February 2011 (UTC)

I'm quite sure this is a bug related to the Mediawiki upgrade to 1.17, correct? Magog the Ogre (talk) 00:57, 17 February 2011 (UTC)

• Not a cache problem - I have tried three different browsers - all the same. One clue: in Firefox when I go into the delete screen, I get the message "Transferring data from meta.wikimedia.org" which does not go away. — [[::User:RHaworth|RHaworth]] (talk · contribs) 01:32, 17 February 2011 (UTC)

• Just a note, but clicking on the word "deletion" inside of the templates still auto-populates the deletion summary, with the added benefit of automatically including information in the template, such as the URL for a copyvio. Cheers, everyone. lifebaka++ 02:02, 17 February 2011 (UTC)

• I get the same "Transferring data from meta.wikimedia.org" message in my browser's status bar that doesn't go away even though the page is finished loading. But it happens on every page for me, not just the delete screen. I also can't get the revisionjumper gadget to work.. -- œ^™ 02:14, 17 February 2011 (UTC)

• The only thing coming from meta.wikimedia.org is JavaScript from Special:BannerController. It loads fine though, so I don't know what the browser is talking about... Reach Out to the Truth 02:38, 17 February 2011 (UTC)

• I just tried to do a speedy delete, and I clicked various occurrences of the word "deletion" on the page to be deleted and in the deletion window, and the reason for deletion stayed as "Other reason". I use Firefox. Anthony Appleyard (talk) 06:38, 17 February 2011 (UTC)

Broken MediaWiki:Sysop.js loading perhaps ? —TheDJ (talk • contribs) 07:27, 17 February 2011 (UTC)

• I have the same problem - as of this morning (UTC), the deletion reason has to be selected manually. Windows 7/Firefox, but also Chrome - not a browser issue. This is a pain, I hope it can be fixed soon. One oddity - which may help diagnose it - after deleting a page, when you click to delete the talk page, "G8: Talk page of a deleted page" does get automatically filled in. JohnCD (talk) 12:28, 17 February 2011 (UTC)
  • Should be fixed now. —TheDJ (talk • contribs) 17:55, 17 February 2011 (UTC)
    • It is! Thank you. JohnCD (talk) 18:42, 17 February 2011 (UTC)
      • What does the "transferring data" browser status mean anyway? I'm not an admin and have seen this permanently since the update. Jared Preston (talk) 22:07, 17 February 2011 (UTC)

Interface issues

The recent MediaWiki 1.17 release caused a number of problems on my editing interface. By the way, I'm using monobook. First, vertical strip along the left side of the page is unusually shifted down (see screenshot). Can anything in my monobook.js (possibly the script labeled "Personal toolbox - from http://en.wikipedia.org/wiki/User:Brian0918/monobook.js", which appears below the standard links on the left hand side) be modified to fix this? Also, I got the old toolbar (for monobook) back by unclicking the options under "editing" in preferences, but the Wikipedia:RefToolbar 1.0 button shows up on the far left instead of the right. Any code to fix this? Thanks in advance, Goodvac (talk) 04:24, 17 February 2011 (UTC)

Right, I'm using MonoBook too, and the logo on the top left starts off a bit left and then moves right every time I open a new page, which slows down the opening. All Hallow's Wraith (talk) 06:14, 17 February 2011 (UTC)

Just try removing components that you think are problematic. That or using a JS console/debugger is likely the only thing you can do about it. The more work you do to prepare and pinpoint the problem, the less time other admins or myself have to invest to help you. —TheDJ (talk • contribs) 07:25, 17 February 2011 (UTC)

How do I remove compnents I think are problematic? The logo? I can remove that? All Hallow's Wraith (talk) 08:40, 17 February 2011 (UTC)

You edit your skin script page, and remove everything. No more userscripts, means no more user scripts messing things up. Then you just copy and past and test till you find what script specifically in our skin script page was causing the problem. —TheDJ (talk • contribs) 17:38, 17 February 2011 (UTC)

I've never touched my skin script page before. What is the code that would make the logo stop moving (or rather show up correctly the first time), and the code that would remove this newfangled grey bar? All Hallow's Wraith (talk) 21:41, 17 February 2011 (UTC)

I found what was causing the problem: User:Omegatron/monobook.js/floatingSidebar.js. Now is there a way to modify that to be compatible with the recent update? Goodvac (talk) 09:34, 19 February 2011 (UTC)

SVG not rendering

no longer displays for me on any of the (many) pages that use it. I'm running firefox (3.6.13). Any ideas what's happening? U+003F^? 10:42, 17 February 2011 (UTC)

I think I've seen it mentioned somewhere that Mediawiki 1.17 is more picky about SVG namespace declarations than 1.16. So maybe that's the problem? --Morn (talk) 11:52, 17 February 2011 (UTC)

I've fixed it. The issue was that the SVG tags used <svg:something> instead of just <something>. --Morn (talk) 12:59, 17 February 2011 (UTC)

Could you fix Commons:File:Current event template.svg as well? — Edokter (talk) — 13:22, 17 February 2011 (UTC)

Remark: what a shame that mediawiki decided to discard all the changes prior to yours today, Morn. Check it out: commons:File:Soccerball current event.svg#filehistory Magog the Ogre (talk) 13:53, 17 February 2011 (UTC)

All old versions are still there; MediaWiki just refuses to render them. — Edokter (talk) — 13:42, 17 February 2011 (UTC)

Oh, right, invalid SVG. Duh. Magog the Ogre (talk) 13:53, 17 February 2011 (UTC)

Uh oh, quite a few other icons are broken too: http://commons.wikimedia.org/wiki/Time-related_icons#Sports Not good. This whole 1.17 upgrade is really an epic fail so far. --Morn (talk) 14:03, 17 February 2011 (UTC)

You don't have to fix the svg:svg case. That is actually a bug in the parser, that i have already fixed and that simply needs to be deployed yet. The cases of missing xmlns namespaces are a problem (these svgs will display an error in you open them in safari). Look in my Commons contribution history to see how to fix cases like that. A texteditor and some googling will do the trick. —TheDJ (talk • contribs) 14:50, 17 February 2011 (UTC)

Writing user scripts for ResourceLoader

Knowing that use of the new modular JavaScript libraries will become necessary in a future version of MediaWiki, I am attempting to update User:PleaseStand/highlight-comments.js to not use any deprecated functions. My new version is at User:PleaseStand/highlight-comments-dev.js, and I have decided to add a feature to highlight other user's comments, not just one's own. My work on implementing this feature raises a few questions. What will be our replacement for importScript? Why aren't mw.Map and mw.user.name() (as documented on the MediaWiki site) exposed to user scripts in the currently live version of MediaWiki? What should be the standard way to give custom settings to user scripts? PleaseStand ^(talk) 12:31, 17 February 2011 (UTC)

Roan and Trevor have told me that those are all features of Resource Loader 2.0 —TheDJ (talk • contribs) 14:13, 17 February 2011 (UTC)

Noticed any random script problems? wgVectorEnabledModules

I was having problems with some of my scripts not running... and from some of the posts above it seems that others in the last few days have as well. For me it was killing easyblock and some others, but I was able to track the JS error back to a protection script. It seems like wgVectorEnabledModules has either been deprecated or is not valid in all skins (and I'm using vector). I tried to put some error protection around it, but if anyone notices problems with my kludgy coding the feel free to revert back to this version of the protection script. If you are having other problems with your scrips you may want to look at whether it uses wgVectorEnabledModules.  7  13:21, 17 February 2011 (UTC)

wgVectorEnabledModules was removed; I guess that may not have been the best idea, because things were relying on it. However, there is now a generic interface for grabbing preferences (mw.user.options.get('preferenceName')) that you can probably use to do the same thing. I've filed a bug for reintroducing wgVectorEnabledModules and wgWikiEditorEnabledModules for back compat at Bugzilla. --Catrope (talk) 23:23, 17 February 2011 (UTC)

Thanks Catrope!  7  00:21, 18 February 2011 (UTC)

Problem with monobook

I see the ongoing hoopla over some changes that were made but can't see anything directly related to my problem. User:Brad101/monobook.css is supposed to set gray backgrounds but it's changed into this nauseating robin egg blue. Hope somebody can help me before my eyes start bleeding. Brad (talk) 14:24, 17 February 2011 (UTC)

Replace the second line with the following:

div#content { background: #CCCCCC; }

And you're done. Gary King (talk · scripts) 16:27, 17 February 2011 (UTC)

The specificity of the monobook script was raised, requiring this change. The monobook css is a bit 'safer' now, and harder to mess up. Before it was very easy to pick your own classnames that happened to match a monobook class and use it in the wiki code. Then you would get the monobook css and weird effects. This makes it harder to fall into that trap. —TheDJ (talk • contribs) 17:16, 17 February 2011 (UTC)

Ahhhhhhh it's gray again. Let us rejoice. Thanks! Brad (talk) 17:20, 17 February 2011 (UTC)

Reference not working

 Fixed

On Max Page (actor) reference #2 isn't displaying right.Vchimpanzee · talk · contributions · 14:44, 17 February 2011 (UTC)

|title= had a newline. PS— IMDB is not a reliable source. ---— Gadget850 (Ed) ^talk 14:49, 17 February 2011 (UTC)

I am aware of that, but until I can find something better it'll have to do wherever I need to use it. I'm not certain but I think this applies mainly to trivia and not to lists of shows' or movies' casts. Thanks.Vchimpanzee · talk · contributions · 14:51, 17 February 2011 (UTC)

FN SCAR infobox template

The infobox template in the article FN SCAR is broken. The template appears to be choking on the "variants" argument, but I'm not sure why, since it works fine on other articles that use the same infobox template. Anybody know what's wrong with this one? —Lowellian (reply) 15:08, 17 February 2011 (UTC)

I believe it's your bullet points: < li > Templates don't seem to like those. Brad (talk) 15:23, 17 February 2011 (UTC)

I tried removing those < li > elements (and BTW, they're not my bullet points; I didn't add them) from the "variants" argument even before I asked, and that doesn't fix it. Moreover, they do not appear to be the problem, as the template still breaks at the "variants" argument, rather than further down the template where the first < li > elements are used, assuming the ones in the "variants" argument are removed. —Lowellian (reply) 15:52, 17 February 2011 (UTC)

I just had a look myself, Template:Infobox weapon has recently been updated. The same issue is seen on all pages that use this template (eg AK-47, V-2, MIM-104 Patriot etc). Might be worth giving whoever edited it a heads-up. Nanonic (talk) 16:04, 17 February 2011 (UTC)

Ah, thanks. Someone reverted that change and the infobox looks good again. —Lowellian (reply) 20:26, 17 February 2011 (UTC)

NPP script broken

I do a lot of NPP (particularly in the lesser namespaces, where spam and defamatory content can hide for days if not weeks), and to make it easier I use a script that user:Mr.Z-man wrote for me.

However, it's stopped working -- now it tells me that there's been a "Session Failure: There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking."

I've left Mr.Z-man a message, but he's quite busy, so I'm wondering if anyone else might have an idea as to how to fix this. DS (talk) 15:10, 17 February 2011 (UTC)

I believe scripts always have to use patroltokens and the API now... Not 100% sure, but I read something like that in the IRC channel I think. —TheDJ (talk • contribs) 17:35, 17 February 2011 (UTC)

There are 2 scripts. The autopatrol script, which I migrated to jQuery and the API last month, and the links script, which just adds a "patrol" link to each entry on Special:Newpages to allow people to manually patrol. From a quick look, the manual patrol links now also require a token, so the script will need to be modified to get the tokens to put in the links, or just use JS and AJAX to patrol the page, the latter is probably better, but I won't have time to actually do it until Monday at the earliest. Mr.Z-man.sock (talk) 18:44, 17 February 2011 (UTC)

"widen searchbox"(gadget) is dead

How come? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 17:59, 17 February 2011 (UTC)

Fixed —TheDJ (talk • contribs) 18:09, 17 February 2011 (UTC)

ah, thx Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 18:10, 17 February 2011 (UTC)

Editing box distorted

The buttons above the editing box are distorted, much in the same way as New Features reformed this part of Wikipedia. Most of the buttons are gone, including bluelink, strikethrough, superscript. I have disabled New Features a long time ago. I can't find anything relevant in My Preferences to change it back. Help! Geschichte (talk) 18:57, 17 February 2011 (UTC)

Try Special:Preferences → Editing, "Enable enhanced editing toolbar" (uncheck). –xeno^talk 19:00, 17 February 2011 (UTC)

Sometimes see pages without any CSS for a split-second?

Sometimes, for some reason during when a page is loading, I'll see the page for a split-second without any CSS whatsoever. So, the background would be white, and the text would be pretty big and take up 100% of the width—similar to how the wiki would look to a mobile browser. This shouldn't be happening since CSS applies pretty quickly, especially since it should be cached by my browser. Is anyone else experiencing this? When a page loads for me, it now does so in three, recognizable steps: load the content; apply global/user CSS; apply user JS. I can see a page transform through each process. Gary King (talk · scripts) 19:16, 17 February 2011 (UTC)

Here's a screenshot to show what I'm seeing. I just so happen to hit the Stop button while the page was loading to catch this moment. Gary King (talk · scripts) 21:54, 17 February 2011 (UTC)

I'm getting the same thing. Overall the page loading seems a little slower, but maybe that's just do the jumping formatting.   Will Beback  talk  22:08, 17 February 2011 (UTC)

Page loading seems perhaps a tad faster for me, actually, which was the whole point of 1.17 so I guess they kind of succeeded. However, by far the biggest culprit for slow loading time is server-side rendering, which has always been the cause of the slowness. I assume that things are already cached as much as possible but really, about 80% of loading time is still spent on the server-side. Gary King (talk · scripts) 00:15, 18 February 2011 (UTC)

There's no "sometimes" about it for me: there's always a one-to-two-second delay from when the page text shows up to when the formatting shows up, with the side effect that section links are only approximations. --Carnildo (talk) 00:16, 18 February 2011 (UTC)

Links not being underlined any more?

I'm still using the classic look, rather than the new one which didn't grab me.

As of today links in articles are no longer being underlined (until you move the mouse onto them).

Sometimes in past years this has happened before for an hour or two, until (presumably) somebody has restored the code to what it was without the bug. This time it seems to be taking longer?

Does anyone know whether this time the change was intentional? (ie is this a bug, or a misconceived unwanted new feature?) And if it is here to stay, how do I get my underlined links back?

Thanks, Jheald (talk) 19:35, 17 February 2011 (UTC)

See here. Gary King (talk · scripts) 19:38, 17 February 2011 (UTC)

Edit toolbar (once fixed) is now broken again

Yesterday I was able to restore my edit toolbar by running through they typical steps: My preferences → Editing → Beta features → unclick "Enable enhanced editing toolbar". Everything was working fine until now, when all of a sudden the "cite" button on the toolbar disappeared. It was working fine and then *poof*. I'm using Monobook/Firefox. Jezebel'sPonyo^{bons mots} 20:26, 17 February 2011 (UTC)

Sigh...you're correct. It was working fine this morning. Now the Cite button is gone again. I'm also Monobook/Firefox. Maile66 (talk) 20:33, 17 February 2011 (UTC)

Ditto for me, I'm using the same as Ponyo, unclicked "Enable enhanced editing toolbar" to get the cite button back yesterday, but it just disappeared again. Davewild (talk) 20:36, 17 February 2011 (UTC)

It is also gone for me. I am on Firefox 3.6.13 with the vector skin, and the old toolbar (both beta features checkbox are cleared, the refTools gadget box is checked. -- Whpq (talk) 20:50, 17 February 2011 (UTC)

It seems to be fine again. At least for the last 10 minutes. But ever since the update, it does take an awfully long time to load above the edit field. Jared Preston (talk) 21:12, 17 February 2011 (UTC)

Yes it's back again now for me. Davewild (talk) 21:38, 17 February 2011 (UTC)

There is still some problem here. The cite button appears to have moved from the right hand end of the bar to the left end of the bar away from the <ref></ref> button. Much easier with the two buttons together. Keith D (talk) 21:52, 17 February 2011 (UTC)

Gadgets stopped working

Pop-ups, clock/purge, blackscreen have stopped working. Were working earlier today. Monobook, Chrome, WinXP. DuncanHill (talk) 21:08, 17 February 2011 (UTC)

Hmm, and now they are back but not when in the edit screen. Predictive search also not working. DuncanHill (talk) 21:28, 17 February 2011 (UTC)

Gadgets and predictive search are working for me in Monobook, even in the edit screen. Gary King (talk · scripts) 21:56, 17 February 2011 (UTC)

Related to my note above? See here - do you use any scripts that use wgVectorEnabledModules? Run the page in firefox and bring up a Java console window and you should be able to find the error.  7  22:42, 17 February 2011 (UTC)

I have no idea if I run anything that uses wgVectorEnabledModules, whatever they are. How would I know if I did. I really don't want to have to download and install yet another browser - . Anyway, gadgets are now coming and going randomly. Added to the much slower page-loading since the upgrade, I think I might as well call it a day. DuncanHill (talk) 16:28, 18 February 2011 (UTC)

• Well, they were working again earlier today, now they've stopped again (except in the edit-screen). DuncanHill (talk) 17:44, 19 February 2011 (UTC)

Weird grey bar

I suddenly seem to have this weird grey bar appearing at the top of every page. It's pretty annoying. Just wondering if it's related to anything that's been changed recently? Or perhaps caused by a moment of dumb on my end? --Dorsal Axe 21:13, 17 February 2011 (UTC)

Could that be another Monobook problem? I use Vector and can't see what you mean. Jared Preston (talk) 21:18, 17 February 2011 (UTC)

• See Wikipedia:Village pump (technical)/Archive 84#Grey stripe at top of pages (part two) for some information. –xeno^talk 21:23, 17 February 2011 (UTC)

Well that's the one. Can't seem to get rid of it though. Appears in both Monobook and Vector too.--Dorsal Axe 21:33, 17 February 2011 (UTC)

But the solution there is to use some JS code. Since JS code is now at the bottom of the pages (whatever that means, I'm not tech-savvy enough to comprehend), then that grey bar will always load before vanishing again – like the watchlist banners. I'm not sitting in the same boat as Dorsal Axe, but can imagine that must be quite annoying and at the very least a major distraction. What is causing the grey bar exactly? Jared Preston (talk) 21:38, 17 February 2011 (UTC)

Right, both this and the amazing swerving logo have shown up on my Monobook in the last two days. Presumably the same is true for everyone who uses Monobook? Shouldn't this be fixed by whoever made the changes to the code in the last two days? All Hallow's Wraith (talk) 21:40, 17 February 2011 (UTC)

I've never seen that grey bar and I've been using Monobook for years now. Gary King (talk · scripts) 21:55, 17 February 2011 (UTC)

Allright, the grey bar has vanished, at least on my monobook. The swerving logo is still here, though. Any chance it'll disappear too? All Hallow's Wraith (talk) 22:27, 17 February 2011 (UTC)

The grey bar has also vanished for me too now. Very strange.--Dorsal Axe 22:37, 17 February 2011 (UTC)

Dorsal, are you having problems with your logo? Is it starting out a bit to the left and then moving to the right a few seconds later? (the Wikipedia logo) All Hallow's Wraith (talk) 22:44, 17 February 2011 (UTC)

So, that's it, is it - the logo thing is permanent? Or what? Who is it that keeps making these brilliant changes that make everything slower and then doesn't stick around to explain them? All Hallow's Wraith (talk) 07:49, 18 February 2011 (UTC)

Question marks appended to redlinks?

It seems that redlinks now have a question mark appended to the end of them by default. Why was this done? Adding punctuation to a link creates confusion and ambiguity in articles. For instance, consider how silly these sentences with redlinks look:

• In 1960, the internet was invented by Al Gorbechev. He asked, "What is the purpose of all these redlinks?"

Did someone decide that coloring the links bright red wasn't sufficient to identify a link with no destination? Again, these types of changes should be opt-in, not opt-out, although I don't even see an option to opt-out of it. I'm sure there is probably some custom CSS that you could append to your monobook.css, but that's not the point. The average casual reader here will almost certainly be confused by these question marks, and they will certainly not be interested in looking at css code. Was this change discussed somewhere? SnottyWong ^confer 22:11, 17 February 2011 (UTC)

Perhaps it's a bug from the upgrade and you need to clear your cache? I see no question marks after redlinks, and I checked both logged in (using my custom CSS and Monobook skin) and logged out (Using "normal reader" CSS and Vector skin.) ^Avic_ennasis @ 22:40, 13 Adar I 5771 / 17 February 2011 (UTC)

Ditto, I'm not seeing that, either. There's a user preference that makes redlinks appear as plain text with a question mark (found on the "Appearance" pane under "Advanced options"), but I don't think I've ever see what you're describing.--Fyre2387 ^{(talk • contribs)} 22:49, 17 February 2011 (UTC)

Hmm. Well, if I use Firefox the question marks go away. But I can't get them to go away in Chrome, even after clearing the cache and following all instructions at WP:BYPASS. Using Chrome 9.0.597.98. What I see is the entire word is red, and there is a red question mark appended to the end of the word. The whole thing (word + question mark) is the hyperlink. SnottyWong ^comment 23:06, 17 February 2011 (UTC)

I would try opening an incognito window and look at a page with redlinks. You'll be logged out in that window, and there will be no cache or anything else to interfere, due to how incognito works. If you don't see question marks in that window, stay on the page and log in, and see if they come back. ^Avic_ennasis @ 23:10, 13 Adar I 5771 / 17 February 2011 (UTC)

Opened incognito window, question marks were gone. Logged in while still incognito, question marks came back. In my prefs, I'm using monobook and I have the "Format links to non-existent pages like this (alternative: like this?)" option un-checked. Any ideas? SnottyWong ^squeal 00:44, 18 February 2011 (UTC)

I checked in my prefs (also monobook) and I had that box checked. When I un-checked it, I saw the question mark after the redlink, as part of the link. Re-checking it returned them to normal (without the question mark.) So, I would actually put a check in that box, and see what they look like. (May have to bypass cache blah blah blah.) ^Avic_ennasis @ 00:50, 14 Adar I 5771 / 18 February 2011 (UTC)

Yep, the box has to be checked. Jared Preston (talk) 01:03, 18 February 2011 (UTC)

Ok, that seemed to work. That was weird. Before I checked the checkbox, it was reading: "Format links to non-existent pages like this? (alternative: like this?)", which is why I didn't check it originally. However, after checking the checkbox, now it reads correctly: ""Format links to non-existent pages like this (alternative: like this?)". Anyway, problem solved. Thanks for the help! SnottyWong ^spout 15:29, 18 February 2011 (UTC)

Confused

I heard We were rolling out Media Wiki software updates and today I see alot features that are popping up. Is there some place where I can read about all the new features in simple terms? I am not a programmer but would like to know what the average Wikipedia can now do now that we couldnt do before. The Resident Anthropologist (talk) 22:17, 17 February 2011 (UTC)

It was yesterday, I believe. Here's a list of what changed: [8]. It should be mostly accurate; I don't know if all the changes are live here. /ƒETCHCOMMS/ 23:24, 17 February 2011 (UTC)

The biggest change is probably the implementation of ResourceLoader, which is supposed to basically speed up the loading of CSS and JS files, essentially making pages load faster. So it's mostly advantageous for developers as they should be implementing it into their scripts. Gary King (talk · scripts) 00:13, 18 February 2011 (UTC)

WP:BRION</shameless self plug> Also check out the issue that comes out on Monday for coverage :) - Jarry1250 ^{[Who? Discuss.]} 17:30, 18 February 2011 (UTC)

ClueBot NG down?

It would seem ClueBot NG is down, no edits for the last two days. I would poke the maintainers but neither have edited in the last two weeks. Can anybody help? Rjwilmsi 22:20, 17 February 2011 (UTC)

WP:STiki is working if you change the queue from ClueBot NG to STiki Metadata to get recent changes. It uses the ClueBot NG queue by default, which will only show unreviewed edits from prior to CBNG going down. It's not fully automated, but much better than just going through the RCs. —UncleDouggie (talk) 01:20, 18 February 2011 (UTC)

I've sent User:Crispy1989 an email and left a message on his IRC channel. Nothing yet. —UncleDouggie (talk) 03:38, 18 February 2011 (UTC)

CBNG is down due to a server problem that seems unrelated to the MediaWiki upgrade. —UncleDouggie (talk) 04:08, 18 February 2011 (UTC)

It's now running! —UncleDouggie (talk) 05:49, 18 February 2011 (UTC)

Finding permanent url

I don't know if this is the right place to inquire about this issue. If not, then please refer me to the relevant page. Here is the problem I am faced with. I wanted to add a reference to the Farouk Sultan article. More specifically, I wanted to provide a link to his CV page located in the official website of the Supreme Constitutional Court of Egypt. The problem is that the page is written in Javascript, and opens only in Internet Explorer (not Firefox). The specific url of the page is not displayed in the address box. I would like to know how to find the specific permanent url of the CV page so as to be able to link back to it in the aforementioned Wikipedia article.

• Here is the main page with a list of all the members of the court: http://www.sccourt.gov.eg/CourtMembers/CurrentCourt.asp
• Farouk Sultan's photograph is the first one displayed on the page (see enlarged version). When I click on the Arabic-language name below his photograph, his Arabic-language CV page opens. However, instead of getting a normal url starting with http, this is what I get:
  javascript:memberCv(95,'%D8%A7%D9%84%D8%AA%D8%B4%D9%83%D9%8A%D9%84_%D8%A7%D9%84%D8%AD%D8%A7%D9%84%D9%89_%D9%84%D9%84%D9%85%D8%AD%D9%83%D9%85%D8%A9');
• My question is: how can I manage to find the permanent url linking to the CV page?

I'm not sure if I have made myself fully understood. If things are not clear, then please tell me so I can rephrase myself. Regards. --BomBom (talk) 00:52, 18 February 2011 (UTC)

Yeah, I hate websites that use that kind of design.

Looking at various CVs, it looks like they use a single URL -- http://www.sccourt.gov.eg/CourtMembers/memberCv.asp -- to display each member's CV. I looked at the Javascript code for the main page, and saw that the main page has a memberCv function that sends a POST request to the CV page with a couple of parameters, one of which is named MemberId, to tell it which CV to display; since it's a POST request, there's no URL querystring shown in the address bar on the CV page. The Javascript code you posted for the link calls the memberCv function with the MemberId set to 95 and the other parameter set to some Arabic text.

The good news is that, according to my testing, the CV page can be accessed with a GET request (which enables a querystring), so I constructed a URL with the querystring (including a MemberId -- the other parameter, which was the same for all the members, appears to be unnecessary) manually added. Here you go: http://www.sccourt.gov.eg/CourtMembers/memberCv.asp?MemberId=95

Lucky Wizard (talk) 02:41, 18 February 2011 (UTC)

Well, I think "Wizard" is the right word rather than "Lucky". If I had spent my whole life studying the problem I would never have come up with that! Thincat (talk) 18:26, 18 February 2011 (UTC)

I agree with Thincat. I would have never been able to find the URL all by myself. Thanks a lot, Lucky Wizard! --BomBom (talk) 13:08, 19 February 2011 (UTC)

Unblockself permission

Who can assign or remove the "unblockself" permission that's mentioned in the new release notes? When I look at another admin's user rights management page, I don't see such a permission either in the list of rights that I can change or in the list of rights that I can't change. Nyttend (talk) 01:46, 18 February 2011 (UTC)

All admins already have it. It's in Special:ListGroupRights as part of the admin package. The only way to remove it is to modify the server configuration. T. Canens (talk) 01:58, 18 February 2011 (UTC)

You don't assign individual permissions, you assign groups that contain those rights. Special:ListGroupRights lists each group and the rights those groups have. Reach Out to the Truth 05:02, 18 February 2011 (UTC)

watchlist not loading in Ta.Wiki

We are facing a strange problem in Tamil wikipedia. The watchlist is loading as a blank page since yesterday (feb 17). The page loads first, but when it tries get data from toolserver.org ("transferring data from toolserver.org"), it goes blank. If i hit the stop button in the broswer before the query to toolserver.org initiates (say while "bits.wikimedia.org" is being contacted) the page is fine. From my very limited technical knowledge, i am guessing something is broken in toolserver and the query on watchlist page load, to it is not returning pages/data.

Can anyone help throw some light on this?--Sodabottle (talk) 04:36, 18 February 2011 (UTC)

document.write is used in ta:MediaWiki:Common.js at line 785, conditional on the page being the watchlist. See Wikipedia:Village pump (technical)/Archive 85#Cannot view m:Talk:Spam blacklist: empty page for discussion of a similar problem; the fix applied there should be able to be easily adapted to your situation. Anomie⚔ 04:59, 18 February 2011 (UTC)

Thanks a ton Anomie :-). I have fixed the issue now--Sodabottle (talk) 05:47, 18 February 2011 (UTC)

Gallery not centered anymore

Hello. Does anyone have some information about <gallery> since the Feb.17th update ? It is now aligned on the left and one has to add <center> everywhere, or is it temporary ? Thanks, Jack ma (talk) 06:56, 18 February 2011 (UTC)

• 
  Sunflower
• 
  La Joconde
• 
  A hamster

I'm quite sure that gallery has always been left aligned. Perhaps you are confusing with one of the many gallery templates ? Someone correct me if I'm wrong. —TheDJ (talk • contribs) 08:47, 18 February 2011 (UTC)

It is implemented as a list instead of a table, which I’m pretty sure is new. More strangely it forces a white background to stretch all the way across the screen. Could someone kindly get rid of that? See screen-shot. Thanks. ―cobaltcigs 17:38, 18 February 2011 (UTC)

That is new indeed, but the alignment has not changed, which is what the question was about. I think the white background was already made transparent in trunk. commit "Took out fix for bug #27458 (“<gallery> has a white background now”) since bug conflicts with a fix for bug #26470". Ok, that even has me confused. Will look further into it tomorrow. —TheDJ (talk • contribs) 01:23, 19 February 2011 (UTC)

For the moment, could we address this locally by using ul.gallery { background-color:transparent; }? In any case making the gallery float in the center (without clumsily centering everything inside it) would require setting an arbitrary width other than the new default of 100% (which is different from the old default of 4× the cell width). ―cobaltcigs 04:05, 19 February 2011 (UTC)

Gallery formatting not working either

As well as no longer being centered when using the <center> tag, which used to center the gallery in the available space (for instance, between the left margin and an infobox's left edge), gallery images are no longer being formatted by widths="XXpx" and heights="XXpx". This is under both FireFox and IE, with both monobook and vector skins. Beyond My Ken (talk) 21:06, 19 February 2011 (UTC)

After a little more investgation, it seems to be the "perrow" variable which is messing with the centering, and only in spaces constricted by infoboxes. Here's a sample gallery in which the image sizes have been overrridden by "widths" and "heights", but no "perrow". It centers properly the the space between the left margin and the infobox:

35 East Wacker
Former names	Pure Oil Building North American Life Building Jewelers Building
General information
Location	35 E. Wacker Drive Chicago, Illinois
Height
Roof	159.41 m (523.0 ft)
Technical details
Floor count	40
Design and construction
Architect(s)	Joachim G. Giaver Frederick P. Dinkelberg

• 
  Sunflower
• 
  La Joconde
• 
  A hamster
• 
  test
• 
  test
• 
  test

Here's the same gallery, with the "perrow" set to 3. It no longer centers in the space:

• 
  Sunflower
• 
  La Joconde
• 
  A hamster
• 
  test
• 
  test
• 
  test

Both galleries center properly when there's no infobox:

• 
  Sunflower
• 
  La Joconde
• 
  A hamster
• 
  test
• 
  test
• 
  test

• 
  Sunflower
• 
  La Joconde
• 
  A hamster
• 
  test
• 
  test
• 
  test

I hope this helps to locate the problem. Beyond My Ken (talk) 21:34, 19 February 2011 (UTC)

Things fall apart, the <center> cannot hold. It does not noticeably center the gallery as a whole because the gallery now has 100% width unless otherwise specified. This is clearly evidenced by the long white banner seen above and in bugzilla:27458. Whilst deprecated the <center> element does center the individual cells within this horizontal space, with the caveat that a trailing partial row will be centered differently. It also centers the text in the image thumbnails, which is surely undesirable. To center a gallery as if it were a table I suppose you’d need to constrain the width to roughly 162px times the desired number of photos per row.

Choosing what how many cells per row would be appropriate requires guessing screen-size and is therefore a fool’s game. I’m pretty sure the entire point of abandoning tables/cells is to make the thumbnails wrap along to subsequent rows much like plain text (within whatever horizontal space is available rather than forming a strict grid based on a poor estimate). Thus I advise against using the above code and defeating that purpose. ―cobaltcigs 21:32, 19 February 2011 (UTC)

Since we posted at virtually the same time, could you re-jigger your explanation with reference to the samples I gave above? Beyond My Ken (talk) 21:38, 19 February 2011 (UTC)

Hmm, upon further observation I see the max-width property is exactly how the perrow pseudo-attribute is implemented. Get the firebug extension and you’ll see what I mean [9]. The other thing I noticed is that using perrow causes a noticeable over-estimation of the required width (for the specified number of cells at the specified size). Normally one would be able to fine-tune this, except that existing CSS properties are discarded completely, see:

Using: <gallery perrow="4" style="max-width:648px; margin:auto; background:green; border:1px solid orange; text-decoration:blink; font-size:200%;"> 

• 
  Sunflower
• 
  Sunflower
• 
  Sunflower
• 
  Sunflower
• 
  Sunflower
• 
  Sunflower

The resulting style attribute is malformed, too wide, and missing the desired properties:

<ul class="gallery" style="max-width: 680px;_width: 680px;">

Is there a bugzilla ticket for this? ―cobaltcigs 22:01, 19 February 2011 (UTC)

MediaWiki software and scripts

I have recently been experiencing problems when running scripts since about Thursday 17 February. Note that I have had similar problems before, but they went away. Recently, the problems resurfaced.

I run a number of regex-based scripts (which can be seen among the stuff at my user page). I made some changes to one of them yesterday, after which I can no longer access any of the sidebar script buttons. I reverted back to an earlier version that I know worked yesterday, but still no joy. The earlier problem was due to a fatal error in the script – another editor who uses my scripts (including the one changed) noticed the script became inaccessible, and informed me. After I had fixed the bug, it resumed working for him; my cupboard remains bare. :-( My friend uses FF on Mac; I have had no success when running FF, Chrome or Safari on Windows. I then tried removing the script from my vector.js, expecting most of the scripts to be restored, but still no.

I suspect the problems may be caused by the MW software, with which I have noticed recent instabilities, which included (amongst other problems) pages 'disappearing' from browser history when surfing WP – I go forwards several pages, but some of the intermediate pages in history are not accessible when I navigate back using the back-arrow; also some pages load without the skin. Does anyone have any similar experiences with scripts recently? --Ohconfucius ^¡digame! 08:36, 18 February 2011 (UTC)

E-Mail User Links not Working

When I click to email someone via Popups, I get the message: "You have not specified a target page or user on which to perform this function." When I go to the Special page, I get: "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." Both times, it gives me a link to the Main Page to click. Is this related to the 1.17 update? - Neutralhomer • Talk • 09:00, 18 February 2011 (UTC)

bugzilla:27526. I can fix it for popups, but this is just a bug in the new software and really should be fixed there. —TheDJ (talk • contribs) 09:34, 18 February 2011 (UTC)

I have never been good at filing BugZilla reports. If you can fix it, please feel free. I have also posted this at the Popups page. - Neutralhomer • Talk • 09:54, 18 February 2011 (UTC)

• Popups are not working for me at all. Glad not to be the only one... --Ohconfucius ^¡digame! 10:04, 18 February 2011 (UTC)

Fixed in r82392, but it may be some time (hopefully only a couple of weeks) until that's deployed to the WMF cluster. Happy‑melon 11:30, 18 February 2011 (UTC)

Editing page visuals

I'm not sure this has been discussed before on this page. I use Firefox. Both phenomenons are cleared temporarily (and only temporarily) by selecting "Preview". Never had this problem until the recent changes. These two things have been happening for a day or two:

• When editing, sometimes, too frequently now, when I place the mouse cursor somewhere on the page, the blinking cursor disappears, leaving me to wonder if it's where I want to be on the page. I figure out where I am by hitting the Spacebar and watching the text move. This phenomenon clears up if I do a "Preview".
• The Insert Link option works fine, but goes a little whacked after one or two uses. I can insert link #1, perhaps even #2 and #3. But at some point when I select the link button, the popup is so large it engulfs my page to the point I can't move it from side to side to see what I'm bringing up. This never happens on the first "link" of the edit, or the first "link" after a "Preview". Clicking on "Preview" clears the oddity, but only until I want to insert more than one or two links.

Maile66 (talk) 12:54, 18 February 2011 (UTC)

I find the editing page has been jerky & jumpy since yesterday. When one adds or deletes words while editing or posting (even in edit summaries), the thing jumps at the touch of any keys. GoodDay (talk) 14:04, 18 February 2011 (UTC)

Oh, yeah...and the jumping. I thought it was just me. Thanks for mentioning that.Maile66 (talk) 14:13, 18 February 2011 (UTC)

I'm experiencing the same issue ("jerky & jumpy") with Internet Explorer. -- Black Falcon ^(talk) 20:29, 18 February 2011 (UTC)

We're also getting reports of that at the Vietnamese Wikipedia. – Minh Nguyễn (talk, contribs) 19:42, 19 February 2011 (UTC)

$(document).ready not working in edit mode

I have this script and tested with alert, which is not firing in edit mode, this worked before 1.17version. Kindly help me to fix. -- Mahir78 (talk) 16:14, 18 February 2011 (UTC)

Still waiting for a help. -- Mahir78 (talk) 06:36, 19 February 2011 (UTC)

Does $(function () {alert("It works!";}); work? – Minh Nguyễn (talk, contribs) 19:44, 19 February 2011 (UTC)

Google Chrome

I don't see anything in the Pump search regarding this specific issue, so: Can someone comment on (or point me to) any known issues in editing with Google Chrome? Specifically, I am seeing the insertion of additional line breaks and, in a few case, extra indentions upon saving comments. I am kind of "forced" to use Chrome on one of my main access computers, so changing back to Mozilla (in which I had no problems) or something else is not really an option. David Able 18:36, 18 February 2011 (UTC)

Also have twinkle issues for me; will not open user talk pages after reverting edits. --Perseus8235 19:15, 18 February 2011 (UTC)

Did you get an error message of any kind? Did it say "We received no revision; something is wrong. Bailing out!" ? —Soap— 16:08, 19 February 2011 (UTC)

User Interface Gadgets-Display assessment

New quirk. More than an hour ago, maybe something happened in the system. I did a couple of edits that didn't show up on my Watch List, Contributions, or the actually edited pages for about half an hour. That particular thing cleared up. There have been no changes in my profile. During that same time, and since, if I change the page assessment on a Talk page, it will show on the Talk page fine. But on the main page assessment display at the top, it doesn't update. I changed the assessment on Homeboy Industries, and the display on the main page shows the old assessment. I have Firefox and Monobook. Maile66 (talk) 19:37, 18 February 2011 (UTC)

When the servers are very busy, at times it can happen that they serve you outdated content. (There are multiple servers handling the requests, and when they are really busy, they sometimes get out of sync with eachother.)—TheDJ (talk • contribs) 00:19, 19 February 2011 (UTC)

Jumping to the wrong section

I've had several incidents since the MediaWiki upgrade where clicking a section link from a different article or an edit summary takes me to the section immediately after what is in the link. When it happens, it will often keep happening on the same link several times and then it starts working once I have clicked any item in the TOC of the destination article. Once it starts working, I can't induce another failure even if I close the tab completely and reopen it. It just happened to me on Talk:Scientology#Call_Hubbard_a_.22Science_fiction_writer.22, which I clicked on from the edit summary by RUL3R in the page history. —UncleDouggie (talk) 20:48, 18 February 2011 (UTC)

So if I understand correctly, you clicked on that link and landed at "Image for Auditing subsection" ? Which browser are you using ? —TheDJ (talk • contribs) 00:02, 19 February 2011 (UTC)

Yes, that's right. I'm using FF 3.6.13. It's got to be something with the browser jumping to the section before all the scripts run at the end with ResourceLoader and that somehow repositions the cursor. Others have reported strange jumpy behavior. In this case, I didn't scroll the window at all, it just immediately went to the wrong section. It happened more than once and on the subsequent incidents I was very careful to not scroll. Unfortunately, it corrected itself before I could get into serious troubleshooting. —UncleDouggie (talk) 08:27, 19 February 2011 (UTC)

When completing the edit of this very section, I first see the properly formatted #MediaWiki software and scripts section and about 1 second later it jumps down to this section. That's probably due to the auto collapsing of the header FAQ. Perhaps I had something similar but it didn't reposition to the proper location for whatever reason. My browser is running a little slow at the moment because I probably have 40 tabs open, but it was never a problem before the MediaWiki upgrade. I guess it's time to save off all the stuff I have in progress and restart. —UncleDouggie (talk) 08:38, 19 February 2011 (UTC)

Ah right of course. It's a bit of a Firefox bug, but an annoying one for sure. Something we might be able to fix in the collapsing code though. (Remember that the collapsing code is an en.wp extension and not part of the MediaWiki software.) —TheDJ (talk • contribs) 09:13, 19 February 2011 (UTC)

I am experiencing the same issue on this pump since the 1.17 upgrade. Svick (talk) 21:10, 19 February 2011 (UTC)

Atom feeds no longer work to track contributions for a certain user or IP

I'm sorry if this issue has been already reported or if this isn't the right place to announce it, but I've just found out that, as I state in title, Atom feeds for any contribution page are empty, no matter how many editions the user (or IP) has done.

Thank you. --Canyq (talk) 21:51, 18 February 2011 (UTC)

You are right. Thanks for reporting it. Filed as issue bugzilla:27339. —TheDJ (talk • contribs) 23:59, 18 February 2011 (UTC)

Excellent! Thank you very much.--Canyq (talk) 00:11, 19 February 2011 (UTC)

Old Username stticking around in watchlist

My watchlist currently shows User:Bot337 as the last person to edit WT:CHUU. They've gone through a rename however, and are now just User:336, although my watchlist still shows their old username. This is on the latest Firefox 4 beta. I don't think this is a cache error, I've cleared my cache and it still does it. I probably should have taken this to bugzilla, but I thought I'd get input from the pump first. demize (t · c) 01:57, 19 February 2011 (UTC)

The rename appears to be very recent. Sometimes, they take a while for everything to be updated. /ƒETCHCOMMS/ 04:24, 19 February 2011 (UTC)

Search box not clearing prompt text

If I click in the search box before the page finishes completely loading, the string "Search" goes black and becomes part of my query instead of vanishing as it should. This is clearly due to resource loader not loading the script that clears the box until the end of the page. It's very annoying because I frequently open a new tab with just my user page to give me a new search box when I need to bring up something in addition to whatever I have open. I recommend that we delete the "Search" prompt from the box on initial load. Once the java script is loaded, it can then fill in the prompt text because it will be in control to also remove it should the user click on the box. I'm running FF 3.6.13 and this never happened prior to MediaWiki 1.17. —UncleDouggie (talk) 04:56, 19 February 2011 (UTC)

Issues with "Search" becoming real text were reported on bugzilla at least 4 times (including my own report), see bugzilla:25683. Meanwhile, the following code in your vector.js will allow you to open search results in a new tab by pressing Shift-Enter (or Shift-Click on dropdown suggestion):

$j(function(){
 $j('#searchform').bind('keyup keydown mousedown', function (e){ 
   $j(this).attr('target', e.shiftKey?'_blank':'')
 })
})

— AlexSm 05:23, 19 February 2011 (UTC)

Wow, more magic Javascript to go horribly wrong during the next MediaWiki "upgrade". :-) Thanks! —UncleDouggie (talk) 08:47, 19 February 2011 (UTC)

Featured article tools not appearing at FAC nominations

For some reason, the toolbox and article links template are no longer appearing at FAC noms: compare Wikipedia:Featured article candidates/Irresistible (Jessica Simpson song)/archive1 to Wikipedia:Featured article candidates/Me and Juliet/archive1. I suspect it has something to do with the code at Wikipedia:Featured article preload. Can somebody take a look? Dabomb87 (talk) 17:07, 19 February 2011 (UTC)

The problem is with the new version of MediaWiki, the sixth entry under "Bug fixes in 1.17" is "Preload parser now parses <noinclude>, <includeonly> and redirects.". Before 1.17, a preload would not parse these tags, so they would just appear with their content fully intact. Unfortunately the featured article preload had relied on this "bug"/"feature" to allow the transclusion of the tags themselves, most importantly the <noinclude> tag, which previously allowed the toolbox to be loaded surrounded by noincludes, so it would appear on the review page but not on the main candidates page. I'm looking into a solution. Intelligentsium 18:07, 19 February 2011 (UTC)

I've come up with something that, while not pretty and indeed rather barbaric, should work. You can check my work at [10]. Intelligentsium 18:29, 19 February 2011 (UTC)

The rather less horrible <noin<noinclude/>clude> also works. This change actually allows the preload to be made less hackish, not more, as you can eliminate the use of {{void}} for the reverse process (genuinely wanting something to be shown only on the page itself, and not included when it's used as a preload). Happy‑melon 19:11, 19 February 2011 (UTC)

How are code updates scheduled?

This MediaWiki code patch applies HREFLANG to links to other-language Wikipedias. How can I tell when,or whether, it will be applied here? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:41, 19 February 2011 (UTC)

It's live right now in the 1.17wmf1 branch, which all Wikimedia projects are currently running. Reach Out to the Truth 20:53, 19 February 2011 (UTC)

How come I don't find the string "hreflang" anywhere in the source of pages with such links, then? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:21, 19 February 2011 (UTC)

DEFAULTSORT sort keys and talk pages

The {{DEFAULTSORT:}} magic word sets a WP:SORTKEY. This affects only the category sorting for the page upon which it is placed, and not that of the associated talk page (see, for example, the cats of Charles Burrell & Sons, where the page is sorted under B, and of Talk:Charles Burrell & Sons, which is sorted under C), so I know that the sort key is definitely not inherited by the talk page. Is this non-inheritance (a) a MediaWiki limitation; (b) a deliberate omission for performance reasons; (c) a bug that can be fixed or (d) a feature which it's possible to implement? If it were possible it would do away with the need for (virtually?) every WikiProject banner template to provide a |listas= parameter. --Redrose64 (talk) 20:51, 19 February 2011 (UTC) amended Redrose64 (talk) 21:07, 19 February 2011 (UTC)

I think (d) is correct, but it may be hard to do it or do it efficiently, so (a) and (b) might be on the right track too. I think you should try filing a bugzilla request and see where it goes. Svick (talk) 21:20, 19 February 2011 (UTC)