Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Glaisher (talk | contribs) at 16:51, 30 July 2016 (→Unregistered users see old revisions: update dupe). 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.


Syntax highlighting

Is there any way to highlight just a word or regular expression in edit box via User:USERNAME/common.js?--ԱշոտՏՆՂ (talk) 12:02, 17 July 2016 (UTC)[reply]

You can look at this. Ruslik_Zero 13:34, 17 July 2016 (UTC)[reply]
Ruslik, thanks!--ԱշոտՏՆՂ (talk) 22:19, 18 July 2016 (UTC)[reply]
I'm fond of User:Ais523/highlightmyname2.js, but it only works in "Read mode", so I don't think it will do what you want. OTOH, since I started using it, I feel more confident that I'm not overlooking my username (and you can set it to any single string that you want). WhatamIdoing (talk) 07:27, 23 July 2016 (UTC)[reply]
Thank you, dear WhatamIdoing--ԱշոտՏՆՂ (talk) 12:19, 26 July 2016 (UTC)[reply]

New bolding in watchlist

Firefox 47.0.1. Less than an hour ago, my watchlist started bolding unvisited page title links, where previously there was just a subtle color difference and no bolding. I have cleared history and cache and restarted Firefox, don't know what else I could do on my end. Anyone else seeing this? ―Mandruss ☎ 21:19, 21 July 2016 (UTC)[reply]

@Mandruss: Did you recently change any of your gadget settings? Under Gadgets -> Watchlist there is a setting that will "Display pages on your watchlist that have changed since your last visit in bold". Is that checked? If not, check it, save, uncheck, and resave, and see if it fixes it. --Majora (talk) 21:24, 21 July 2016 (UTC)[reply]
Did you recently change any of your gadget settings? No, not in many moons. The option was unchecked, so I did what you suggested. No change. ―Mandruss ☎ 21:26, 21 July 2016 (UTC)[reply]
I'm having the same phenomenon, the same version of Firefox. Nothing changed on my end. But in the last hour or two, the bolding got so bold on the unvisited ones that it's blurry. It's big and thick and very dark and blurry. Only the link title is that way, not the rest of the info on the item. My gadget on Preferences is also not checked. What happened? — Maile (talk) 21:37, 21 July 2016 (UTC)[reply]
It's beginning to look like it might be a Firefox problem. I saw the change around the time that Firefox said it had automatically downloaded 47.0.1, albeit before I restarted Firefox to install it. I don't understand how the download could have introduced the problem, but then I know nothing of the internals. If it's Firefox, I'd expect a 47.0.2 very soon. ―Mandruss ☎ 21:42, 21 July 2016 (UTC)[reply]
I've had Firefox 47.0.1 for a couple of weeks now. By default of any other postings here, it's probably Firefox. But who knows. It's really distracting. And just confirming that I do not have this same problem in I.E. — Maile (talk) 21:48, 21 July 2016 (UTC)[reply]

I assume that the bolding has something to do with the was Firefox handles CSS scripts. I'm not seeing the issue on Chrome so it is probably a problem on their side. I believe you can override it. WP:CUSTOMWATCH has instructions on how to make it bold. I'm guessing you would just replace, "font-weight: bold;" with "font-weight: normal;" --Majora (talk) 21:47, 21 July 2016 (UTC)[reply]

Am seeing the same myself in Chrome, Firefox, IE and Edge. Do not have the option selected in prefs. Have tried selecting it and deselecting it. No difference. Nanonic (talk) 21:49, 21 July 2016 (UTC)[reply]
Not seeing it in Edge or IE, no other browsers to test. ―Mandruss ☎ 21:55, 21 July 2016 (UTC)[reply]
Has now stopped in both my Edge and Chrome but still in IE and FF. Odd! However when I refresh the page in Chrome, I can see it bold the 'unread' entries during page load before putting them back to normal when rendered. Nanonic (talk) 22:00, 21 July 2016 (UTC)[reply]
I've always experienced that in Chrome. I just assumed there was some Javascript at work that took a little longer to load. clpo13(talk) 22:04, 21 July 2016 (UTC)[reply]
I think I've always seen that in Firefox, but the bolding was turned off so quickly that I barely noticed it. So the hypothesis would be that whatever was turning it off is no longer working. No idea what that is, or why it would suddenly stop working. ―Mandruss ☎ 22:19, 21 July 2016 (UTC)[reply]
It's CSS. The MediaWiki software comes with bolding and no builtin option to remove the bold. The English Wikipedia removes bolding in MediaWiki:Gadget-WatchlistBase.css, a gadget enabled by default and saying "(This loads the base style for the watchlist. Please do not disable this option.)" Another gadget MediaWiki:Gadget-WatchlistChangesBold.css can then override the first gadget and make bolding again with "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)". For some reason the first gadget is failing. I tried a dummy edit of MediaWiki:Gadget-WatchlistBase.css with no effect. It works in Firefox 47.0.1 if I load it using withCSS: https://en.wikipedia.org/wiki/Special:Watchlist?withCSS=MediaWiki:Gadget-WatchlistBase.css. But it fails if I just have it enabled in gadgets and disable the bolding gadget. The English Wikipedia got mw:MediaWiki 1.28/wmf.11 three hours ago so something there may have triggered the issue. PrimeHunter (talk) 22:31, 21 July 2016 (UTC)[reply]
(edit conflict) I'm experiencing this problem as well, Firefox 47.0.1 and briefly on Chrome 52. Interestingly enough, I tried Majora's suggestion above regarding the watchlist gadget and the bolding went away, but only in Chrome. Firefox still has it. clpo13(talk) 22:04, 21 July 2016 (UTC)[reply]
I also am seeing the same bolding effect, started in the last hour or two. I am using Iceweasel 24.4.0, and have not recently tweaked any of my settings there or on WP. (Just got a new pair of glasses, but surely that is not a factor.) ~ J. Johnson (JJ) (talk) 23:12, 21 July 2016 (UTC)[reply]
Me too. Started up this afternoon. I thought perhaps I had just loaded the page funny (sometimes clearly caches and what not fixes things like this) but apparently its still happening. I haven't tweaked any of my watchlist settings, and I am not happy about the bolding, although if it helps I have noticed that only pages I haven't directly edited are being bolded on the watchlist, those pages that I have edited and still have the current for are not bolded. Not sure what that means, but I am willing to take it. For the record, I am contributing using Firefox and I am fairly certain its the most recently available one. TomStar81 (Talk) 01:26, 22 July 2016 (UTC)[reply]
Incidentally, I just noticed that its also on the recent changes page for those items I have on my watchlist. Not sure how that happened, but its happened. TomStar81 (Talk) 02:56, 22 July 2016 (UTC)[reply]
The bolding is of watched pages that have been changed since you last visited them. I don't know why MediaWiki:Gadget-WatchlistBase.css fails as a gadget but the bolding can be removed by importing it in your common JavaScript:
importStylesheet('MediaWiki:Gadget-WatchlistBase.css'); // Linkback: [[MediaWiki:Gadget-WatchlistBase.css]]
With this, bolding will be determined by the gadget "Display pages on your watchlist that have changed since your last visit in bold". PrimeHunter (talk) 10:33, 22 July 2016 (UTC)[reply]
@PrimeHunter: Thanks for helping with this, as always. Before deciding whether to fix this locally, I would like to know the prospects for a site fix that would make that unnecessary. Is anyone looking at this? If not, is there a way to get them to, such as phab? ―Mandruss ☎ 10:51, 22 July 2016 (UTC)[reply]
My guess is it will soon be fixed but I don't know where or by whom. I only know what is written here. Many people with CSS and MediaWiki knowledge watch this page, it has only been 14 hours where many users are not active, and so far a problem is only known to exist with a locally made gadget so I wouldn't take it to phab now. PrimeHunter (talk) 11:10, 22 July 2016 (UTC)[reply]
Ok. I'll wait. ―Mandruss ☎ 11:21, 22 July 2016 (UTC)[reply]
It appears that gerrit:288026 has somehow changed the loading order of modules, so the module that applies the default bolding is now loaded after gadgets rather than before. Anomie⚔ 13:14, 23 July 2016 (UTC)[reply]
A short-term workaround would be to increase the specificity of the selectors in the gadget (e.g. make it "html .mw-changeslist-line-watched .mw-title") so it's not relying on ordering to break the tie. Anomie⚔ 13:25, 23 July 2016 (UTC)[reply]
I have limited CSS knowledge but I suggest you do that if you ensure MediaWiki:Gadget-WatchlistChangesBold.css still works for those who do want bolding and have selected it in preferences. PrimeHunter (talk) 19:11, 23 July 2016 (UTC)[reply]
This is still occuring, seems to have stalled in getting a "fix", think we need to this this enwiki local still? — xaosflux Talk 11:18, 26 July 2016 (UTC)[reply]
@Xaosflux: If the suggested fix looks good to you or another admin with CSS knowledge then I suggest trying it. Anomie only has one edit since the suggestion. I'm not qualified to evaluate it. PrimeHunter (talk) 10:54, 27 July 2016 (UTC)[reply]

