Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by AKlapper (WMF) (talk | contribs) at 14:59, 11 July 2017 (→Vandalism still visible when I'm logged out?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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.


Nowrap template no longer working

I've noticed that Template:Nowrap stopped doing what it was designed to do overnight. I edit and access Wikipedia from a mobile device, and the template it very useful for organising complex tables—such as those at 2017 World Rally Championship—because it keeps the cells of the table on one line.

This isn't the first time this issue has arisen, so I'm guessing it's just a by-product of a software update or something of the like. Prisonermonkeys (talk) 08:52, 1 July 2017 (UTC)[reply]

This template only puts the content into an "nowrap" CSS class. Since it still works for me and that you have no custom CSS, it's indeed likely to be because of a software update on your side. —PaleoNeonate - 09:12, 1 July 2017 (UTC)[reply]
Adding: unless the CSS was recently changed for mobile, which I can't easily test (my mobile systems use a custom solution which appear like a non-mobile browser to the Wikimedia software). —PaleoNeonate - 09:15, 1 July 2017 (UTC)[reply]
I changed the CSS for mobile. I disabled it. I kept running into more and more problems on mobile where lines were not wrapping because people had added nowrap to it, causing the viewport to be wider than the width of the device. People are using nowrap in an excessive extent, beyond the purpose. Tables as described above is one such example. You should just set the min-width of the table cell using em units in that case. Much safer, much more flexible. I have disabled the Mobile styling for now, to find out if we can maybe live without it. If not we can always reenable, but I feel that the problems are elsewhere. —TheDJ (talk • contribs) 10:25, 1 July 2017 (UTC)[reply]
@TheDJ — I didn't understand a word of that; you lost me at "CSS". Could you please explain your preferred solution and provide an example of the replacement markup that I can use? Prisonermonkeys (talk) 23:41, 1 July 2017 (UTC)[reply]
@Prisonermonkeys: TheDJ has temporarily stopped the template from working on the mobile site because it has been unnecessarily overused, causing text to overflow on narrow screens. His solution is to add width styling, such as style="min-width: 15em", to table cells. This change is not permanent as the CSS (styling) for the mobile site is largely controlled by MediaWiki:Mobile.css, which he edited to disable the template. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:59, 2 July 2017 (UTC)[reply]

@Jc86035 — thank you for that explanation. Unfortunately, the width styling is incredibly fiddly and unwieldly to use on mobile devices and it requires a whole lot of trial and error just to implement. Prisonermonkeys (talk) 02:22, 7 July 2017 (UTC)[reply]

@TheDJ: I think it might be better to re-enable it. It's unavoidable that some tables are going to overflow on the mobile site, purely because some screens are too small for them. Even the third column of the table at Metropolitan line#List of stations isn't fully shown on my phone (when vertical), and no nowrap is used there. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:26, 7 July 2017 (UTC)[reply]
And sometimes it's beneficial to force a table to be wider than the width of the device. The aforementioned tables in the likes of 2017 World Rally Championship can get very complex, especially when individual cells can span multiple rows or columns. Prisonermonkeys (talk) 06:28, 7 July 2017 (UTC)[reply]

Issue with scripts loading

Hi all, hoping someone might be able to help with this. When I go to some pages all of the scripts I am using load, while when I open others only a couple do (from what I can see only m:MoreMenu and WP:Refill). Sometimes if I refresh the page all of them will and sometimes only some (those two) will load, when I edit a page all of the scripts load. I'm guessing this might have something to do with a timeout as the page loads (though page size doesn't seem to affect it - seems much more random). Is there a way to work out what the issue is (including if it's with a specific script). I'm using Chrome on Windows 10. Thanks, Callanecc (talk • contribs • logs) 08:50, 2 July 2017 (UTC)[reply]

@Callanecc:--I too have my share of this problem.Entirely similar in nature.Somewhere read, Kudpung too facing this.So, it wouldn't be un-expected if a lot of users felt the problem.And no, it's not some specific script based.In my case, using Edge solves the problem. But still, sometimes you have to go for a F5! Anyway there are often some interesting developments on the console! Winged Blades Godric 17:51, 2 July 2017 (UTC)[reply]
That is correct, I am indeed having exactly the same issue as described by Callanecc. Using OSX and Firefox, latest releases. No fancy plug-ins on Firefox. Same issue on all my Macs, and which ever IP I'm using. I usually find that if I immediately refresh the page, the rest of the scripts will load. The one to fail to load most often is Twinkle - particularly the parts of it that are only visible to admins. I tried pruning my .js page a couple of days ago but it hasn't helped. I don't have problems with any other web sites that use a lot of js or server-side apps. Kudpung กุดผึ้ง (talk) 18:01, 2 July 2017 (UTC)[reply]
@MusikAnimal: have you got any ideas what could be causing this? Callanecc (talk • contribs • logs) 00:22, 3 July 2017 (UTC)[reply]
My bet is some of the scripts you are using are not properly declaring dependencies on other scripts. This is why sometimes they work, sometimes they don't -- it's a race condition. Fortunately it's easy to fix. When I'm back home later tonight I'll go through all of your scripts and see what I can do :) TheDJ might also want to help. We should try to get a bot-generated list of scripts that need fixing — MusikAnimal talk 00:46, 3 July 2017 (UTC)[reply]
@Callanecc: I updated several scripts. I think this should fix your issue, but let me know otherwise :) — MusikAnimal talk 03:04, 3 July 2017 (UTC)[reply]
@MusikAnimal: thanks for working on this! The scripts seem to be working consistently in mainspace, but not elsewhere (only the menus on userpages and at SPI). Callanecc (talk • contribs • logs) 04:48, 3 July 2017 (UTC)[reply]
I've done some more assorted fixes, but many of these scripts are so old and there are so many of them, it's making it hard to find specific problems. Some of this stuff hasn't worked for years, it's a miracle both of you were able to do anything at all one the site :D —TheDJ (talk • contribs) 19:27, 3 July 2017 (UTC)[reply]
I've been having issues for the last month or so, especially w/Twinkle. Loads about 1/4 of the time. Running on updated W10 and Firefox. GenQuest "Talk to Me" 19:08, 3 July 2017 (UTC)[reply]
You broke your own javascript, by accidentally adding CSS to it. —TheDJ (talk • contribs) 19:34, 3 July 2017 (UTC)[reply]
  • I think what I've been experiencing is related. Also, look back through archives of about the last month, malfunctioning scripts seems to be a recurring problem with a lot of issues and editors. With me, it's the edit screen. When I first open the edit window, it's plain text with no toolbar, no distinguishing colors in the text. Nothing. It takes 3 "preiews" before everything looks like it's supposed to ... the edit toolbar visible and the distinguishing text colors for inserted templates, etc. But if I edit when it finally looks normal, and do a Preview, it goes back to everything missing but the text. This is very hard to look at and edit within. — Maile (talk) 19:26, 3 July 2017 (UTC)[reply]
    See mw:Help:Locating_broken_scripts. If you keep having problems and are not able to fix them, then just disable EVERYTHING. Get back to a clean slate and start adding your scripts from scratch (and only those you actually use, and that seem slightly maintained. I realize people are attached to their scripts, but if you cannot maintain scripts, while at the same time you have problems editing, then it is time to get back to square 1. —TheDJ (talk • contribs) 19:31, 3 July 2017 (UTC)[reply]
    Well ... I just noticed a script that I apparently added last year, and looks like it came from the German wikipedia. Removing that script seems to have helped. A year later, I have no idea why I added it in the first place. Thanks for the suggestion. — Maile (talk) 19:52, 3 July 2017 (UTC)[reply]
    TheDJ As it turns out, removing that one script didn't really correct anything. The problem has returned. However, when you say "if you cannot maintain scripts", I'm not maintaining what I have. They are "imported" from other user pages. I'll try removing another one.— Maile (talk) 20:22, 3 July 2017 (UTC)[reply]
    Removing another one didn't do anything either. — Maile (talk) 20:24, 3 July 2017 (UTC)[reply]
    TheDJ Per your advice, I removed all scripts from my commons.js and rebooted my browser. The sporadic edit window issue still exists. Strange. The only thing I can conclude is that this is part of some weird blip happening because of ongoing changes. Hopefully, things will work out. Unless you have another idea what is causing this. — Maile (talk) 12:15, 4 July 2017 (UTC)[reply]
    @Maile66: The only other thing I can think of is that maybe it's a Gadget in your preferences. Usually gadgets are pretty well maintained, but perhaps there is an outlier in there. from "distinguishing text colors" i suppose you at least have enabled the syntax highlighter extension by Remember the dot enabled. I note this gadget has some pretty strange postfix in it's description of "(works best in Firefox and works almost all of the time in Chrome and Opera)". —TheDJ (talk • contribs) 12:47, 4 July 2017 (UTC)[reply]
    @TheDJ: Yesterday, I tried unchecking gadgets, just because they can have quirks. However, when the colors don't display, the edit toolbar also doesn't load. As far as I know, this started back on June 30, when I (and others) were also temporarily encountering that 502 Bad Gateway quirk. Whatever is happening, all this seems to be linked together. — Maile (talk) 13:22, 4 July 2017 (UTC)[reply]
    And finally, I think I have a clue. Refreshing my Firefox 54.0.1 browser once in the edit window has the same effect as clicking "Publish" three times - all the scripts load correctly with a browser refresh. Looking into the Mozilla files on my computer, June 29 is the date I updated to the new browser. And, yep, the problems began then. So, eliminating all else already, it surely must be this new version of Firefox. — Maile (talk) 18:16, 4 July 2017 (UTC)[reply]
  • I am experiencing the same issue with Twinkle and some other scripts I use. It loads about 35% of the time. Callmemirela 🍁 talk 22:52, 3 July 2017 (UTC)[reply]
  • Thanks MusikAnimal and TheDJ for the help! I think I've solved my problem. I ran the debugger as suggested above and it identified a problem (hasClass being a null value) with the markblocked gadget which I was importing from ruwiki (as that's where it was when I added it) in my global.js page. I updated that to the version of script on meta, which seems to have solved the problem. Thank you, Callanecc (talk • contribs • logs) 00:52, 4 July 2017 (UTC)[reply]