That dreadful bolding that everyone hates!!!

I see that unreadable bold text in the watchlist is back. How do I get rid of it this time? Checking/unchecking the "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" box, in preferences/gadgets/watchlist, makes no difference.--Ykraps (talk) 18:58, 23 July 2016 (UTC)[reply]

I don't see this bold. Where is the customize button? Millbug talk 19:09, 23 July 2016 (UTC)[reply]
See #New bolding in watchlist. There is a solution for your personal JavaScript and a suggested solution for everybody who is affected. PrimeHunter (talk) 19:14, 23 July 2016 (UTC)[reply]
I'm afraid I don't understand much of that conversation. Do I create User:Ykraps/common.js, then copy this script, "importStylesheet('MediaWiki:Gadget-WatchlistBase.css'); // Linkback: [[MediaWiki:Gadget-WatchlistBase.css]]" to it, and save?--Ykraps (talk) 19:32, 23 July 2016 (UTC)[reply]
Exactly. (Don't copy the nowiki part in the page source). PrimeHunter (talk) 19:35, 23 July 2016 (UTC)[reply]
That seems to have done the trick, thank you.--Ykraps (talk) 21:32, 23 July 2016 (UTC)[reply]

As as side note, I don't understand why people consider the bold "unreadable". In fact I've had the bolding enabled for a while, and it's much easier to spot changes than solely based on the color of a small dot. nyuszika7h (talk) 21:13, 23 July 2016 (UTC)[reply]

Perhaps it's a failing eyesight, getting old thing but in vector skin the type is so blobby the characters are barely distinguishable. With other skins it's not so bad but then the normal type is too small.--Ykraps (talk) 21:32, 23 July 2016 (UTC)[reply]
I use Firefox and MonoBook; I found that with IE (any skin), all characters get smudged. I believe that this smudging is something called anti-aliasing, which some consider a Good Thing. With my eyesight, it's not - I need sharp edges. --Redrose64 (talk) 22:47, 23 July 2016 (UTC)[reply]
I use Firefox and the Vector skin, it looks fine to me. nyuszika7h (talk) 11:12, 24 July 2016 (UTC)[reply]
I use Firefox and Safari in Vector, and it looks good. Perhaps it's a Windows problem? I use a Mac.
Not a Windows thing. I see it on Linux with Firefox. Jason Quinn (talk) 17:23, 28 July 2016 (UTC)[reply]
Despite the assertion that everyone hates the bolding, I happen to like it, and I will go to some trouble to enable it at the few wikis where it's not on by default. WhatamIdoing (talk) 13:50, 27 July 2016 (UTC)[reply]

Got ping hours later and it wasn't supposed to ping

I just got a notification for this edit when I went to Wiktionary, but that was two hours ago and I've already seen that message, plus it wasn't supposed to ping as there was no mention in a new message there (I remember the latter part was raised as an issue here earlier). nyuszika7h (talk) 17:37, 22 July 2016 (UTC)[reply]

And I am still receiving notifications that I have read hours ago when I go to other wikis. nyuszika7h (talk) 11:11, 24 July 2016 (UTC)[reply]
The same happened to me a couple days ago. Maybe it's just database lag... It seems to help to mark them read. —PC-XT+ 02:14, 29 July 2016 (UTC)[reply]

Exact time of registration

I want to thank you again for making that link to a user's commons uploads. It is very handy.

I often have the need to know the exact time of registration. Rather than going to Special:CentralAuth for each user, would this be possible with a script or something:

At a userpage under the username it says "Registered 07/25/2016; 10 edits". It would be great if new users, for the first, say, week or month, could have the time of registration as well, like "Registered 07/25/2016 16:55 (41 minutes ago); 10 edits". Is this possible? Anna Frodesiak (talk) 06:52, 24 July 2016 (UTC)[reply]

@Anna Frodesiak: This script does pretty much all of that if I understand you correctly, and it also shows user rights. Just install it and go to any user/user talk/contributions page and click the icons next to the page title. Omni Flames (talk) 06:59, 24 July 2016 (UTC)[reply]
In case you haven't seen it, at the bottom of a user's contributions is a "User rights" link, and clicking that shows the user's rights and has text "Created on...date/time". Johnuniq (talk) 07:02, 24 July 2016 (UTC)[reply]
Thanks, Johnuniq. I would just love to have it displayed at their userpage without having to click anything. Anna Frodesiak (talk) 08:42, 24 July 2016 (UTC)[reply]

Ping @Mr. Stradivarius: :) Anna is talking about modifying User:MastCell/user-rights.js - NQ (talk) 08:28, 24 July 2016 (UTC)[reply]

Struck through the first sentence. This post was actually intended for our beloved Mr. Stradivarius, but I decided to post it here instead and forgot to remove the first sentence. Anna Frodesiak (talk) 08:36, 24 July 2016 (UTC)[reply]
These scripts really confuse me. If someone would be so kind as to put it wherever it is supposed to go, that would be great. Anna Frodesiak (talk) 08:42, 24 July 2016 (UTC)[reply]
The two linked to above are User:MastCell/user-rights.js and User:Anomie/useridentifier.js. I have no clue what they do or where they go. It's all just symbols and colours to me. Anna Frodesiak (talk) 08:43, 24 July 2016 (UTC)[reply]
For User:Anomie/useridentifier.js, installation instructions are at the top. User:MastCell/user-rights.js doesn't have any, but it does show "Heavily borrowed and lightly adapted from User:Splarka/sysopdectector.js"; and User:Splarka/sysopdectector.js also lacks installation instructions. Notifying MastCell (talk · contribs) and Splarka (talk · contribs), although the latter has edited only once in the last two years. --Redrose64 (talk) 09:44, 24 July 2016 (UTC)[reply]
User:Anna Frodesiak/common.js says:
importScript('User:MastCell/user-rights.js'); // Linkback: [[User:MastCell/user-rights.js]]
That means your account runs User:MastCell/user-rights.js. Requests can be posted to User talk:MastCell. If you want to run User:Anomie/useridentifier.js then place this in your common JavaScript:
importScript('User:Anomie/useridentifier.js'); // Linkback: [[User:Anomie/useridentifier.js]]
Requests can be posted to User talk:Anomie. You can also use the talk pages of the scripts but posts there may not be noticed. PrimeHunter (talk) 09:49, 24 July 2016 (UTC)[reply]

I'm lost here. I don't even know what they do or don't do or how to install these. Could some kind editor please just make "Registered 07/25/2016; 10 edits" become "Registered 07/25/2016 16:55 (41 minutes ago); 10 edits"? I'd be so grateful. Anna Frodesiak (talk) 12:01, 24 July 2016 (UTC)[reply]

Anna Frodesiak you say "at a userpage", do you mean a specific user's page - or any userpage? As far where you are looking, especially for older users the Special:CentralAuth timestamp not be the oringal registration time, the Special:Log/newusers (User creation log) for the user is usually more accurate. — xaosflux Talk 13:24, 24 July 2016 (UTC)[reply]
Anna is using User:MastCell/user-rights.js whichs adds information when you view a user page. The script is made by MastCell so if you want it to display more information like account age in minutes then you can ask for it at User talk:MastCell. The script has not been edited since 2012 and I don't know whether MastCell has interest in changing it. PrimeHunter (talk) 13:35, 24 July 2016 (UTC)[reply]
Hi PrimeHunter. I posted and asked at here. Couldn't I just take that script and ask someone to modify it a bit and stick it in my .js thing-a-me-doodle? Anna Frodesiak (talk) 17:35, 24 July 2016 (UTC)[reply]
Hi Xaosflux. Yes, I mean for all new users when I am at their userpage. I normally have to open a new tab for each at Special:CentralAuth. When I want to look into a bunch of users for an SPI or maybe tagteam vandalism, it would be useful without having to click more tabs. Anna Frodesiak (talk) 17:35, 24 July 2016 (UTC)[reply]
  • Looks like you just need to modify a line a bit:

userRightStr += ("Registered " + (regDateObj.getMonth() + 1) + "/" + regDateObj.getDate() + "/" + regDateObj.getFullYear() + "; becomes: userRightStr += ("Registered " + (regDateObj.getMonth() + 1) + "/" + regDateObj.getDate() + "/" + regDateObj.getFullYear() + " " + regDateObj.getHours() + ":" regDateObj.getMinutes() To get the date from now you can use Date.now() and subtract the regDateObj from that which gets you milliseconds, then divide by 1000*60 to get minutes. II | (t - c) 21:27, 24 July 2016 (UTC)[reply]

You'd also have to change var regDate = user['registration'].split("T")[0]; to var regDate = user['registration'];. Combine this code snippet with User:PleaseStand/userinfo.js and it works as desired. - NQ (talk) 03:45, 25 July 2016 (UTC)[reply]
Thank you, ImperfectlyInformed! Now, of course, I have no clue what all that means, but if it can now be done, that is great. So, would you stick that in the .js doo-dad or wherever, please? I'd be eternally grateful. Anna Frodesiak (talk) 21:38, 24 July 2016 (UTC)[reply]

You are all so nice, and I am sorry to cause such a fuss over all of this. Anna Frodesiak (talk) 21:38, 24 July 2016 (UTC)[reply]

@Anna Frodesiak: Click here and replace the contents of that page with this. - NQ (talk) 03:45, 25 July 2016 (UTC)[reply]
Hi NQ. When I did that, it said "An administrator, 7 years 8 months old, with 99,918 edits. Last edited 15 hours ago. From Wikipedia, the free encyclopedia." Again, I am sorry to cause such a fuss over this. It is not a hugely important thing and I can live with opening the extra tabs. I just thought it would be a teeny tweak to a script or something. Thank you all for trying and I am terribly sorry to have wasted so much community resources over this. Anna Frodesiak (talk) 04:01, 25 July 2016 (UTC)[reply]
@Anna Frodesiak: Yes it shows you how old the account is. (eg. "28 minutes old", "7 years, 8 months old" etc.) If you click on that link, it'll take you to Special:ListUsers which will display the exact registration date and time. Anyway, if you prefer to have the registration info displayed as well, try this : Copy the contents of this page and paste them here. Then click here and replace the contents with this. Let me know how it goes. - NQ (talk) 04:12, 25 July 2016 (UTC)[reply]
It should show up like this for your account or like this for a new user - NQ (talk) 04:20, 25 July 2016 (UTC)[reply]
Really? I must be going blind. Let me try it again. Anna Frodesiak (talk) 04:24, 25 July 2016 (UTC)[reply]
NQ, it works! Fantastic! I must be going bonkers because I didn't even read the above "...Yes it shows you how old the account..." paragraph when I typed "Really". And thank you for the 'replace-this-with-this' presentation. That makes it so easy. I am totally terrified by adding 'code'. I keep thinking it will melt Wikipedia or go all haywire or something. Thank you again! Oh, and if it is super easy, could that line get trimmed or shrunk or both? No real need for "A registered user" or "6 years 6 months old", and "Last edited" could just be "last" and I know it is "From Wikipedia, the free encyclopedia." If that is not a total sinch, don't worry about it. Thank you again! :) Anna Frodesiak (talk) 04:34, 25 July 2016 (UTC)[reply]

 Done! Anna Frodesiak (talk) 06:55, 25 July 2016 (UTC)[reply]

By the way, it's all nice and concise and tiny now, thanks to NQ. Feel free to give it a go. It is here: User:Anna Frodesiak/user-info.js. Anna Frodesiak (talk) 07:43, 25 July 2016 (UTC)[reply]

Lua modules

Why did Wikipedia introduce Lua modules/templates? What is the benefit of them? - NeedAGoodUsername (talk) 15:52, 24 July 2016 (UTC)[reply]

@NeedAGoodUsername: if you're referring to modules such as Module:Reply to, they are used for a wide range of purposes - for example, in the template {{Reply to}} it is invoked to produce a ping notification -- samtar talk or stalk 16:00, 24 July 2016 (UTC)[reply]
One of benefits - it allows to create much more complex "structures" than templates allowed. Also, compare this version with Module:Demography. The code, which creates the table, is only some 10 lines long in Lua (almost everything else there is only for the table definition and style). --Edgars2007 (talk/contribs) 16:46, 24 July 2016 (UTC)[reply]
Right, but doesn't it limit those who don't understand or know Lua? Seeing as people creating their own wikis tend to use templates from Wikipedia (like ambox and infobox) the old code makes it easier for them to customize how the template looks and works than the lua ones. - NeedAGoodUsername (talk) 16:59, 24 July 2016 (UTC)[reply]
Yes it does limit the number of people who can contribute to these modules, but we have plenty of technical editors who are able to. Is there a particular module you're struggling with? -- samtar talk or stalk 17:11, 24 July 2016 (UTC)[reply]

It's more that I'm trying to create my own wiki and using some of the templates used by Wikipedia (like {{Ambox}}, {{infobox}}, etc.) and it's really hard to change or customise them if you don't know Lua as you can't just ask people to go to another site to do changes for them. - NeedAGoodUsername (talk) 18:56, 24 July 2016 (UTC)[reply]

As a programmer Lua is far more accessible and approachable than parser functions which are highly unusual. Further Lua is a much better language. It makes often hard things easy, and many previously impossible things possible. Finally where it makes a difference it’s faster, speeding page load and reducing server load.--JohnBlackburnewordsdeeds 17:28, 24 July 2016 (UTC)[reply]

But isn't the page load speed outweighed to having another thing to process when generating the page? - NeedAGoodUsername (talk) 18:56, 24 July 2016 (UTC)[reply]

They are more functional. They are also much faster to execute on the server, noticeably improving response times for saving and rendering large pages. Dragons flight (talk) 17:19, 24 July 2016 (UTC)[reply]
Many of the templates have reached the stage of being unintelligible to most users. Lua can actually simplify many of these. עוד מישהו Od Mishehu 18:52, 24 July 2016 (UTC)[reply]
Samtar: It is not true that in the template Reply to it is invoked to produce a ping notification. The essential feature of a notification is a link to the user page, like the one at the start of this post: you will have got a notification from me, and I didn't use a single template. --Redrose64 (talk) 18:59, 24 July 2016 (UTC)[reply]
Have you tried looking in the template histories to find pre-Lua versions? There are some templates which were completely replaced, though. I remember some talk of hosting them in a repository or something, somewhere... —PC-XT+ 02:32, 29 July 2016 (UTC)[reply]

Page Information Stats

While I really like and appreciate the new design and layout of the Page information stats, I was hoping someone could explain why there is a column for % of minor edits made by a user, but not a % of major edits, and why there is Text Share column:
Username | Edits | Minor | Minor (%) | First Edit | Last Edit | Text Share. Atsme📞📧 18:30, 24 July 2016 (UTC)[reply]

You refer to the "Revision history statistics" link at the bottom after you click "Page information" in the left pane of an article (not the same tool as "Revision history statistics" in the page history). Example: https://tools.wmflabs.org/xtools/wikihistory/wh.php?page_title=Example. "major edit" is an unofficial term for either all edits which are not marked minor edit by the editor, or edits which are considered major by some subjective evaluation. For the former definition, just subtract minor edits from 100% to get "major" edits. The latter "definition" is not precise enough to compute a percentage. When I load a page with the tool it says "Attention: The data for authorship is loading. Depending on the data and the size of the article, this may take a while. The page does not need to be reloaded. The data will automatically appear." But nothing more happens. It apparently refers to a feature which is supposed to fill out the "Text Share" column. The tool links to de:Benutzer:APPER/WikiHistory/Autorenbestimmung (in German). It talks about the feature but doesn't mention it's broken. PrimeHunter (talk) 21:19, 24 July 2016 (UTC)[reply]
Thank you, PrimeHunter Atsme📞📧 15:18, 26 July 2016 (UTC)[reply]