Syntax highlighting on Firefox is not working consistently

I have syntax highlighting enabled on my account, and I primarily use Firefox for Wikipedia. However, the syntax highlighter is not always working. It did when I typed this messages, but elsewhere it refuses to work. When it doesn't, it never gives me the "Syntax highlighting is disabled message", it just never loads at all as if I had never enabled it in my preferences. —MRD2014 01:23, 5 July 2017 (UTC)[reply]

@MRD2014: See my comments above. Does your syntax highlighter work if you reload the page? My similar issues happened on the date I upgraded to Firefox 54.0.1 on June 29. Took me a while to figure it was Firefox, but I have the same problem as you. Not only does the highlighter not work (usually) the first time I open an edit window, but the edit toolbar is not there. If I reload the page, the highlighter and everything else shows up. Sometimes it takes a couple of reloads. But having eliminated all other possibilities, and the problems coinciding with when I upgraded to 54.0.1, the problem is Firefox. — Maile (talk) 11:21, 6 July 2017 (UTC)[reply]
@Maile66: I do have version 54.0.1 installed, and my edit toolbar shows up (the one with the bold and italic buttons), but the syntax highlighter is very unreliable and sometimes loads but most of the time it doesn't. —MRD2014 13:27, 6 July 2017 (UTC)[reply]
@MRD2014: Exactly, except for the toolbar.
  • As I am typing this, I see the toolbar above, but no highlighting.
  • Now I have reloaded the page by clicking the arrow in the URL area, and the highlighting now magically appears.
  • Now I just clicked "Preview" and both the toolbar and the highlighting disappeared.
  • I have now clicked on the arrow in the URL area, and it asked me if I wanted to Resend the page. I said I did. Now both the toolbar and highlighting are back.