Tech News: 2016-30

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

Problems

  • Sometimes, the visual editor required saving twice. That problem is now fixed. [2]

Changes this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 July. It will be on non-Wikipedia wikis and some Wikipedias from 27 July. It will be on all wikis from 28 July (calendar).
  • It is now possible to mark all Notifications as read on Special:Notifications, by clicking on the cog icon. [3]
  • Wikipedia search will now detect the language of your search if 2 or fewer results are found. It will then show results from the matching language Wikipedia, if any relevant article exists. It will start to roll out in 5 languages. [4]

Meetings

  • You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 26 July at 19:00 (UTC). See how to join.
  • You can join the next meeting with the Architecture committee. The topic this week is "an extension that implements an authenticated key-value store". The meeting will be on 27 July at 21:00 (UTC). See how to join. [5]

Future changes

  • The current icon for Notifications "Notices" (in English "Notices") will be changed from a bubble-speech icon to a tray icon for consistency. [6]
  • Special:Notifications page code will be changed to be more Mobile friendly. [7]

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

19:54, 25 July 2016 (UTC)

The editing environment appears to have changed, detrimentally

In the past, when beginning to edit a page, the advanced edit options atop the edit window and the special characters/wiki markup underneath were immediately available. As of recently, to my chagrin, I have realized that these options are no longer available until after the page is previewed. Is this a change that was intended? I think it is counterproductive and wish it could be reversed. It literally wastes data having to reload the page in preview just to access these tools. Many users, including me, purchase our internet access by the gig and I do not see a good reason for loading a page superfluously. If there is a good reason, please tell me of it, so I may know. Thank you.--John Cline (talk) 11:52, 26 July 2016 (UTC)[reply]

I checked and I seem to be able to view it just fine without hitting the show preview button. It does take a few seconds to appear though, so maybe try waiting for a moment. --Jakob (talk) aka Jakec 11:57, 26 July 2016 (UTC)[reply]
It is certainly slower than it used to be, and has been for some weeks - it's why I made this edit seven weeks ago. I can live without the buttons at the top, but the box of links (the "charinsert" gadget, defined at MediaWiki:Gadget-charinsert-core.js with MediaWiki:Gadget-charinsert-core.css) is indispensable. This does take time loading, and sometimes never loads at all. --Redrose64 (talk) 12:11, 26 July 2016 (UTC)[reply]
I apologize. My connection is running slow, and I apparently did not wait for the page to fully load in edit mode. It does seem to take longer to load than I recollect of the past, but I can adapt. Best.--John Cline (talk) 12:21, 26 July 2016 (UTC)[reply]
Tracked in Phabricator
Task T54253

Maybe I'm missing something, but could somebody please explain to me why we still encourage Wikipedians to implement PRURL when Wikipedia (or Wikimedia in general) is HTTPS-only and not going back? Are there usage scenarios that I am not thinking about?

Because it seems to me now that Wikipedia is HTTPS-only it makes no difference on a technical level whether we use https://www. or //www.. However, PRURL does seem to irritate or confuse people. I remember when I used to convert links to PRURL, other people complained to me thinking I was destroying a working link due to a software bug, because they hadn't heard of PRURL before.

Long story short, I believe there is no point in using PRURL at all anymore. But, like I said, maybe I'm missing something. --bender235 (talk) 13:46, 26 July 2016 (UTC)[reply]

The only case would be mirrors who can't figure out (somehow) how to implement HTTPS. --Izno (talk) 15:12, 26 July 2016 (UTC)[reply]
Mirrors and forks may still be on http:. This was covered at the RfC --Redrose64 (talk) 15:14, 26 July 2016 (UTC)[reply]
How many pages are we talking about here? Just so to get a perspective on the scale of the problem, and whether it is worth even considering. Just like, for instance, we don't worry about design/display issues from old browsers like IE4 since the amount of people still using them is negligible. --bender235 (talk) 15:32, 26 July 2016 (UTC)[reply]
PS: I am aware of this list, but it seems close to 100% there are dead (my inference from randomly checking 15 links, all dead). --bender235 (talk) 15:36, 26 July 2016 (UTC)[reply]
So http pages are HTTP 301 redirects to the corresponding https pages. The change also had some consequences; in particular, IE6 users on Windows XP can no longer access Wikipedia and IE7 (Windows XP, Windows Vista), IE8 (Windows XP, Windows Vista, Windows 7), IE9 (Windows Vista, Windows 7), and IE10 (Windows 7, Windows 8) users no longer have autocompletion of previous edit summaries and visited Wikipedia pages are no longer stored in the browsing history for those users. GeoffreyT2000 (talk) 16:22, 28 July 2016 (UTC)[reply]

Page movers applying pending changes protection bug?

Observe the 2 pp-pc edits by Cyberbot to this page after a WP:PM/C#4. It seems apparent that pending changes settings don't go away upon deletion (unlike edit prot), and do migrate with page moves (like edit prot). This result is also what Mr. Stradivarius got separately and posted here and here.

While it may be a "feature", I currently believe that page movers can indirectly pending-change protect pages with a set of page moves requiring suppressredirect. Example: suppose A is pending changes protected and suppose I want to pending-change-protect B. Then I can carry out this procedure:

  1. Move A → new location C (with suppressredirect)
  2. Move B → A (with suppressredirect)
  3. Move A → B (with suppressredirect)
  4. Move C → A (with suppressredirect)

I believe the page at title B is now pending changes protected, and I believe a side effect is that the non-existent C is pending changes protected as well. I don't dare test this (complicated cleanup needed by a sysop perhaps), but it's what I believe to be a logical result of pending changes settings not resetting after a deletion (or in this case, redirect suppression). A mitigation is to make it expire like edit protection does, which I'm suggesting here. — Andy W. (talk · ctb) 00:02, 27 July 2016 (UTC)[reply]