If that's how it's more or less working for you, and you have Firefox 54.0.1, I believe it's a Firefox issue. — Maile (talk) 13:37, 6 July 2017 (UTC)[reply]
This is what happened to me.
  • I clicked "edit" and the highlighting appeared, and the toolbar was there.
  • Upon clicking "Show preview", everything was still there (I have live preview enabled).
  • When clicking on edit on other pages, it seems to load the highlighter more often that not after typing this.
Very weird issue. —MRD2014 13:43, 6 July 2017 (UTC)[reply]
It happens to me in both Firefox and Chrome. It's a resource issue. dawnleelynn(talk) 16:13, 10 July 2017 (UTC)[reply]
@MRD2014 and Dawnleelynn: If you think this looks weird in Wikipedia, try editing in Commons. It's awful there. — Maile (talk) 16:48, 10 July 2017 (UTC)[reply]
It seems like the syntax highlighter is working more reliably for me now here (still on 54.0.1). —MRD2014 16:51, 10 July 2017 (UTC)[reply]

Maile66 MRD2014 I haven't been in Commons since Christmas. But that's unfortunate. I've been in Chrome due to a different Firefox issue I just posted, and the syntax highlight issue is occurring there. dawnleelynn(talk) 17:00, 10 July 2017 (UTC)[reply]

@MRD2014 and Dawnleelynn: The syntax highlighter, and the appearance (or not) of the edit toolbar, are still hit and miss for me on Wikipedia. Until recently, I think it had been weeks or months since I'd edited any text at Commons. There's no highlighting or formatting at all in the edit window at Commons, and the edit toolbar is also hit and miss over there. — Maile (talk) 17:08, 10 July 2017 (UTC)[reply]

Women's World Contest

Hi, I'm planning on running this contest in October. However, given how much effort daily the Wikipedia:WikiProject Africa/The Africa Destubathon took I will need assistance with a bot to help check article length and sourcing once submitted. I was wondering if somebody could code Wikipedia:ContestBot with the ability to approve or decline articles submitted to the contest pages with a tick or x. It will be a new article contest, and 1 kb of readable prose the minimum requirement. The bot would also need to check that there are no unsourced paragraphs. Would this be reasonable to code? Getting a bot designed to reduce the time needed to run contests I think will be essential for future growth of contests in other areas. Thanks.♦ Dr. Blofeld 09:39, 4 July 2017 (UTC)[reply]

Anybody?♦ Dr. Blofeld 06:21, 7 July 2017 (UTC)[reply]

Regular expression

Is there a PCRE regular expression which can match and fix incorrectly nested templates (e.g. {{Template|para=value{{Template|para=value}}}} → {{Template|para=value}}{{Template|para=value}}), where parameter values can themselves correctly contain other templates? This would be used by UsuallyNonviolentBot task 1, as there are several hundred pages where {{Extra chronology}}, {{Extra album cover}}, {{Extra track listing}}, {{Singles}}, {{Audio sample}} and {{External music video}} are incorrectly nested inside each other instead of being side by side. An example is Wonderwall (song), where {{External music video}} is nested inside {{Extra track listing}}. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:54, 5 July 2017 (UTC)[reply]

If you can narrow down your problem to one level of nesting, such as looking for {{External music video}} nested within {{Extra track listing}}, without any other templates nested within either one, and the fix is simply to extract the nested template and move it out immediately following, then it's not too complex. If you're trying to be more generalized, though, I think automated fixing is tricky with just a regular expression. Some kind of parser to separate out the template arguments would be better. isaacl (talk) 15:53, 5 July 2017 (UTC)[reply]
@Isaacl: Thanks. I've made a regex (\{\{([eE]xtra album cover|[eE]xtra chronology|[sS]ingles|[eE]xternal music video|[aA]udiosample|[eE]xtra music sample|[aA]udio sample|[Ee]xtra track listing)(\{\{[^{}]+\}\}|[^{]|\s|\{[^{])*)((\{\{([eE]xtra album cover|[eE]xtra chronology|[sS]ingles|[eE]xternal music video|[aA]udiosample|[eE]xtra music sample|[aA]udio sample|[Ee]xtra track listing)(\{\{[^{}]+\}\}|[^{]|\s|\{[^{])*\}\})+)\s*\}\}\s* → $1}}$4. Unfortunately, even though Regexper says it works and it functions successfully in AWB's advanced regex testing with the infobox of 911 (Gorillaz and D12 song), loading the entire page causes AWB to hang and I have no idea why. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:46, 6 July 2017 (UTC)[reply]
It's not just tricky to make a generalised fix for nested templates using regular expressions - it's impossible. (The problem is analogous to trying to parse HTML with regex.) To deal with nested templates properly, you need to use a wikitext parser. I'd try using Parsoid or mwparserfromhell. — Mr. Stradivarius ♪ talk ♪ 14:40, 8 July 2017 (UTC)[reply]
Agreed the completely general problem needs a parser. The original poster might be able to get by with something else, depending on what specific subset of the issue that is being examined. isaacl (talk) 15:27, 8 July 2017 (UTC)[reply]

Some updates about Recent Changes pages

Hello!

As you may already know, the Collaboration team has created a Beta feature. This feature is on your wiki since few months: "⧼eri-rcfilters-beta-label⧽". You can activate it in your Beta preferences.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked. It adds new features that ease vandalism tracking and support of newcomers:

  • Filtering - filter recent changes with easy-to-use and powerful filters combinations.
  • Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
  • Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help.

This last set of filters is available on your wiki, but there is an ongoing labeling campaign to refine the results (3885 left to do).

You can know more about all those features by visiting the quick tour help page.

What's new?

Since the release, we have fixed small bugs and improved the interface. We have also released a way to bookmark your favorite configurations of filters.

We plan to add more new features! The full list is on this Phabricator page (in English) but here are the most important ones:

  • Filters for Namespaces and tagged edits and, later, filters for Categories and Usernames
  • Redesign navigation by using an improved time selector and better integrated navigation options
  • Add live updates
  • Have a more clear interface by putting community-defined 'related links' into a collapsible panel

This last change is about links displayed on top of the RecentChanges (see how they look like on your wiki). We do that change because we have discovered that those links are not that much used. Also, they sometimes take a lot of space on small screens. To help people to focus on recent changes patrolling, we will hide those links, with an option to show them. We have created some examples to show you how it will look like. If you like to see those links all the time, you will have to click on the link to show them and they will remain open. We welcome your feedback about this change.

Most of this information was already introduced in the Collaboration monthly newsletter. Please subscribe to get regular updates!

You can ping me if you have questions.

All the best,Trizek (WMF) (talk) 10:24, 6 July 2017 (UTC)[reply]

Huge delay for Wikidata changes

I already noted this in a previous section, but it seems to have become considerably worse. When I try to see Wikidata changes in my wtachlist or in recent changes, I need to scroll way way down before I get anything.