Retracting a lot, didn't read the pc1 expiry clearly. It looks like Cyberbot II removed the template just 9 minutes later... but in any case, these two edits are still puzzling. Is Draft:Move/Syrian Civil War pending changes protected despite not existing? Or is it just a replication issue that made Cyberbot II add and remove the template in that time frame? — Andy W. (talk · ctb) 00:22, 27 July 2016 (UTC)[reply]
(Should have done some more observation) Special:Diff/728148235 is also puzzling. Bot bug? Small addition, if a sysop would volunteer testing the steps I crossed out above anyway, just to be sure, that would be nice — Andy W. (talk · ctb) 00:25, 27 July 2016 (UTC) 00:30, 27 July 2016 (UTC)[reply]
Had some more time to ponder, and I have an answer for myself I now think the reason this happened was because the page currently at "Syrian civil war" was briefly at "Syrian Civil War" for technical move reasons, and carried over pending changes prot briefly to the new title. Either Cyberbot II had a slow reaction (twice), or the MW backend had a slow reaction to the second quick move back to "Syrian civil war". (Sorry for some of the strike-out mess here) — Andy W. (talk · ctb) 00:46, 27 July 2016 (UTC)[reply]
This also applies when a page with pending changes enabled was moved with the usual redirect left behind. An example of this is County High School, Leftwich, which I have moved to The County High School, Leftwich back in November 2015 and that redirect had 2 edits by Cyberbot II. GeoffreyT2000 (talk) 05:01, 27 July 2016 (UTC)[reply]

GeoHack

Apologies if this has been asked before, but is there a way to bypass the geohack page when clicking on the GPS coordinates in an article and go directly to the Google satellite view (or another view, if I wanted)? Calidum ¤ 03:08, 27 July 2016 (UTC)[reply]

There's an old user script at mw:GeoHack/Replacement script, but it will need updating (it still references the old toolserver, while geohack is now on Tool Labs) - Evad37 [talk] 16:01, 27 July 2016 (UTC)[reply]
Could you articulate why you want to bypass the GeoHack page? Also whether you are looking to bypass on one or two pages or hundreds/thousands? --User:Ceyockey (talk to me) 22:31, 27 July 2016 (UTC)[reply]
@Calidum: Adding the following to your common.js will bypass GeoHack and take you straight to Google Maps satellite view:
importScript('User:Evad37/GeoHack replacement script.js'); // [[User:Evad37/GeoHack replacement script.js]]
ghrs_mapprovider = "https://maps.google.com/maps?ll={latdegdec},{londegdec}&q={latdegdec},{londegdec}&hl={language}&t=h&z={osmzoom}";
Changing the value of ghrs_mapprovider = will allow you to specify a different mapping provider (you can get urls to use from Template:GeoTemplate).
@Ceyockey: I presume he or she wants to save time by not loading GeoHack and just going straight to the mapping service he or she wants. - Evad37 [talk] 05:32, 28 July 2016 (UTC)[reply]
Thanks, @Evad37: that's exactly what I was looking for. @Ceyockey: I was looking to avoid having to click through the GeoHack page because I find it cumbersome, as Evad said. Calidum ¤ 01:21, 29 July 2016 (UTC)[reply]
Thanks Evad37, like Calidum I always found the geohacks interface to be cumbersome in offering so many options. older ≠ wiser 01:38, 29 July 2016 (UTC)[reply]
Just curious, could something like this be used to create a lightweight version of geohacks? I.e., perhaps a menu with just a few frequently used options? older ≠ wiser 01:52, 29 July 2016 (UTC)[reply]
We already have this, through appropriate setting of the region: parameter. When that is not set, what you get above the fold is a big list of global mapping services, followed by many lists of regional mapping services, as you get by following the coords link at this page; now compare this version, try out the coordinates link - what you should see is that the Great Britain links have moved above the fold, and appear on the right-hand half of the page, and all the non-global non-Great Britain services have been removed. Where a GeoHack page has two halves like that, I ignore the left-hand (Global services) half; if it doesn't, I add a suitable region:. --Redrose64 (talk) 08:45, 29 July 2016 (UTC)[reply]
@older ≠ wiser: Yes, I made an alternate script User:Evad37/GeoHack_replacement_script.js that will load a /GeoHack user subpage. You can format that page however you like, with whatever links you like (as I mentioned above, urls to use can be found at Template:GeoTemplate). - Evad37 [talk] 08:53, 29 July 2016 (UTC)[reply]

Is echo putting the notifications under the wrong bubble?

If I'm not mistaken, mentions and new talk page messages, currently share a similar icon of blue dialog bubbles, yet they get placed under the alert box that turns red, instead of the new messages box that turns blue, which also has the dialog bubbles as the icon. Conversely, all new alerts show up under the new messages box. It's very misleading as it makes me think I got a new message, instead of something else.—cyberpowerChat:Online 08:55, 27 July 2016 (UTC)[reply]

Some kinds of notification were recently moved from red to blue or vice versa, see previous threads e.g. Wikipedia:Village pump (technical)/Archive 147#Notification issue. The idea is that all the "you may need to action this now" ones (which may be messages on user talk) go under red, whereas the "you can ignore this one until next week" ones (like thanks) go under blue. --Redrose64 (talk) 09:22, 27 July 2016 (UTC)[reply]
Can't they at least move the icons too? The red one has a bell which I consider non-important alerts, while the blue has the messages icon which indeed do consider important.—cyberpowerChat:Online 11:33, 27 July 2016 (UTC)[reply]
Ya it's happening with me too. — VarunFEB2003 I am Offline 13:59, 27 July 2016 (UTC)[reply]
I hear that one of the icons is changing soon, possibly to something that looks like an inbox tray. Whatamidoing (WMF) (talk) 14:03, 27 July 2016 (UTC)[reply]
That's right, we're changing both the icon for the non-urgent (blue) category (from "speech bubbles" to a "tray"), and the appearance of the notification badges generally. See this Phabricator task for details. This change will hopefully (if we don't find any more bugs in it) be live on beta labs for testing later today, and live here on English Wikipedia on Thursday August 4th. --Roan Kattouw (WMF) (talk) 21:17, 29 July 2016 (UTC)[reply]
Sidenote, just for anyone else's interest/fascination. Part of the delay with rolling this more accessible design and icon-change out, has been getting it to work well with some languages that use non-Arabic numerals. If you haven't encountered these before, see examples in the ToC at bn:বাংলা ভাষা and lo:ພາສາລາວ, and links to more here). I find this intriguing, and some other Wikimedians probably will, too. :) Quiddity (WMF) (talk) 21:43, 29 July 2016 (UTC)[reply]