The delay now seems to be 1 1/2 hours, which means that no matter how I try it, no Wikidata changes appear in "recent changes" (expanded to 5000(!) items, mainspace only, no minor edits). In my watchlist (which of course is dependent on what I have in my watchlist) the most recent Wikidata change is almost 2 hours old, but then I get one every 5 or ten minutes, so this seems again evidence of a huge delay. For a watchlist this is annoying (I check mine regularly, I don't check if anything "new" has popped up 2 hours in the past), for recent changes this is unacceptable. It does explain why major Wikidata vandalism remains unnoticed for weeks or months, and it also seems to be indicative of how many people here actually have activated and use the Wikidata option... Fram (talk) 12:22, 6 July 2017 (UTC)[reply]

@Lydia Pintscher (WMDE): Seems like an issue for you. --Izno (talk) 12:32, 6 July 2017 (UTC)[reply]
@Izno: Thanks for the ping!
@Fram: Thanks for bringing this to my attention. Is there anything special to the changes or is it all of them? --Lydia Pintscher (WMDE) (talk) 13:16, 6 July 2017 (UTC)[reply]
All of them. Fram (talk) 13:32, 6 July 2017 (UTC)[reply]
Ok thanks. I think I have found the problem. Currently a lot of new items on Wikidata are being created for articles on cebuano Wikipedia. This leads to a lag in informing all Wikipedias about changes. I have brought this up on Wikidata. --Lydia Pintscher (WMDE) (talk) 14:02, 6 July 2017 (UTC)[reply]
The discussion is at Wikidata:Project chat#Q32000000. Someone is running a megabot. Thincat (talk) 10:46, 7 July 2017 (UTC)[reply]

Search for contributions to a specific page?

Is there a way to find all the edits I've made to a specific page? -- RoySmith (talk) 13:40, 6 July 2017 (UTC)[reply]

@RoySmith: Yes, the user contrbibution search tool which is also linked from page histories under the title "Edits by user". Graham87 07:05, 7 July 2017 (UTC)[reply]
Cool. That's exactly what I was looking for. Thanks. -- RoySmith (talk) 12:19, 7 July 2017 (UTC)[reply]

Bug in page history?

Resolved

This edit, made 04:57 on 6 July 2017, currently shows in the history as an addition of +163 bytes, rather than a very large negative value that I would expect, given that the user has removed all previous messages. A bug, or am I missing something obvious? Optimist on the run (talk) 17:46, 6 July 2017 (UTC)[reply]

Looks to be a bug, the old page text is showing as 0, so it netted +163 (the new page size). — xaosflux Talk 17:52, 6 July 2017 (UTC)[reply]
Not technically an abuse filter problem - but it is also presenting as a problem there, added this information to phab:T168736. — xaosflux Talk 19:10, 6 July 2017 (UTC)[reply]
The log [1] shows the page was deleted before the edit and restored after the edit, so the edit created the page at the time and did indeed add 163 bytes. PrimeHunter (talk) 21:43, 6 July 2017 (UTC)[reply]
Thank you PrimeHunter - we can put THIS one behind us. — xaosflux Talk 22:41, 6 July 2017 (UTC)[reply]

Wikitext Syntax Highlighting beta feature available for testing

Screenshot of Wikitext Syntax Highlighting on test.wikipedia

Hi everyone, the WMF Community Tech team has a new feature that's up for testing, if you'd like to take a look. The feature is Wikitext Syntax Highlighting, which was #6 in this year's Community Wishlist Survey -- a way to help editors parse the text in the edit window by using color, bolding, italics and size to make it easier to see which parts are article text, and which are links, templates, tags and headings. It's easy to separate the link target from the actual link text, section headings are bigger, and adding bold and italics actually changes the way it looks in the edit window. Plus -- thanks to the amazing performance optimization done by volunteer developer Pastakhov -- it loads a lot faster than previous versions of syntax highlighting.

Syntax Highlighting is currently a Beta feature on test.wikipedia, and here's a test article you can check out: Barack Obama. If everything goes well, we'll be rolling this out as a Beta feature on live wikis soon. Please feel free to test it out, and you can leave comments and questions on the project talk page on Meta. Thanks! -- DannyH (WMF) (talk) 23:00, 6 July 2017 (UTC)[reply]

Pink! Purple! Blue! --Izno (talk) 03:03, 7 July 2017 (UTC)[reply]
stress test :D —TheDJ (talk • contribs) 09:19, 7 July 2017 (UTC)[reply]
TheDJ: Oh, good idea; I'm going to change the example links. :) DannyH (WMF) (talk) 17:10, 7 July 2017 (UTC)[reply]

Vandalism still visible when I'm logged out?

Tracked in Phabricator
Task T169894

Earlier today, I reverted some vandalism at Mort Walker and John Aloysius Farrell. However, it seems that when I view these pages now, when logged out, the vandalism is still visible. That's true regardless of the browser. I've looked at these pages in Chrome, Firefox, and Microsoft Edge. Does anyone have any ideas?

The vandal's edits were severe BLP violations, so I hope that they don't remain visible to the masses. Zagalejo^^^ 23:05, 6 July 2017 (UTC)[reply]

Are you possibly using a proxy server that may be caching (such as a corporate proxy server)? — xaosflux Talk 23:14, 6 July 2017 (UTC)[reply]
No... but it seems that the problem has now resolved itself, whatever it was. *shrugs* Zagalejo^^^ 23:24, 6 July 2017 (UTC)[reply]
Remember, anonymous users are shown cached versions. There could be several reasons the article doesn't show up immediately to non-logged in folks: varnish cache didn't get purged (for any of a half dozen causes from software bugs to a network hiccup), the job queue is overly backed up, browsers still have a cached version locally, or some sort of corporate or ISP proxy that attempts to cache content. Long as it eventually shows up without further user action, it usually implies one of the latter reasons. As always, a purge should fix things up. If it continues to be outdated, that's a bug. FACE WITH TEARS OF JOY [u+1F602] 01:10, 7 July 2017 (UTC)[reply]
What is your username? All I see in Opera 36 is a plain rectangle. --Redrose64 🌹 (talk) 10:17, 7 July 2017 (UTC)[reply]
The user name is the Unicode character U+1F602, which is officially named "FACE WITH TEARS OF JOY". It's an emoji code point, represented as 😂, 😂,😂, and 😂 in the emoji sets we have available with {{emoji}}. Anomie⚔ 12:03, 7 July 2017 (UTC)[reply]
@😂: The relevant Phabricator task I have created is phab:T169894. It is about caches not being updated when viewed by logged out users. GeoffreyT2000 (talk) 14:38, 7 July 2017 (UTC)[reply]

Problem with logging in

Hello, I'm the user known as "nineko" and I'm mainly active on the Italian and on the English Wikipedias. I'm having a bizarre problem. My Cookies settings are correct, and, more importantly, I didn't change them recently. I've always been able to stay logged in and edit pages (see, for reference, my contributions in Italian and in English). However, earlier today I went to Wikidata to report a mistake ([2]), and since them I'm logged off from every Wikipedia. If I try to log back in, I either can't altogether, or I briefly appear as logged in, just to be logged off as soon as I change page. I tried to use another browser (Chrome instead of my usual Firefox), giving it the most permissive Cookies settings possible, but the problem was still there. I tried to delete all the Cookies in case some of them were corrupted for some reason, but nothing changed, either. So, if two Cookie-permissive browsers don't work even after a complete cleanup, I'm confident that the problem isn't on my end. Even though I'm quite expert when it comes to these issues, having been a webmaster and administrator myself in the past, I don't know what else to do. Visiting Wikidata maybe corrupted some of my session data on the server, which is obviously out of my reach. Can anyone help with identifying my problem and fixing it? Thanks in advance.
2.235.238.165 (talk) 23:23, 6 July 2017 (UTC)[reply]

Try to clear all your cookies, make sure you are accepting cookies, then try to login here: login.wikimedia.org. — xaosflux Talk 23:25, 6 July 2017 (UTC)[reply]
Been there, done that. As I said, I already tried everything I could, including deleting all my cookies and using another browser just in case. I tried again because you asked nicely, but with no success, in both Firefox and Chrome. To reinstate, I didn't change any cookie setting recently, the fact that this issue is present with two different browsers alone should tell that this isn't on my end. I just started to get logged off as soon as I visited Wikidata. Some administrator should check my session on the server.
2.235.238.165 (talk) 23:32, 6 July 2017 (UTC)[reply]
This may be related to a hash update (phab:T169261) try logging in at this wiki that you have never touched zh.wikivoyage. — xaosflux Talk 00:49, 7 July 2017 (UTC)[reply]
Thanks a lot :D
Nineko (talk) 01:01, 7 July 2017 (UTC)[reply]
It is probably worth suggesting that having achieved a successful login on a previously-untouched wiki, the user should explicitly log out; this will invalidate all login cookies server side, so at the next login attempt on a frequently-visited wiki, a clean cookie will be delivered which does not conflict with old corrupt cookies. --Redrose64 🌹 (talk) 10:20, 7 July 2017 (UTC)[reply]

Xi's tools- Edit counter

[https://tools.wmflabs.org/xtools-ec/?user=ClemRutter&project=en.wikipedia.org] just throws an error [error::mq] after 9.75 seconds of processing. Firefox and Chromium on Linux Mint. Sometimes change is not for the best. --ClemRutter (talk) 01:12, 7 July 2017 (UTC)[reply]

The xTools have been unstable for years. I don't know which change you refer to. PrimeHunter (talk) 07:59, 7 July 2017 (UTC)[reply]
Indeed, appears that the edit counter is once agian being grumpy. I'll give it a kick.
Community tech and I are in the process of building a completely new, more stable version of XTools. We are preparing to enter beta at some point over the next month. Please keep an eye out for that. ~ Matthewrbowker Say something · What I've done 16:06, 7 July 2017 (UTC)[reply]
Very nice to know, thanks! —PaleoNeonate - 16:17, 7 July 2017 (UTC)[reply]
As a follow-on to this, you've actually discovered a bug in both the new and old xtools. See T170005 for the bug report. You are welcome to keep an eye on that page for further information. Thank you so much! ~ Matthewrbowker Say something · What I've done 19:54, 7 July 2017 (UTC)[reply]

Edit conflict not working

The new edit conflict dialogue doesn't work for me. I have spent some time puzzling over where I am supposed to put anything - the help says there are two columns, but I only see one. Eventually I have started noticing that there is a second column, but it then vanishes. am I missing something? (I use Vector skin. I haven't looked at my Custom js, but I haven't changed its contents in years). --ColinFine (talk) 11:56, 7 July 2017 (UTC)[reply]

This reminds me that when it was a new feature I tried it, but quickly disabled it as I had no idea what to do when presented with it and I didn't have the time to find out (with no custom JS scripts in use)... I have not tried it very recently, so am not sure if it is related. I would have less trouble dealing with raw text unified diffs —PaleoNeonate - 16:15, 7 July 2017 (UTC)[reply]
Hey you two!
Thanks for your feedback! We already got reports like that on the extension feedback page and in both cases the broken column layout seemed to be related to the wikEd extension. You could try disabling that and see if the two column conflict page looks fine without it. I wrote a small guide how to create an edit conflict with yourself to test the feature. It would be really great to hear from you again if that helped.
When the issue really is wikEd related, there is a patch coming where we temporarily deactivate wikEd on the two column conflict page. You could have a look at the ticket on Phabricator to see the progress in that matter.
Best, and thanks again Christoph Jauera (WMDE) (talk) 09:51, 10 July 2017 (UTC)[reply]
@Christoph Jauera (WMDE): btw. would be cool to have a Special:EditConflictSimulator page, which allows us to test this. Much handier than having to follow complicated steps in a guide. —TheDJ (talk • contribs) 11:08, 10 July 2017 (UTC)[reply]

Page categorization not being reported in watchlist

There seems to be a problem with the watchlist reporting of additions/removals from categories. For example when watching Category:CS1 errors: dates there is no report of additions to the category of 2017 Manchester Arena bombing or 2017 CONCACAF Gold Cup. I have noticed this before and it appears to be with articles that start with a number that get missed from the watchlist. Keith D (talk) 18:52, 7 July 2017 (UTC)[reply]

It works for me. Have you enabled "Show hidden categories" at Special:Preferences#mw-prefsection-rendering? For 2017 Manchester Arena bombing the category was not changed in the most recent edit and it only shows up when I enable "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 19:21, 7 July 2017 (UTC)[reply]
It usually shows up for other articles that have been changed. Both of the articles have appeared in the category today but not on the watchlist. I have unchecked the page categorisation on the hide list before refreshing the watchlist page. Keith D (talk) 20:50, 7 July 2017 (UTC)[reply]

Clarity of user-rights log messages

When user rights are changed, the log usually lists the old rights and the new rights. That is useful in some cases, but other times what I really want to see is what changed, which is difficult when the information is a sentence with lists of words. More clear is what some admins so in their edit summary, saying what right was added/removed rather than just an explanation of why some change was made. Consider the following three examples from the current log (chosen solely for illustrative purposes), listed in increasing order of readability that entails increasing amounts of work by admin:

  • 11:47, 10 July 2017 Alex Shih (talk | contribs | block) changed group membership for Jupitus Smart from autopatrolled, extended confirmed user, new page reviewer, pending changes reviewer and rollbacker to autopatrolled, extended confirmed user, new page reviewer, pending changes reviewer, rollbacker and page mover
  • 12:08, 10 July 2017 Alex Shih (talk | contribs | block) changed group membership for Seppi333 from extended confirmed user and IP block exempt to extended confirmed user, IP block exempt and template editor (Wikipedia:Requests_for_permissions/Template_editor)
  • 11:06, 10 July 2017 Kudpung (talk | contribs | block) changed group membership for Steve Quinn from autopatrolled, extended confirmed user and pending changes reviewer to autopatrolled, extended confirmed user, pending changes reviewer and new page reviewer (+patroller; Requested at WP:PERM; Special:PermaLink/789904243#User:Steve Quinn (using userRightsManager))

The "+patroller" in the third is what I would like to see happen automatically. DMacks (talk) 12:32, 10 July 2017 (UTC)[reply]

This is a good idea. I have the same problem, and an elegant solution would be welcome. – Jonesey95 (talk) 13:49, 10 July 2017 (UTC)[reply]
I agree that seeing the difference rather than only another list of all groups would be convenient. —PaleoNeonate - 14:05, 10 July 2017 (UTC)[reply]

Looking back, it seems like the message used to do this (until sometime in or before December 2009), according to Wikipedia:Village pump (technical)/Archive 69#Rights changes. Apparently prior to that, only the change was stored, so that's all that the log said, but then the old/new perms themselves were stored so the full lists were included in the log instead. I can't find "changed group membership for" in the MediaWiki: namespace of system messages, which might tell us when the current message was created. DMacks (talk) 19:02, 10 July 2017 (UTC)[reply]

But anyway, given it's based on a change to the storage (back-end, not front-end) it doesn't really matter how it used to be implemented front-end. Now, it's a front-end issue with parsing the new back-end data in LogFormatter.php getIRCActionText(). I guess we're headed out of VPT into the land of Phab? DMacks (talk) 19:23, 10 July 2017 (UTC)[reply]

Can Edit summary dropdown box allow more lines?

Greetings, Before asking here I did check the FAQ and the Archives for a possible answer. Is there an easy way to increase the number of lines that appear on the Edit summary dropdown box? This is not a major concern, just thought it would be helpful to have more choices showing. I'm setup for the Vector skin. Regards, — JoeHebda • (talk) 14:00, 10 July 2017 (UTC)[reply]

Tech News: 2017-28

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • There are sometimes links to pages about the same thing on other Wikimedia projects. A Wikipedia article about Berlin can link to the Wikivoyage guide or Wiktionary entry about Berlin. You can now see when that page has a badge. A badge could be the star that shows that an article is a featured article. [3]

Changes this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 July. It will be on non-Wikipedia wikis and some Wikipedias from 12 July. It will be on all wikis from 13 July (calendar).

Meetings

  • You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 11 July at 19:00 (UTC). See how to join.

Future changes

  • Mobile users will be able to edit Wikipedia without JavaScript. This will make it possible to edit the wikis from older mobile phones. This will probably happen on 18 July for most wikis. [4]
  • We will not use Tidy on Wikimedia wikis in the future. It will be replaced by June 2018. It could be earlier. Editors will need to fix pages that could break. You can read the simplified instructions for editors.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:07, 10 July 2017 (UTC)

In the Source Editor, Cite - Template not working

It started in Firefox, clicking Cite on the toolbar, and then Templates, and then Web. Then proceed as normal, clicking the magnifying glass to propagate the fields on the Web Citation form. Then clicking the date page to propagate the Access date field. Then filling in remaining fields manually, and adjusting any other fields. Once the information is final, click the Insert button. Nothing happens. I have the most updated version of Firefox, which is 54.0.1. (64-bit). In fact, it had just updated, and I thought that might have been what broke the form. I am running Windows 10 64-bit. So, I downloaded Chrome to try it out there. I am running the most current version of Chrome 59.0.3071.115 (Official Build) (64-bit). It worked for several days, but then it broke yesterday. You don't always know when Chrome has updated, so Chrome may have updated since when I start using it. Anyway, so now the form is not working in either browser. I am using the Visual Source Editor citation generator as a work-around for now. But I would really prefer to use the citation generator in the Source Editor. I am surprised no one else has reported this issue already. Appreciate any insight. Thanks! dawnleelynn(talk) 16:55, 10 July 2017 (UTC)[reply]

Do you have the syntax highlighting beta enabled in your preferences ? —TheDJ (talk • contribs) 17:05, 10 July 2017 (UTC)[reply]
TheDJ (talk · contribs) Hi, was away a few minutes. Thanks for your reply. I have the Syntax Highlighter under Edit enabled. It doesn't say it is a beta feature. I couldn't find any syntax highlighter that says it is a beta feature. Do you think I should disable this feature regardless and see if it helps? Thanks! dawnleelynn(talk) 17:52, 10 July 2017 (UTC)[reply]
TheDJ (talk · contribs) I tried disabling that feature, but it didn't help. dawnleelynn(talk) 18:04, 10 July 2017 (UTC)[reply]
dawnleelynn (talk · contribs) I use the drop down citation templates mostly. I have no idea what the magnifying glass is for, since I've never used it (what does it do?). So, except for the magnifying glass (which does nothing on mine), the drop down web citation template worked for me in Firefox 54.0.1. (32-bit) I have the same Windows version as you do. The only thing that seems to be different between us is the bit-version of Firefox. — Maile (talk) 19:24, 10 July 2017 (UTC)[reply]
Here's another thing that sometimes works. Under Preferences/Gadgets/Editing, if you have either "wikEdDiff" or "WikEd" checked, uncheck them and see if that improves things. — Maile (talk) 19:48, 10 July 2017 (UTC)[reply]

Maile66 Thanks for responding. I checked my Preferences where you specified. I don't have either of those boxes selected. But you never know. Thanks for trying. dawnleelynn(talk) 20:11, 10 July 2017 (UTC)[reply]

How do you suppress those annoying watchlist dropboxes?

See https://gyazo.com/3b890d5350145ebb2e2d8cbad3da43cc. Those tend to show up randomly, and I don't know what causes them, or how to stop them from popping up. Headbomb {t · c · p · b} 18:41, 10 July 2017 (UTC)[reply]

@Headbomb: You have User:UncleDouggie/smart watchlist.js in your User:Headbomb/monobook.js which does that. The fact that it doesn't always work, is likely because one of the other scripts in your monobook.js is sometimes failing, and then taking everything else with it. —TheDJ (talk • contribs) 20:21, 10 July 2017 (UTC)[reply]
better ?? I also fixed some of the other scripts you were including and removed ones that were either empty, broken or otherwise pointless. —TheDJ (talk • contribs) 20:57, 10 July 2017 (UTC)[reply]
Alright, I'll give this a try, although I've lost my CitationBot link, which was one that most definitely worked. Headbomb {t · c · p · b} 21:56, 10 July 2017 (UTC)[reply]
Enabled it via Gadgets. Headbomb {t · c · p · b} 21:58, 10 July 2017 (UTC)[reply]

TheDJ (talk · contribs) while you're at it, could you take a look at User:Js/watchlist.js? Previously, there was a function that let your sort your watchlist by namespace/alphabetically, and it stop working a while ago. Headbomb {t · c · p · b} 22:15, 10 July 2017 (UTC)[reply]

Hmm, I tried my best, but it's still ancient and fragile. Still requires a lot more time to invest. —TheDJ (talk • contribs) 23:29, 10 July 2017 (UTC)[reply]
Well, so far, whatever you did seems to have fixed it. At least as far as the functionality I cared about goes. Headbomb {t · c · p · b} 01:54, 11 July 2017 (UTC)[reply]

MiszaBot I messing up Talk pages

I'm working on a couple of articles where an editor added MiszaBot I to the talk pages, for example https://en.wikipedia.org/wiki/Talk:Single-payer_healthcare . The editors at Single payer didn't even want it because it disrupted the discussions.

Now I see that not only was the text removed, but I can't find an archive, and the text is apparently gone. For example, the MiszaBot search box doesn't return anything, and there is no page at https://en.wikipedia.org/wiki/Talk:Single-payer_healthcare/Archive_1 Furthermore, MiszaBot is deactivated https://en.wikipedia.org/wiki/User:MiszaBot_I and the maintainer has been inactive since 2015.

(1) There was a lot of useful information in those archived discussions. Is there any way I or someone can get them back?

(2) Is it possible that Miszabot or some other bot will delete the text that is now on the talk page and lose it in a mistaken attempt to archive it?

I apologize if this is not the right place to ask these questions, but I got here by following the help links. If this isn't the right place, what is? --Nbauman (talk) 23:27, 10 July 2017 (UTC)[reply]

@Nbauman: The history of that page does not show any recent archiving, and MiszaBot hasn't editing in over 5 years. The last bot archive on that page was 2014. Is there a recent problem that you are seeing? Can you provide a diff link or the specific date and time you think the page had a bad edit? — xaosflux Talk 23:32, 10 July 2017 (UTC)[reply]
More info: Look here - the talk archives appear to be under an alternate spelling, feel free to move them to the current title. — xaosflux Talk 23:35, 10 July 2017 (UTC)[reply]
The article and main talk page were moved without moving the archived subpages. I have moved them now. PrimeHunter (talk) 23:39, 10 July 2017 (UTC)[reply]

Creating an account

Is there a way to identify who created an account? I'm dealing with a situation where someone has an account, but they claim they did not create it. I'd like to track down who created it.--S Philbrick(Talk) 02:16, 11 July 2017 (UTC)[reply]

@Sphilbrick: Check the user creation log. User:Musabello was created by another user (me). User:Sphilbrick was created by an unregistered (or not signed in) user. — JJMC89 (T·C) 05:04, 11 July 2017 (UTC)[reply]
This method only works at the wiki where the account was originally created. You may have to look for that wiki at Special:CentralAuth. Special:CentralAuth/Musabello shows a green plus at en.wikipedia.org so it was created here. If the user means they got the password from another person who created the account the normal way without already being logged in to some account then the log cannot show it. PrimeHunter (talk) 09:22, 11 July 2017 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=790089438"