User:MarkS/Extra edit buttons

This is an extremely awesome feature offered via a script but it is no longer functional and is not working even with the browsers and skins most preferred. Can a new version of this script be developed or someone fix whatever issues this has. I really want to use it but 'am unable to. Thanks — VarunFEB2003 I am Offline 11:58, 27 July 2016 (UTC)[reply]

Have you tried User talk:MarkS/Extra edit buttons#Alternative way to add buttons and m:User:Krinkle/Scripts/InsertWikiEditorButton? Helder 20:49, 27 July 2016 (UTC)[reply]

Addition of rollbacker right unlogged

The user rights log for Steven Crossin says that the group membership for that user was changed from "rollbacker" to "rollbacker and account creator" on 10 May 2008, but the addition of the rollbacker right is neither logged there nor at meta. GeoffreyT2000 (talk) 21:38, 27 July 2016 (UTC)[reply]

There are several renames involved and a log entry from February 2008 [8] apparently didn't move at the first renaming after that. PrimeHunter (talk) 22:09, 27 July 2016 (UTC)[reply]

SyntaxHighlight problem

I have a problem with {{syntaxhighlight|lang=xml}} What I'd like to get (with appropriate highlighting) is: 


<CopyFiles>
    <Source>C:\SourceFiles\SourceFile1.txt</Source>
    <Dest>C:\DestFiles\DestFile1.txt</Dest>
</CopyFiles>

What I actually get is: 

<CopyFiles>
    '"`UNIQ--Source-00000025-QINU`"'
    <Dest>C:\DestFiles\DestFile1.txt</Dest>
</CopyFiles>

If it doesn't show up above, the "<Source>" element is appearing as [single-quote][double-quote][backtick]UNIQ---Source-0000007-QINU[backtick][double-quote][single-quote]. I'm using Monobook on IE11. Any help would be most appreciated. Tevildo (talk) 16:32, 28 July 2016 (UTC)[reply]

@Tevildo: I suspect it's choking on the "nested" tags, since <source> is actually an alias for <syntaxhighlight>. The "UNIQ" garbage is internal MediaWiki parser stuff. Try this:
<CopyFiles>
    <Source>C:\SourceFiles\SourceFile1.txt</Source>
    <Dest>C:\DestFiles\DestFile1.txt</Dest>
</CopyFiles>
— Earwig talk 17:24, 28 July 2016 (UTC)[reply]
That seems OK, thanks. Tevildo (talk) 21:45, 28 July 2016 (UTC)[reply]

Commonist appears to have died

Yes this is not the page to ask- but it is the page where I can talk to the technical elite. Commons has been announcing for weeks that it switching off its http service and moving to https. Well it has. On doing an upload we get a message HTTP/1.1 403 Insure Request Forbidden- use HTTPS.

Does anyone know which file has to be hacked to change a target server address (or whatever). Where do I find it on Linux Mint 17.1 box? I am looking to do a switch to Vicuna- but a few extra Java Netbeans programmers helping out on GitHub would speed the progress over there, there have been losses as well as gains particularly in the User input skin.

Back to Commonist it must be easy to add HTTPS-Commons as a new wiki so we can back to business as usual. Comments and suggestions please- or just a little bit of magic.--ClemRutter (talk) 20:03, 28 July 2016 (UTC)[reply]

For the record, this is about the upload tool at commons:Commons:Commonist. I haven't tried it but are you sure you are using the current version? PrimeHunter (talk) 23:05, 28 July 2016 (UTC)[reply]
Version 0.4.28- (could be the issue) checking there appears to be movement at github #Mediawiki-api-announce Insecure (non-HTTPS) API Requests to become unsupported starting 2016-06-12. Following the links it appears that detail is stored in wikis.txt which is missing in my version.--ClemRutter (talk) 00:03, 29 July 2016 (UTC)[reply]
0.4.28 is from 22 May 2011.[9] No wonder it doesn't work. Get the current version at commons:Commons:Commonist#Download and install the Commonist. PrimeHunter (talk) 00:22, 29 July 2016 (UTC)[reply]
I am still in shock that five year code was working perfectly until last month! Still I will have a poke around and see what else is happening. My first attempt at using the webstart link on [10] died with the error message
-: image_wikimedia_commons.bpp unknown error: access denied ("java.lang.RuntimePermission","accessDeclaredMembers") so there is still some work to do. ClemRutter (talk) 10:07, 29 July 2016 (UTC)[reply]

New "basic" usergroup?

Resolved - was a software bug. — xaosflux Talk 13:41, 30 July 2016 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Is anyone else seeing a new empty "basic" usergroup at Special:ListGroupRights? [11] Was this the result of a phab ticket? — Andy W. (talk · ctb) 22:05, 28 July 2016 (UTC)[reply]

@Andy M. Wang: Yes I see it. And it is not just on enwiki but on meta and on commons as well. Which probably means it was a global rollout. It doesn't look like sysops have the ability to assign it though so not entirely sure what the purpose is. The only permission assigned to the group is the ability to bypass tor blocks. Seems like a duplicate of IPBE to me. --Majora (talk) 22:32, 28 July 2016 (UTC)[reply]
I cannot make sense of it. uselang=qqx says the name "basic" is made by MediaWiki:Group-basic but there is no such message. No group is listed as able to add or remove the basic group at Special:ListGroupRights. Special:UserRights/Example (admin only) lists it under "Groups you cannot change" in my admin account. But I can change IP block exemptions, a group which includes the only right by basic: torunblocked. I suspect basic is a bug or incomplete feature. PrimeHunter (talk) 22:39, 28 July 2016 (UTC)[reply]
Don't see any phab requests, I asked on [Wikitech-l], awaiting response. — xaosflux Talk 01:11, 29 July 2016 (UTC)[reply]
Hi all. Yes, as I just wrote on wikitech-l, this would appear to be a mistake. Some configuration code was being moved to a new system and a GrantPermissions line for 'basic' to have torunblocked was added under GroupPermissions in the new file instead of GrantPermissions. I'll see if I can get it fixed - thanks for pointing it out. --Alex Monk (WMF) (talk) 01:48, 29 July 2016 (UTC)[reply]
Mystery solved, thank you for the speedy response Alex Monk (WMF). — xaosflux Talk 01:52, 29 July 2016 (UTC)[reply]
Another developer merged and deployed my fix to the servers at 04:04 this morning. --Alex Monk (WMF) (talk) 17:29, 29 July 2016 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Commons.css: Tables in route diagram templates

If anyone cares (I'm following the instructions at the top of the page), I've opened a discussion at MediaWiki talk:Common.css regarding display issues in {{Routemap}} in the Minerva (mobile) skin. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 11:00, 29 July 2016 (UTC)[reply]

Unregistered users see old revisions

Tracked in Phabricator
Task T141687

I have seen three reports today that unregistered users are seeing old revisions of pages. I examined it and it's true for many pages which have been edited since yesterday. It is not about browser caching. Reloading the pages doesn't help. They have to be purged to force the current revision to unregistered users. I tested random pages at Special:RecentChanges. For the majority, the time at "This page was last modified" at the bottom shows that the current revision is not being served. At Wikipedia:Help desk I currently see 18:30, 28 July 2016 when logged out. There are 30 revisions since then. I always see the current revision when logged in. I'm in Denmark and using a desktop browser. PrimeHunter (talk) 19:13, 29 July 2016 (UTC)[reply]

I've gotten the same experience logged out about 3-4 hours ago. — Andy W. (talk · ctb) 19:28, 29 July 2016 (UTC)[reply]
Unregistered users have always been served cached versions as opposed to logged-in users. Ruslik_Zero 19:53, 29 July 2016 (UTC)[reply]
Yes, cached versions for performance reasons but usually not old page revisions as far as I know, at least not in a majority of the cases. I don't think the multiple reports today is a coincidence. PrimeHunter (talk) 20:05, 29 July 2016 (UTC)[reply]
I had the same experience a few hours ago when not logged in. It was disconcerting to not see a post I had made earlier on a ref desk and a reply to it. The post and reply appeared immediately after I logged in. Akld guy (talk) 20:55, 29 July 2016 (UTC)[reply]
Cross-referencing from Help desk: https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Why_No_Text_In_Article.3F I can only link to this section when logged on. Richard Nowell (talk) 13:27, 30 July 2016 (UTC)[reply]
I don't know whether this is related but seems like it might be. I'm an OTRS agent trying to answer questions that are emailed to Wikimedia. Every so often I get a message about not seeing the most recent version of the page but it is usually a one off email. A day or two ago I fielded three such emails in the same day, one of which claimed that purging didn't resolve it. As a possible aside they noted that the material look different in the mobile version compared to the desktop version. I just wonder if there was some issue keeping the database caught up.--S Philbrick(Talk) 15:13, 30 July 2016 (UTC)[reply]
I've reported this on Phabricator as it does look like there is an increase in these occurences: phab:T141693. --Glaisher (talk) 16:50, 30 July 2016 (UTC)[reply]

Issue: Book creator, special page - missing from list on '"Special pages"

Greetings, Today while updating Tip of the day for July 29 I noticed that Book creator is not on Special pages. Wondering if an expert could please add. Thanks! — JoeHebda • (talk) 19:28, 29 July 2016 (UTC)[reply]

I guess you mean Special:SpecialPages which is linked on "Special pages" under "Tools". Many special pages are omitted there but Special:SpecialPages#Page tools starts with Book for me. It links to Special:Book which is the Book Creator. We could change the text to "Book Creator" in MediaWiki:Coll-collection but "Book" is the name of the special page and seems OK to me. PrimeHunter (talk) 20:00, 29 July 2016 (UTC)[reply]

30 months ago, I complained that when I entered "Brolin" in Wikipedia search, instead of being shown a list of search results, I was taken straight to this page: http://en.wikipedia.org/wiki/Brolin Today, the same thing is still happening!

This seems to be a serious flaw in Wikipedia. "Search" does not mean "Redirect me to a page that matches the search term."

If I google "Brolin" the first page of results shows 3 Wikipedia pages, including the one I was looking for. Wikipedia search, meanwhile, seems more like Google's "I'm feeling lucky" option, although I think most people would feel pretty unlucky if Google sent them to a page about Famotidine...

What went wrong with Wikipedia search? And when will this problem finally be addressed?? Dadge (talk) 13:07, 30 July 2016 (UTC)[reply]

This is a deliberate feature. The top right of search pages have a "Help" link going to Help:Searching. The lead shows three ways to make a search instead of going to directly to a perfect match. Registered users can choose three alternative skins at Special:Preferences#mw-prefsection-rendering. All three have both a "Go" and "Search" button. The current default Vector skin doesn't use buttons at the search box but relies on other methods. PrimeHunter (talk) 14:26, 30 July 2016 (UTC)[reply]
@Dadge: The old discussion is at Wikipedia:Village pump (technical)/Archive 123#"Search". PrimeHunter (talk) 14:43, 30 July 2016 (UTC)[reply]
@Dadge:While it is mentioned at the link, I'll add that I'm often in a position of not wanting the Search box to take me directly to the article (that said, I often do so I'm happy that it is the default approach). Whenever I want to do a search but do not want to be automatically brought to an article that might match my search string, I simply click on the magnifying glass. That brings up a search page which I believe works exactly the way you wanted to work.--S Philbrick(Talk) 15:09, 30 July 2016 (UTC)[reply]

Why is this article showing an old version when I'm logged out?

Hi

I'm wondering why the article 3DBenchy is showing an old version of the article when I'm logged out, I've tried it on several computers and they all give the same results so its not my cache.

Thanks

--John Cummings (talk) 16:28, 30 July 2016 (UTC)[reply]

This is the same problem as above. —  crh 23  (Talk) 16:31, 30 July 2016 (UTC)[reply]
Ah, thanks Crh23 I've been told that if I add ?=purge to the end of the article URL it will fix it, and it does :) --John Cummings (talk) 16:32, 30 July 2016 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=732247981"