Hosta

Centralized discussion
Proposals: policy	other	Discussions	Ideas
An RfC to permit trusted non-admins to close TFD discussions with uncontroversial delete outcomes A proposal to forbid IPs from participating in the RfA process. A proposal to elevate WP:BRD to guideline status An RfC on "edit in Wikidata" links, for templates using Wikidata A proposal to add an edit restriction function to Wikipedia. Note: inactive discussions, closed or not, should be archived.
archive talk history watch

Table cell contents spilling over.

When viewing the following table in the mobile version of the site, some text from the first column spills over into the adjacent cell of the second column.

Team	Constructor	Chassis	Power unit	Tyre	No.	Drivers
Scuderia Ferrari	Ferrari	SF15-T[1]	Ferrari	P	5 7	Sebastian Vettel Kimi Räikkönen
Sahara Force India F1 Team	Force India-Mercedes	VJM08[2]	Mercedes PU106B Hybrid	P	11 27	Sergio Pérez Nico Hülkenberg
Lotus F1 Team	Lotus-Mercedes	E23 Hybrid[3]	Mercedes PU106B Hybrid	P	8 13	Romain Grosjean Pastor Maldonado
Manor Marussia F1 Team[4]	Marussia-Ferrari	TBA	Ferrari 059/3[5][6]	P	TBA TBA	Will Stevens TBA
McLaren Honda	McLaren-Honda	MP4-30[7]	Honda RA615H Hybrid	P	14 22	Fernando Alonso Jenson Button
Mercedes AMG Petronas F1 Team	Mercedes	F1 W06 Hybrid[8]	Mercedes PU106B Hybrid	P	6 44	Nico Rosberg Lewis Hamilton
Infiniti Red Bull Racing	Red Bull-Renault	RB11[9]	Renault Energy F1-2015	P	3 26	Daniel Ricciardo Daniil Kvyat
Sauber F1 Team	Sauber-Ferrari	C34[10]	Ferrari	P	9 12	Marcus Ericsson Felipe Nasr
Scuderia Toro Rosso	Toro Rosso-Renault	STR10[11]	Renault Energy F1-2015	P	33 55	Max Verstappen Carlos Sainz Jr.
Williams Martini Racing	Williams-Mercedes	FW37[12]	Mercedes PU106B Hybrid	P	19 77	Felipe Massa Valtteri Bottas
Source:[13][4][14][15][16]

Anyone got an idea what's causing this and/or how to solve this. Tvx1 22:24, 28 February 2015 (UTC)

I don't have a mobile device and it looks right for me in both desktop and https://en.m.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&mobileaction=toggle_view_mobile. The table has a coding error in {{nowrap|{{nowrap|Mercedes PU106B Hybrid}} which should only have one {{nowrap}}. Does it help to remove that:

Team	Constructor	Chassis	Power unit	Tyre	No.	Drivers
Scuderia Ferrari	Ferrari	SF15-T[17]	Ferrari	P	5 7	Sebastian Vettel Kimi Räikkönen
Sahara Force India F1 Team	Force India-Mercedes	VJM08[18]	Mercedes PU106B Hybrid	P	11 27	Sergio Pérez Nico Hülkenberg
Lotus F1 Team	Lotus-Mercedes	E23 Hybrid[19]	Mercedes PU106B Hybrid	P	8 13	Romain Grosjean Pastor Maldonado
Manor Marussia F1 Team[4]	Marussia-Ferrari	TBA	Ferrari 059/3[5][6]	P	TBA TBA	Will Stevens TBA
McLaren Honda	McLaren-Honda	MP4-30[20]	Honda RA615H Hybrid	P	14 22	Fernando Alonso Jenson Button
Mercedes AMG Petronas F1 Team	Mercedes	F1 W06 Hybrid[21]	Mercedes PU106B Hybrid	P	6 44	Nico Rosberg Lewis Hamilton
Infiniti Red Bull Racing	Red Bull-Renault	RB11[22]	Renault Energy F1-2015	P	3 26	Daniel Ricciardo Daniil Kvyat
Sauber F1 Team	Sauber-Ferrari	C34[23]	Ferrari	P	9 12	Marcus Ericsson Felipe Nasr
Scuderia Toro Rosso	Toro Rosso-Renault	STR10[24]	Renault Energy F1-2015	P	33 55	Max Verstappen Carlos Sainz Jr.
Williams Martini Racing	Williams-Mercedes	FW37[25]	Mercedes PU106B Hybrid	P	19 77	Felipe Massa Valtteri Bottas
Source:[13][4][14][15][26]

Does it help to remove all nowrap (may be controversial in an article), or for simplicity replace them by {{identity}} as here:

Team	Constructor	Chassis	Power unit	Tyre	No.	Drivers
Scuderia Ferrari	Ferrari	SF15-T[27]	Ferrari	P	5 7	Sebastian Vettel Kimi Räikkönen
Sahara Force India F1 Team	Force India-Mercedes	VJM08[28]	Mercedes PU106B Hybrid	P	11 27	Sergio Pérez Nico Hülkenberg
Lotus F1 Team	Lotus-Mercedes	E23 Hybrid[29]	Mercedes PU106B Hybrid	P	8 13	Romain Grosjean Pastor Maldonado
Manor Marussia F1 Team[4]	Marussia-Ferrari	TBA	Ferrari 059/3[5][6]	P	TBA TBA	Will Stevens TBA
McLaren Honda	McLaren-Honda	MP4-30[30]	Honda RA615H Hybrid	P	14 22	Fernando Alonso Jenson Button
Mercedes AMG Petronas F1 Team	Mercedes	F1 W06 Hybrid[31]	Mercedes PU106B Hybrid	P	6 44	Nico Rosberg Lewis Hamilton
Infiniti Red Bull Racing	Red Bull-Renault	RB11[32]	Renault Energy F1-2015	P	3 26	Daniel Ricciardo Daniil Kvyat
Sauber F1 Team	Sauber-Ferrari	C34[33]	Ferrari	P	9 12	Marcus Ericsson Felipe Nasr
Scuderia Toro Rosso	Toro Rosso-Renault	STR10[34]	Renault Energy F1-2015	P	33 55	Max Verstappen Carlos Sainz Jr.
Williams Martini Racing	Williams-Mercedes	FW37[35]	Mercedes PU106B Hybrid	P	19 77	Felipe Massa Valtteri Bottas
Source:[13][4][14][15][36]

PrimeHunter (talk) 04:56, 1 March 2015 (UTC)

Thanks for mentioning that coding error. That didn't cause the problem however. Actually it did not do any harm at all. If you click on the link to the mobile view and then reduce the width of your browser screen to the minimum you will see the text from the first column spilling over. Using the identity template doesn't solve it. Tvx1 05:38, 1 March 2015 (UTC)

I already tried the minimum width on mobile and it works for me. I get a horizontal scroll bar and no overlap. I will stop guessing. It's too hard when I don't have the problem. PrimeHunter (talk) 05:51, 1 March 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Since I'm not able to explain the issue with text, I have made a screenshot:

As you can see, content from the first column is spilling over into the second. Tvx1 21:20, 16 March 2015 (UTC)

It doesn't spill over for me. Based on the amount of spillover in your screenshot, maybe your browser doesn't reserve space for the flag icon when the column width is calculated. PrimeHunter (talk) 00:05, 20 March 2015 (UTC)

Multiple user have reported this to me though, regardless of which browser they use. Tvx1 06:54, 21 March 2015 (UTC)

I think you're spot on there. Either the flag icon isn't taken into account, either it's just counted as a 1px character. Is there a way to solve this? Tvx1 19:07, 26 March 2015 (UTC)

Does it change anything if the size of the image is increased, or removed altogether? Googol30 (talk) 04:06, 27 March 2015 (UTC)

Well, cells without flagicons don't spill over into other, no matter how wide they are. But we want to have them in that table. Tvx1 10:13, 28 March 2015 (UTC)

And does making the icons larger make the problem worse? What I'm trying to determine is how the browser is interpreting what it's given and why it isn't making the cells large enough. If the browser isn't making sufficient space for all of the elements the cell contains, should we worry about that, since it's then the fault of the browser, or find a workaround and try to fix the problem on our end, even if the mobile browser isn't working as expected? I didn't seem to catch what your mobile browser even is. If I could replicate the problem on my end, I could attempt to fix it, but the desktop version of Chrome I'm running handles element widths as expected. Let me add a table with the changes I'm thinking of for illustration:

Team	Constructor	Chassis	Power unit	Tyre	No.	Drivers
Scuderia Ferrari	Ferrari	SF15-T[37]	Ferrari	P	5 7	Sebastian Vettel Kimi Räikkönen
Sahara Force India F1 Team	Force India-Mercedes	VJM08[38]	Mercedes PU106B Hybrid	P	11 27	Sergio Pérez Nico Hülkenberg
Lotus F1 Team	Lotus-Mercedes	E23 Hybrid[39]	Mercedes PU106B Hybrid	P	8 13	Romain Grosjean Pastor Maldonado
Manor Marussia F1 Team[4]	Marussia-Ferrari	TBA	Ferrari 059/3[5][6]	P	TBA TBA	Will Stevens TBA
McLaren Honda	McLaren-Honda	MP4-30[40]	Honda RA615H Hybrid	P	14 22	Fernando Alonso Jenson Button
Mercedes AMG Petronas F1 Team	Mercedes	F1 W06 Hybrid[41]	Mercedes PU106B Hybrid	P	6 44	Nico Rosberg Lewis Hamilton
Infiniti Red Bull Racing	Red Bull-Renault	RB11[42]	Renault Energy F1-2015	P	3 26	Daniel Ricciardo Daniil Kvyat
Sauber F1 Team	Sauber-Ferrari	C34[43]	Ferrari	P	9 12	Marcus Ericsson Felipe Nasr
Scuderia Toro Rosso	Toro Rosso-Renault	STR10[44]	Renault Energy F1-2015	P	33 55	Max Verstappen Carlos Sainz Jr.
Williams Martini Racing	Williams-Mercedes	FW37[45]	Mercedes PU106B Hybrid	P	19 77	Felipe Massa Valtteri Bottas
Source:[13][4][14][15][46]

Of course, this is an extreme size change, but it's to troubleshoot things here. Does this make the problem worse, fix it, or make no difference whatsoever? Googol30 (talk) 23:42, 28 March 2015 (UTC)

Googol30, that makes the problem much worse. Here is a screenshot:

In case I hadn't made it clear yet, this is an issue that only occurs on the mobile version of the site. The only mobile browser I have thus far identified not to be affected by this issue is Firefox. All other mobile browser have this problem. I mostly use mobile Safari, but as said other mobile browsers are affected as well. Tvx1 00:37, 29 March 2015 (UTC)

Googol30, does my above reply hold any value for you regarding this issue? Tvx1 13:25, 30 April 2015 (UTC)

@Tvx1: yes, and I've done some research into the problem, finding that this is actually intended behavior of the nowrap attribute. Sadly, I do not have enough technical knowledge of its use within MediaWiki or on Wikipedia to properly fix this issue, so I regret to inform you that although (I think) I know what is causing the problem, I cannot properly fix it without potentially causing more problems elsewhere. Googol30 (talk) 11:04, 4 May 2015 (UTC)

And do you know anyone who could be able to fix it, or do you think it would be better to file a bug report over on Phabricator? Tvx1 15:55, 4 May 2015 (UTC)

I'd say, if you haven't already, to file a report on Phabricator, possibly linking to there from here to give anyone looking for the problem here a place to continue searching.Googol30 (talk) 20:09, 10 May 2015 (UTC)

Done Tvx1 13:08, 16 May 2015 (UTC)

"Loss of session data" error on Save page

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.

For months, I guess, I've been getting this on about one in ten saves. The second attempt always works, so it's not a serious hindrance, but it's definitely annoying, distracting, and a bit nerve-rattling, especially in addition to the other weird editing glitches we've seen lately.

A look at this page's archives shows other users having the problem, going back years, but I don't see a clear resolution there.

I have Firefox 38.0.1 on Windows 7. I'm using the NoScript 2.6.9.26 Firefox extension, but these WP-related sites are whitelisted: wikipedia.org, wikimedia.org, wmflabs.org, wmfusercontent.org. I also have the Adblock Plus 2.6.9.1 extension.

A resolution would be worth a demonstration of WikiLove, if you're into that sort of thing. ―Mandruss ☎ 06:02, 8 June 2015 (UTC)

I don't get them nearly as often as you but this happened to me twice today. Firefox. --NeilN ^{talk to me} 06:14, 8 June 2015 (UTC)

(edit conflict) A few times today already, I'll get the loss of session data error after taking a mere five seconds to make a correction to an article when I used to have to wait at least a few minutes with the edit window open before saving for that to happen. Luckily, I just need to press save again to fix the problem. Dustin (talk) 06:15, 8 June 2015 (UTC)

Also, this is on Google Chrome. Dustin (talk) 06:15, 8 June 2015 (UTC)

If someone could say that they have the problem without one or both of the Firefox extensions (or the Chrome version), that would rule them out as the culprit. ―Mandruss ☎ 06:23, 8 June 2015 (UTC)

This happens to me, and I have both of these extensions installed (but disabled for these domains). However, it doesn't happen to me nearly as often. Usually, I have to have an editing window open for ≥15 minutes to get this error. WhatamIdoing (talk) 06:28, 8 June 2015 (UTC)

It's possible it's far less than one in ten for me. I of course notice when the error happens, but I'm not aware of how many saves have worked since the previous error; I'm not paying attention to that. I could start keeping a record, but I don't know that a more accurate number would help identify the problem. ―Mandruss ☎ 08:55, 8 June 2015 (UTC)

I don't have either of these extensions. --NeilN ^{talk to me} 06:32, 8 June 2015 (UTC)

I think I see it more for edits that have been open for awhile, but I'm certain it happens sometimes after a ~30-second edit session. ―Mandruss ☎ 06:59, 8 June 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘"Please try again" suggests that the developers anticipated the possibility of "loss of session data", and were unable to come up with a way to prevent that possibility. The career software developers among us can attest that such situations are possible, although rare. Some aspects of the software environment are beyond our control, and the rare nut is uncrackable. But it would be nice to have the developers look at the problem and say whether that is the case here. If it is, that would be a good thing to know going forward. ―Mandruss ☎ 07:52, 8 June 2015 (UTC)

Firefox 38.0.5 and some earlier versions. I don't have eother NoScript or AdBlock. I've not counted the rate at which the "Loss of session data" error occurs, but it's more likely for a longer interval between "edit" and "save page". But it has happened for a simple sub-10-second typo fix on more than one occasion. --Redrose64 (talk) 08:14, 8 June 2015 (UTC)

It suddenly became far more frequent about 10 days ago - and most of my edits are just typos (Windows 7, IE11, Vector & no fancy add-ons) - Arjayay (talk) 09:04, 8 June 2015 (UTC)

This edit took no more than ten seconds from clicking "[edit]" to Save page, during which time I did not navigate off the page, switch windows or do anything other than type - yet it still threw "Sorry! We could not process your edit due to a loss of session data." Ridiculous. --Redrose64 (talk) 12:48, 10 June 2015 (UTC)

I have strong suspicions that this is related to #Post_not_showing_up_immediately. I suspect the same change that is causing that problem (still not tracked down btw), is also causing this problem. Possibly because outdated tokens or timestamps are included in edit pages or something. —TheDJ (talk • contribs) 12:58, 10 June 2015 (UTC)

For me, the "session data" issue pre-dated the other by at least months — maybe many months, I can't recall. ―Mandruss ☎ 16:59, 11 June 2015 (UTC)

• Is this related? When these errors start happening, I typically also get "token" errors when I use the Upload Wizard. (If my memory is correct, the message is "token not recognized".) In this case, all my work is completely lost, and I have to restart the upload from scratch. Browser back buttons work just fine with loss of session data, but not with these token failures. I presume this is simply because Uploading doesn't come with a Preview button, so my browser when I upload never has a record of what I just did. I also presume I could avoid problems if I got in the habit of right-clicking the Upload button. I also presume that the simplest temporary fix would be that when the Upload button is activated, the page as it is also added to the browser history. Choor monster (talk) 13:08, 10 June 2015 (UTC)

• It happened again. Error message was "Invalid token". I was left looking at File:John Cromwell Bell, portrait by Julian Russell Story.jpg, with the statement "No file by this name exists, but you can upload it." and a Create tab at the top. Choor monster (talk) 17:25, 11 June 2015 (UTC)

Loss of Session Data

About once a day, I try to make an edit, and get the error message that my edit could not be made due to a loss of session data. It tells me to try again, and says that if that does not work, I should log out and log back in. I press the Save button again, and it works. (I don't have to log out and log in.) Should I just ignore it, or can I do something to minimize the frequency of these glitches? Robert McClenon (talk) 15:23, 10 June 2015 (UTC)

I am using Google Chrome 43.0.2357.124 and Windows 7. Robert McClenon (talk) 15:25, 10 June 2015 (UTC)

I'm occasionally getting these too. It seems that this message is most likely to occur when I start editing an article and keep it open in the edit mode for a long time (over an hour). For me, too, the message goes away after pressing Save. I'd also be interested in knowing the cause of this message and whether it can be prevented. (I'm using Firefox 22.0 on Win7).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 10, 2015; 15:29 (UTC)

It happens for me when I haven't been editing very long. Since we are using different web browsers, they might be different issues. Robert McClenon (talk) 15:53, 11 June 2015 (UTC)

It happens for a variety of browsers. It also happens for very short editing sessions. --Redrose64 (talk) 16:34, 11 June 2015 (UTC)

Have the exact same issue and configuration as Robert McClenon.--Wolbo (talk) 17:04, 11 June 2015 (UTC)

• I was coming here to complain myself. I'm getting this 70% of the time now. It's becoming more than just an annoyance. Also some pages when edited load out of date and need to be refreshed. There are some weird glitches going on right now.—^cyberpower_Chat:Online 18:25, 11 June 2015 (UTC)
• Noting that I too have had this happening with increasing frequency, about every third edit today, and it has also occurred when accessing restricted pages (in my case, the checkuser interface). Using Win7 with FF38.0.5. I have noted this on the current phab report. Risker (talk) 23:08, 14 June 2015 (UTC)

Impending bot armageddon

Hidden in the link at the end of today's Tech News is a bit of a bombshell. For people who didn't notice, most of our bots are going to stop working on 2 July if their code isn't updated.

According to the announcement, the following bots need to be fixed. (I've restricted the list to bots active on this wiki.)

• User:AAlertBot
• User:Acebot
• User:ClueBot III
• User:ClueBot NG
• User:CorenSearchBot
• User:Cyberbot I
• User:Cyberbot II
• User:DeltaQuadBot
• User:Dexbot
• User:ErfgoedBot
• User:HasteurBot
• User:Invadibot
• User:Legobot
• User:Lowercase sigmabot III
• User:Merge bot
• User:RMCD bot
• User:SineBot
• User:SvickBOT
• User:Theo's Little Bot
• User:Xqbot

We are reliant on quite a few of those bots for the smooth functioning of our wiki, so it's very important that they are fixed. Also, as TheDJ says above, there are also a number of user scripts that need fixing as well.

I've started a list of users to notify about this at User:Mr. Stradivarius/API continuation/users to notify, and a message to send to them at User:Mr. Stradivarius/API continuation/message. It would be very helpful if people could help me to expand the list to include user scripts, and to help copy edit the message. Once that's done, we can send it out using Special:MassMessage. Hopefully that will prevent wiki-meltdown on 2 July. — Mr. Stradivarius ^{♪ talk ♪} 00:53, 9 June 2015 (UTC)

This was also announced at WP:BOTN, with the complete list of bots that are known to be at risk. If you have know bot owners who don't frequent BOTN here (especially people at other projects), then please reach out to them. (Also, someday we need to create a template for major issues like this—maybe something like {{warning|All your bots are going to break}}. This only seems to happen once or twice a year, but I worry that people won't notice these messages in time.) Whatamidoing (WMF) (talk) 01:29, 9 June 2015 (UTC)

@Whatamidoing (WMF): You know we have a feature called Wikipedia:Mass message senders, and I do have a talk page that yells at me everytime someone edits it. I only check the bot operators' pages once in a blue moon, and I'm not subscribed to any email lists. I learned of this after my bots broke. – Wbm1058 (talk) 18:17, 13 June 2015 (UTC)

Is there a full list of affected bots? The announcement only names those with over 10,000 deprecation warnings over the course of a week. Some bots operate at a lower frequency but are equally as important — MusikAnimal ^talk 01:49, 9 June 2015 (UTC)

CBNG and CBIII have had a source code change that Damian will push to live soon - Rich^T|C|E-Mail 08:51, 9 June 2015 (UTC)

Anomie is checking with Legal if they can release all the account names: "I already have the list of *accounts* affected: there are 510 with between 1000 and 10000 hits. Of those, 454 do not contain "bot" (case insensitively)" https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/081953.html --Sitic (talk) 19:24, 9 June 2015 (UTC)

I'm guessing that the non-bot users will mostly be people using Huggle, Twinkle, AWB, STiki, and other similar tools. I'm not sure which of the tools is affected, though. — Mr. Stradivarius ^{♪ talk ♪} 22:08, 9 June 2015 (UTC)

@Mr. Stradivarius: there is now a list for all the bots which where not mentioned in the original mail: https://lists.wikimedia.org/pipermail/wikitech-l/2015-June/082037.html --Sitic (talk) 16:15, 11 June 2015 (UTC)

Not all the bots, just the ones that hit the warning more than 1000 times during the week sampled (May 23–29, IIRC). Anomie⚔ 00:09, 13 June 2015 (UTC)

• Mine and everyone else using Peachy have been fixed.—^cyberpower_Chat:Online 08:55, 9 June 2015 (UTC)
• Does anyone know whether there is a fix planned/available for Pywikibot? That would cover about half the bots in the list. — Mr. Stradivarius ^{♪ talk ♪} 09:40, 9 June 2015 (UTC)

You can find some info here: Wikisource:Scriptorium#Pywikibot_compat_will_no_longer_be_supported_-_Please_migrate_to_pywikibot_core. --Mpaa (talk) 12:19, 9 June 2015 (UTC)

• Impending?? Both of my bots are already down, and failing in a library API call. I guess I need to scramble to fix it as soon as I can. – Wbm1058 (talk) 17:17, 13 June 2015 (UTC)

GET: http://en.wikipedia.org/w/api.php?action=query&list=categorymembers&cmtitle=Category%3AArticles+to+be+merged&format=json&cmlimit=500 (0.29201698303223 s) (0 b)
Warning: Invalid argument supplied for foreach() in C:\php\botclasses.php on line 263
GET: http://en.wikipedia.org/w/api.php?action=query&list=embeddedin&eititle=Template%3ARequested+move%2Fdated&eilimit=500&format=json (0.26001501083374 s) (0 b)
Warning: Invalid argument supplied for foreach() in C:\php\botclasses.php on line 496

/**
     * Sends a query to the api.
     * @param $query The query string.
     * @param $post POST data if its a post request (optional).
     * @return The api result.
     **/
    function query ($query,$post=null) {
        if ($post==null)
            $ret = $this->http->get($this->url.$query);
        else
            $ret = $this->http->post($this->url.$query,$post);
        return json_decode($ret,true);
    }
 
    /**
     * Returns an array with all the members of $category
     * @param $category The category to use.
     * @param $subcat (bool) Go into sub categories?
     * @return array
     **/
    function categorymembers ($category,$subcat=false) {
        $continue = '';
        $pages = array();
        while (true) {
            $res = $this->query('?action=query&list=categorymembers&cmtitle='.urlencode($category).'&format=json&cmlimit=500'.$continue);
            if (isset($x['error'])) {
                return false;
            }
            foreach ($res['query']['categorymembers'] as $x) {  // this is line 263
                $pages[] = $x['title'];
            }
            if (empty($res['query-continue']['categorymembers']['cmcontinue'])) {
                if ($subcat) {
                    foreach ($pages as $p) {
                        if (substr($p,0,9)=='Category:') {
                            $pages2 = $this->categorymembers($p,true);
                            $pages = array_merge($pages,$pages2);
                        }
                    }
                }
                return $pages;
            } else {
                $continue = '&cmcontinue='.urlencode($res['query-continue']['categorymembers']['cmcontinue']);
            }
        }
    }
 
    /**
     * Returns all the pages $page is transcluded on.
     * @param $page The page to get the transclusions from.
     * @param $sleep The time to sleep between requets (set to null to disable).
     * @return array.
     **/
    function getTransclusions($page,$sleep=null,$extra=null) {
        $continue = '';
        $pages = array();
        while (true) {
            $ret = $this->query('?action=query&list=embeddedin&eititle='.urlencode($page).$continue.$extra.'&eilimit=500&format=json');
            if ($sleep != null) {
                sleep($sleep);
            }
            foreach ($ret['query']['embeddedin'] as $x) {  // this is line 496
                $pages[] = $x['title'];
            }
            if (isset($ret['query-continue']['embeddedin']['eicontinue'])) {
                $continue = '&eicontinue='.$ret['query-continue']['embeddedin']['eicontinue'];
            } else {
                return $pages;
            }
        }
    }

What do I need to change? Wbm1058 (talk) 17:37, 13 June 2015 (UTC)

I don't find that the email announcement linked above adequately explains this. It may be a slow slog through the documentation if I don't get some help here. Can anyone confirm that there are breaking changes in the latest MediaWiki release?

Link to MediaWiki API help: action=query – Wbm1058 (talk) 19:10, 13 June 2015 (UTC)

Hmmm, it says that rawcontinue is currently ignored

Wikimedia sites are going HTTPS only – some time ago, I tried changing my bot's queries to use https. That didn't work, so my bots still use http. Is that the problem? Wbm1058 (talk) 19:38, 13 June 2015 (UTC)

Wbm1058, this change won't happen for another couple of weeks, so the cause of your bots breaking is presumably something else. When did everything break? Whatamidoing (WMF) (talk) 05:32, 14 June 2015 (UTC)

I'm guessing that this is due to the switch to https-only, which happened a couple of days ago. As Whatamidoing said, the change in the continuation format will not happen until 2 July on this wiki. — Mr. Stradivarius ^{♪ talk ♪} 08:15, 14 June 2015 (UTC)

@Whatamidoing (WMF): My bot's last successful update was at 06:18, 12 June 2015. Per § Forced HTTPS, "At some point between 07:38 and 10:00, 12 June 2015 (UTC), the user preference "Always use a secure connection when logged in" lost its effect, and regardless of its setting, Wikipedia became HTTPS only." I've inquired about solutions over at m:Talk:HTTPS#Bots. – Wbm1058 (talk) 21:20, 14 June 2015 (UTC)

@Wbm1058: I know nothing about PHP, but below in #Self redirect when retrieving https pages? User:Flominator also had an issue in his PHP tool due to the HTTPS switch. --Sitic (talk) 22:10, 14 June 2015 (UTC)

OK, my HTTPS issues have been solved, but just a reminder that I still have only about two weeks to figure out what this is about. – Wbm1058 (talk) 18:41, 16 June 2015 (UTC)

Side by side 'Live' preview of wikicode

The Actual Live Preview gadget at work.

I have a new user script to share...: Actual Live Preview. With this script, if your window is wider then 1200px, it will split it in half and show you your edit surface on the left and a 'update while you type' content preview on the right. The only requirement is that you enable "Live preview" in your preferences. Enjoy. —TheDJ (talk • contribs) 07:55, 10 June 2015 (UTC)

• Like--ukexpat (talk) 15:38, 10 June 2015 (UTC)
• Very nice. :-) Alakzi (talk) 23:14, 10 June 2015 (UTC)
• Like Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 13:11, 11 June 2015 (UTC)
• Like — Fwiw... it works seamlessly along side Wikisource's Sidebar-to-Flatlist gadget for nearly 100% viewspace usage (see scrren grab). -- George Orwell III (talk) 23:08, 12 June 2015 (UTC)

I love it for section-editing. Fabulous!

1 problem: It has a scrolling issue for editing large whole pages, where the edit surface scrolls out of view when I scroll the page. See https://i.imgur.com/em0K4FV.png and https://i.imgur.com/2Daf0YS.png (Firefox, Linux). HTH. Quiddity (talk) 21:48, 12 June 2015 (UTC)

Yeah still pondering how to fix that. It's a bit difficult, to find the right style and UI to improve that. —TheDJ (talk • contribs) 00:33, 13 June 2015 (UTC)

Maybe add some scrolling for such cases? That is, add the text is scrolling box, which is so long how the editing window is --Edgars2007 (talk/contribs) 15:12, 14 June 2015 (UTC)

Found another problem. At least in Latvian Wikipedia, I got such problem: screenshot. The same is at Vector and Monobook, tested in some few articles. Firefox+XP and 1440×900 big resolution. --Edgars2007 (talk/contribs) 15:34, 14 June 2015 (UTC)

Wikidata arrogance

See Drugbox:#IUPHAR_ligand_links_update.

It appears that wikidata people actually write: We need ..., We have to ..., You can do that manually [for 7500 facts?]. While really the (institutional) editor offers to add facts to wikipedia. Sic transit whatever gloria wikidata. -DePiep (talk) 01:20, 11 June 2015 (UTC)

If you are looking for meaning in words, you will find it. WP:AGF —TheDJ (talk • contribs) 06:27, 11 June 2015 (UTC)

By Jimbo, a "wiki" is a website with open editing, where anyone can edit. Four years on, and wikidata still is not a wiki. -DePiep (talk) 11:17, 12 June 2015 (UTC)

Neither is Wikipedia anymore if I'm very honest. It's all about perspective. —TheDJ (talk • contribs) 13:04, 12 June 2015 (UTC)

Wikidata, after hosting the iw's nicely, is a broken wiki. It does not serve. Nothing perspective, it does not function. -DePiep (talk) 21:14, 12 June 2015 (UTC)

number of contributions by a user

How can I find out how many contributions I have made to Wikipedia? Bevo (talk) 20:38, 11 June 2015 (UTC)

The simplest way is via your own Special:Preferences, it will show your number of edits as well as other account information on the User Profile tab. There are also links at the bottom of everyone's user contribution page (yours is at Special:Contributions/Bevo) linking to various tools to see Edit Count and Global contributions and associated statistics. Nanonic (talk) 20:44, 11 June 2015 (UTC)

I have found User:PleaseStand/User info useful for this. If you go to someone's user page, it shows their edit count, gender, user rights, and block status, along with handy links to further information. — Mr. Stradivarius ^{♪ talk ♪} 23:33, 11 June 2015 (UTC)

Thanks to all for this information. Bevo (talk) 02:34, 13 June 2015 (UTC)

Black bar on mobile site search

For about a month now, I've been unable to perform searches on the mobile site's search box from my Blackberry Bold 9900, due to a big, black bar that covers the entire thing. What gives? lavender|^{(formerly HMSSolent)}|lambast 23:54, 11 June 2015 (UTC)

Ugly bug. It should be fixed now (as of ~90 minutes ago). Whatamidoing (WMF) (talk) 01:28, 12 June 2015 (UTC)

Just tested it with this page - it's working now. lavender|^{(formerly HMSSolent)}|lambast 03:13, 12 June 2015 (UTC)

BTW. This looked like a very small thing and I'm sure all reporters were like: "Why don't you 'just fix it' already"... Just to bring some perspective: This issue seems to have required multiple debug sessions over multiple weeks by multiple people, was not always reproducible and in the end changed changed 8 files... Simple things often aren't simple :) —TheDJ (talk • contribs) 10:02, 12 June 2015 (UTC)

It's been reported here before, Wikipedia:Village pump (technical)/Archive 137#Search Field on Wikipedia's Mobile Homepage. --Redrose64 (talk) 10:38, 12 June 2015 (UTC)

Forced HTTPS

At some point between 07:38 and 10:00, 12 June 2015 (UTC), the user preference "Always use a secure connection when logged in" lost its effect, and regardless of its setting, Wikipedia became HTTPS only. Why was this done, and how can it be undone? Some users are unable to use HTTPS connections. --Redrose64 (talk) 10:33, 12 June 2015 (UTC)

Having the same problem, which for me means I will be making very terse edit summaries until this is fixed. Windows uploaded and installed updates yesterday, so it may have something to do with that. I get forced into the secure server even before logging on, and no amount of "s" deletion (https^h) takes me off the secure server. I checked the Favorites properties and it still just has "http", so something's rotten in IE methinks. – Paine  11:12, 12 June 2015 (UTC)

Same here. Firefox.--EchetusXe 11:55, 12 June 2015 (UTC)

Hi. Yes, this is not a local problem for you. See Wikipedia:Village pump (technical)#HTTPS by default below. I'll try to answer any questions regarding this. /Johan (WMF) (talk) 12:46, 12 June 2015 (UTC)

@Paine Ellsworth: Are you referring to phab:T55636? Which version of IE are you using? As for the Firefox issue (EchetusXe), I note that autocompletion of edit summaries works very well for me in Firefox (latest version) with HTTPS. Perhaps you need to check browser or add-on settings. — This, that and the other (talk) 13:10, 12 June 2015 (UTC)

To This, that and the other: – Yes re. phab:T55636. I've known for a long time that my IE-10 in Win8 would not work with WP as it concerns the edit summary autofil challenge. My workaround was to simply not check the HTTPS box in prefs. This, however, is a new problem that doesn't even allow me access to the Wikipedia non-secure server, HTTP, when I'm not logged in. I open the browser, I click the Fave link (HTTP only) and then am whisked away to the HTTPS Wikipedia server. Even if I delete the S in HTTPS up in the URL field, the moment I hit ENTER or GO, the S reappears. Apparently, the WMF has found a way to make it so even non-registered users must use the HTTPS, which is a total drag all around! – Paine  14:07, 12 June 2015 (UTC)

I feel your pain, paine, this also means users from China can NO LONGER access the English wikipedia (this virus is currently limited to enwiki) since https is BLOCKED there, and also, the developers have enforced this without discussion and as per our community first policy and thus we must now vote on removing this..this is the 2nd time this has happened, btw, there is no longer a "forcedhttps" cookie as i have been told by the developer on IRC that the "Always use a secure connection when logged in" option is now well 'utterly useless'....--Stemoc 14:28, 12 June 2015 (UTC)

I'm pretty sure China and Iran are geographically exempted from this. — This, that and the other (talk) 14:41, 12 June 2015 (UTC)

Just to be clear, nobody is geographically exempt. The geographic exemptions only applied to the previous use SSL for logged in users. The use SSL for everyone applies to everyone visiting one of the 8 languages that it has been turned on for (Which includes ZH, but not the Iranian languages) regardless of geographic location. By what I have heard, users from China have not been able to access zh.wikipedia.org (both https and normal http) since several weeks prior to this switch, and they are still able to access en.wikipedia.org over HTTPS, so this switch hasn't had any immediate affect on Chinese users. Bawolff (talk) 06:07, 14 June 2015 (UTC)

Wikimedia devs, you know those people we pay to mess up the site decided our input doesn't matter even though Jimmy explicitly said that we will NOT force IP users into HTTPS during the last Wikimania..--Stemoc 13:53, 12 June 2015 (UTC)

AArrghhh! Not again. This breaks my most important firefox addon. M U S T h a v e p l a i n H T T P : / / please ˥ Ǝ Ʉ H Ɔ I Ɯ (talk) 07:31, 13 June 2015 (UTC)

Eh nope, worst reason. Go poke addon developer to bring his extension into this generation of the web. —TheDJ (talk • contribs) — Preceding undated comment added 10:14, 13 June 2015 (UTC)

Eh nope. It is unsupported. wikilook. It needed a user "patch" to work with later firefox versions, but AFAIK there is no equivalent out there. This dictator driven change is un-representative... ˥ Ǝ Ʉ H Ɔ I Ɯ (talk) 11:43, 13 June 2015 (UTC)

You are complaining to you family because the guy who has been driving you around for 4 years was arrested for driving without a license. You should be thankful for a place where we collectively concluded that driving people around without a driving license is a bad idea, and you should stop hitching rides with that person, no matter how useful he might be to you. —TheDJ (talk • contribs) 12:08, 13 June 2015 (UTC)

GreaseMonkey scripts

It seems that for some people Greasemonkey scripts don't work anymore on https. I'm not entirely sure how and why, but I have figured out that if you add explicit @grant's to the script that they DO work. I'm a little dumbfounded that we didn't get more reports about such failures over the past 2 years... I guess it proves that greasemonkey users don't really understand what they are using. :) —TheDJ (talk • contribs) 19:20, 12 June 2015 (UTC)

HTTPS by default

Hi everyone.

Over the last few years, the Wikimedia Foundation has been working towards enabling HTTPS by default for all users, including anonymous ones, for better privacy and security for both readers and editors. This has taken a long time, as there have been different aspects to take into account. Our servers haven’t been ready to handle it. The Wikimedia Foundation has had to balance sometimes conflicting goals, having to both give access to as many as possible while caring for the security of everyone who reads Wikipedia. This has finally been implemented on English Wikipedia, and you can read more about it [link-to-blog-post here] here.

Most of you shouldn’t be affected at all. If you edit as registered user, you’ve already had to log in through HTTPS. We’ll keep an eye on this to make sure everything is working as it should. Do get in touch with us if you have any problems logging in or editing Wikipedia after this change or contact me if you have any other questions. /Johan (WMF) (talk) 12:43, 12 June 2015 (UTC)

There's a blog post at the Wikimedia Foundation blog now. /Johan (WMF) (talk) 13:09, 12 June 2015 (UTC)

To Johan (WMF): – You have to know what a real drag this is. Not only do I want a CHOICE in the matter, and would continue to choose HTTP as long as the edit summary field's autofil function does not work when I'm on the HTTPS server, you should also consider what Redrose64 said above, that some users are unable to use HTTPS connections. The part in the blog post about "all logged in users have been accessing via HTTPS by default since 2013" is just not true, either. We've been given a choice up until now, and I for one do not want to give that up. I want to be able to CHOOSE whether or not I'm on the HTTP server or the HTTPS server. – Paine  14:21, 12 June 2015 (UTC)

Yes, we do know. The answer I was given when I asked about this is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. Because of this, we’ve made implementation decisions that preclude any option to disable HTTPS, whether logged in or not. This renders the current opt-out option ineffective, and the option will be removed at a later date after we’ve completed the transition process. /Johan (WMF) (talk) 14:27, 12 June 2015 (UTC)

You have had to use HTTPS to access the site when logging in as it's been used for the login process, though. /Johan (WMF) (talk) 14:30, 12 June 2015 (UTC)

It's evidently a weighty issue. And I do realize that I don't edit WP in a vacuum, that I must eventually accept this situation for the good of all. And frankly, I don't have a problem with having to stay on HTTPS as pertains to the "big picture". My problem is very basic and concerns the fact that I no longer have a drop-down list from which to pick my edit summaries, because that function is thwarted by my IE-10 when I am on any HTTPS server. If that little quirk could be fixed, I'd be a happy camper whether I'm on a secure server or not. – Paine  15:47, 12 June 2015 (UTC)

I'm not very familiar with IE myself, but I'll ask around and see if anyone knows a simple fix. /Johan (WMF) (talk) 16:12, 12 June 2015 (UTC)

@Johan (WMF): IE10 won't enable autocomplete on HTTPS pages when the "Cache-Control: no-cache" HTTP header is set (which Wikipedia does). Changing it from "no-cache" to "must-revalidate, private" would allow autocomplete, but may have other unintended consequences. --Ahecht (TALK
PAGE) 16:34, 12 June 2015 (UTC)

@Paine Ellsworth: It seems like IE 11 does not have this problem, and all users would eventually be required to update to it by the end of the year (by Microsoft). Did you try IE 11? Tony Tan · talk 02:09, 14 June 2015 (UTC)

Yes, Tony Tan, I upgraded to Win8.1 and IE-11 yesterday and was pleased to pass it on that it has given me back what I had lost with the older browser and Windows software. Thank you very much for your kind thoughts and Best of Everything to You and Yours! – Paine  02:26, 14 June 2015 (UTC)

I also see I am struck with using HTTPS, which is nuisance and a bother as I longer have a drop-down list from which to pick my edit summaries. How can a drop-down list be re-implemented? It was the only degree of automated help we had in what is otherwise an unfriendly article editing environment. Hmains (talk) 17:44, 12 June 2015 (UTC)

So how do I use the website in http then? I do not want extra security to protect me. I don't need protecting. This is a nonsense. Why am I being forced to use https even though I don't want to use it? There was an opt out. The opt out has been removed despite the fact that those using the opt out very clearly want to opt out. — Preceding unsigned comment added by 86.18.92.129 (talk) 19:46, 12 June 2015 (UTC)

Hi, the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. /Johan (WMF) (talk) 19:53, 12 June 2015 (UTC)

I'll try to figure out if there is a solution to that, Hmains. /Johan (WMF) (talk) 19:53, 12 June 2015 (UTC)

Johan (WMF), Re: "the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out", would you be so kind as to ask for a one-paragraph explanation as to why they believe this to be true and post it here? Not a dumbed-down or simplified explanation, but a brief, fully technical explanation for those of us who are engineers? Thanks! --Guy Macon (talk) 20:49, 12 June 2015 (UTC)

Sure. Just so you know, they're getting a lot of questions at the moment, as well as handling the switch for the hundreds of Wikimedia wikis that aren't on HTTPS yet, but I'm passing on all questions I get that I can't answer myself. /Johan (WMF) (talk) 21:18, 12 June 2015 (UTC)

The engineering-level explanation is that in order to help prevent protocol downgrade attacks, in addition to the basic HTTPS redirect, we're also turning on HSTS headers (gradually). The tradeoff for HSTS's increased protections is that there's no good way to only partially-enforce it for a given domainname. Any browser that has ever seen it from us would enforce it for the covered domains regardless of anonymous, logged-in, logged-out, which user, etc. Once you've gone HSTS, opt-out just isn't a viable option. /BBlack (WMF) (talk) 21:56, 12 June 2015 (UTC)

@Jason Quinn: see the answer above. /Johan (WMF) (talk) 22:12, 12 June 2015 (UTC)

To Johan (WMF): I don't see what the problem is: create a cookie named something like IAcknowledgeThatHttpIsInsecure which can be set from a dedicated page: if this cookie is set, do not send the Strict-Transport-Security (HSTS) header and do not force redirect to HTTPS. Yes, people who have received the Strict-Transport-Security header will get a browser error, but I assume all browsers that implement HSTS allow some way for the user to manually override or ignore it (something like "I know what I'm doing", then set a security exception); and the users can be warned in advance on the dedicated page that sets the cookie. If you're afraid an attacker will set the cookie on an unsuspecting user (through a fake Wikipedia page) and thus bypass HSTS, please note that (1) this attack always exists anyway, because an attacker who can do this can setup a fake HTTP wikipedia.org proxy domain anyway (in both cases, it will impact those users who did not receive the HSTS header), and (2) you can mitigate the attack by letting the cookie's content contain a MAC of the client's IP address (or some other identification string), with a MAC key that Wikimedia keeps (and the cookie is honored only if the MAC matches). You might also display a warning in the HTML content if the cookie is set, reminding of its existence and impact, and giving a link to remove it should the user change their mind. The performance cost of all of what I just described should be completely negligible in comparison with the performance cost of doing HTTPS in the first place. And this should all be very simple to implement. On a personal note: I promise to donate 150€ to the Wikimedia foundation (adding to the 100€ I donate about once a year) if and when a way to access it through HTTP using the former URLs is brought back; conversely, until this happens, I will be too busy to consider how I can work around this inconvenience to contribute either financially or by editing articles. (I could also go on to emphasize how, as a cryptographer, I think the idea of forcing users to go through HTTPS to read publicly accessible and publicly editable information is absolute idiocy, but the cryptophile zealots have made up their mind already.) --Gro-Tsen (talk) 19:43, 13 June 2015 (UTC)

Keyed MAC of client IP address is not going to work due to dynamic IPs that change (And I'm not sure that there exists any other unique identifier that would be appropriate. Keep in mind, for your scheme to work, the browser cannot receive an HSTS header even once). Note that deleting an HSTS setting from your browser is actually much more hidden then you'd normally think, and are generally not meant to be user overridable. While you're correct that HSTS cannot prevent a malicious proxy if the user has never visted wikipedia before (unless we do HSTS preloading, which we do not yet), your scheme weakens the protection of HSTS, since a malicious proxy only has to set a cookie for wikipedia, not necessarily catch the user at the first visit. Furthermore, in order for the redirect not to take place, the cookie must be non-secure. Hence the malicious proxy might as well just pretend to be some fake subdomain, e.g. http://fake.wikipedia.org (Which since its fake, does not have HSTS, unless we set the includeSubDomains flag for HSTS, which we don't currently, and would prevent us from ever hosting a non-secure service on any subdomain), use some method to load traffic from that address (easy), and then set your IAcknowledgeThatHttpIsInsecure cookie with the domain field set to .wikipedia.org. Last of all, your scheme is also incompatible with HSTS preloading, which presumably the WMF is eventually going to pursue. Bawolff (talk) 00:53, 14 June 2015 (UTC)

OK, I'll give up on trying to solve other people's problems with HTTPS and focus on mine: to this effect, do you (or anyone else) knows if there at least exist some reliable transparent Wikipedia mirror on HTTP (perhaps something like "wikipedia-insecure.org") that allows both reading and editing and that I could use (by spoofing my DNS to point there) without the trouble of setting up my own? (I hope we can agree that a mirror served under a different domain cannot weaken security since anyone can set up such a thing.) I'll find a way to disable HSTS on my browser somehow. --Gro-Tsen (talk) 23:02, 14 June 2015 (UTC)

It's worth giving some background here to understand the need for security. One of last year's revelations was that Wikipedia editors were being targeted by the NSA. So if you weren't using HTTPS (and probably even if you were), you were likely helping to build a database profile on your reading habits. But worse, your e-mail and other communications were probably also targeted for follow-up simply because you edit Wikipedia. What difference does it make? Nobody in the general public knows! The collected information is used in secret fashion in secret ways by undisclosed people. But there are real dangers to you. Supposedly, the information is being used only for national security related to terrorism. That's not true, however, because it is known from the same leaks that it is being used for more than that, for instance, in the war on drugs. And, it is also known that collected information is sometimes abused by those who have access to it for personal reasons. The use could also include (and probably is) helping to decide whether you get security clearance for future dream job. it could potentially even be used to sabotage a hopeful's political career or in general help silence people with oppositional points of view. In other words, this information has the potential to be used by people now or in the future to negatively affect your life and destiny without you even knowing. The WMF has decided (and rightfully so) that there's a need to protect users from dangers that they might not even be aware of. When it comes to this, many people say things like "I'm not doing anything wrong" or "I've got nothing to hide" but the problem is that you can't say you're doing nothing wrong because it's third parties who determine that, not you. And you do have stuff to hide even if you are completely a law-abiding citizen. This issue that affects you even if you think it doesn't. People are talking above about certain countries that do not allow HTTPS and how IP users there should be not be forced to use HTTPS because Wikipedia would be blocked for them. Well, those are great examples where governments being able to see what you are reading could get you arrested, imprisoned, or worse. The use of HTTPS is only a minor step in combating the abuse of government-level surveillance but it's a step in the right direction. @Johan (WMF), it'd be interesting to know why the implementation cannot safely handle an opt-out because naively I don't see why the one should affect the other. Maybe this exposes a flaw in the implementation. Jason Quinn (talk) 21:17, 12 June 2015 (UTC)

Hi Jason Quinn, thanks. I'm passing on the question to someone better suited to answer it than I am. /Johan (WMF) (talk) 21:20, 12 June 2015 (UTC)

On January 12, 2016, Windows 7 users will be required to install Internet Explorer 11 and Windows 8 users will be required to update to Windows 8.1 anyway, so you don't need to worry about the autocomplete problem in IE10. That problem doesn't occur in IE11. GeoffreyT2000 (talk) 21:26, 12 June 2015 (UTC)

Wikipedians were NEVER targeted by the NSA, why would they be? I don't know where you people are getting your information from and if some wikipedian came along and said that s/he was being targeted, then s/he was either being paranoid (like 90% of americans) or s/he is doing soemthing "illiegal" so its the best interest of wikipedia to report that person to NSA, not ENFORCE this stupid idea....Again Wikipedia is an INTERNATIONAL website, its NOT only for AMERICA....why should the rest of the world have to pay for the fears of a few paranoid psychopaths that are better off in jail..oh and BTW, HTTPS has and will NEVER be secure, the "s" in https never stood for secure...@Jimbo Wales:, Why would you allow this?--Stemoc 21:43, 12 June 2015 (UTC)

At the right is the main slide itself so you and others can decide for themselves what it means. The slide explicitly uses Wikipedia as an example of the websites that they are "interested in" and confirms that they are interested in "typical users" of such websites. Given the context of the slide (exploiting HTTP for data collection), it is unreasonable to assume readers and editors were not being targeted. We all were targeted and all our traffic to and from Wikipedia would have been caught up in the named NSA collection programs. It would be naive to think otherwise. If there is one thing that's been learned in the last year, it's that "if it can be done, it is" kind of summarizes what's been going on and "mitigated" does not described their collection techniques. As for other countries being denied access by the global removal of HTTP support, that is a point that should be debated. But I already mentioned that there are countries were the use of HTTP might literally allow Wikipedia readers to be executed for readings the "wrong" stuff. The meaning of a "free" encyclopedia would have to be discussed and the dangers of access in these countries would have to be considered and weighed in such a debate. And, regardless of how you perceive the US, it's possible the US could become as bad. Jason Quinn (talk) 22:30, 12 June 2015 (UTC)

It is certainly a bit of a backtrack by @Jimbo Wales:.Blethering Scot 22:43, 12 June 2015 (UTC)

The real win here (imo) is making Firesheep style attacks totally impossible and thwarting non-state sponsored, and lower budget state sponsored adversaries. One assumes that the NSA will probably just slurp up the unencrypted inter-data center links (For those of you not close enough to use eqiad directly. Imagine a world where the sum of human knowledge fully deployed IPSec). Given the funding level of the NSA, I expect that they probably have traffic analysis capabilities to be able to tell who is visiting a page of interest (especially for a site like wikipedia, which imo seems like the perfect target for a traffic analysis type of attack against a TLS secured connection). However https does make it much harder to simply collect it all, and any measure that increases the cost of ubiquitous surveillance should be applauded. Bawolff (talk) 22:50, 12 June 2015 (UTC)

All I see Jason is a bunch of American websites.....Mate, if NSA want to spy on you, it WILL SPY on you, you don't have to eff up wikipedia for them to stop and basically, by forcinghttps onto the wikipedia, would you not think that it will make NSA more interested? because only a person with something to hide would do this ..So Jimmy loses his battle with NSA in terms of NSA and this is what he comes up with? moving to https which honestly is just as secure as http...After this was defeated last year, i honestly felt like we lived in a democracy where the voice of the people was heard and adhered........back to communist wikipedia we go..yeah Jason, executed for reading the wrong stuff on wikipedia like How to build a Bomb or How to join ISIS......oh right, we don't have those pages cause wikipedia is NOT a terrorist organization...--Stemoc 22:59, 12 June 2015 (UTC)

(a) Non-Americans arguably have got more to fear from NSA surveillance; the legal framework allows for the collection of great swathes of foreign data. (b) The decision was made by Wikimedia, which is in no way a democracy. (c) Do actually read up on the issues you're arguing. Alakzi (talk) 23:29, 12 June 2015 (UTC)

Yeah, you really shouldn't let your anger and/or frustration allow such bullshit from your fingers and keyboard, Stemoc. "Communist Wikipedia"? no more than an airline practices communism when they check for bombs and weapons as we board – no more than when we have to pass through a building security point that helps to protect us while we're on the premises - is it communism to own a .357 and be ready to shoot a criminal who tries to steal from you? or to hurt your loved ones? Privacy, security, if you don't try to work with structures that protect them, then you're no better than the criminal, terrorist or agency that tries to circumvent them. Best of Everything to You and Yours! – Paine  00:03, 13 June 2015 (UTC)

Calm down lady, this is just an Encyclopedia, not your ebay, paypal, bank account or your social networking sites where privacy is a MUST NEED for safety reasons.. the MAIN reason this site was created was to allow users to browse and edit anonymously so no one really knows your true identity or location, if you are using your real name and stuff, I'd advice you to invoke the 'Vanish' policy and start anew or get your account renamed, I think people keep forgetting that this is NOT like every other site they visit, infact wikipedia is based on facts and if you are scared to write down fact on articles because you fear the NSA then i really really pity you... only crooks fear the government....let that be known...and p.s, I'm brown and I don't give a shit about the NSA...as usual, the wiki revolves around America...pathetic.--Stemoc 02:47, 13 June 2015 (UTC)

@Stemoc: Out of curiosity, what do you think about the following hypothetical situation: Someone (Lets say Alice) thinks she might have <insert weird disease here>. Alice wants to look it up on Wikipedia, but is worried that her ISP is tracking which websites she visits, and will sell the information to her insurance company (or whomever else is the highest bidder), who in turn will jack up the price of her insurance beyond what she can afford, on mere suspicion of having the disease, even if she doesn't have that. Is that a legitimate reason to want/need privacy when browsing Wikipedia? You may trust the government (For some reason), but do you really trust your ISP? What about the guy sitting across the room at the starbucks on the same wifi network? Bawolff (talk) 06:12, 13 June 2015 (UTC)

Bawolff, again, another "american" problem....I have an IDEA, why not make a us version for https?, brilliant now, e.g, anyone that wants to be logged in on https, log in at https://us.en.wikipedia.org and everyone else at the old link at http://en.wikipedia.org, this will solve the problem once and for all, why "force" everyone onto https, its the same as pushing everyone over the cliff and telling them to swim instead of building a bridge to get across, those who can't swim or having health (ISP) problem will surely drown..I fought this the last time it happened and I will fight it yet again..--Stemoc 11:43, 13 June 2015 (UTC)

+1. Live in a country with universal health care...Or has privacy laws...I am an IT professional with a Computer Science Degree and 30+ years of experience. I know the implications of not using HTTPS, an I also know the NSA can bypass that easily if they care to. This (not allowing an opt-out) is total garbage and a false sense of security...˥ Ǝ Ʉ H Ɔ I Ɯ (talk) 11:56, 13 June 2015 (UTC)

Now cut that out, buddy, or I'll hit you with my purse! Hey, waitasec – how did you know I'm a "lady"? You been hackin' into my HTTP??? – Paine  12:46, 13 June 2015 (UTC)

Little old me? hacking? NEVAH!......--Stemoc 17:01, 13 June 2015 (UTC)

@Bawolff: We're not done with all of our plans for securing traffic and user privacy. This will be covered in deeper detail in a future, engineering-focused blog post after the initial transition is complete. But just to hit some highlights in your post: we do have an active ipsec project, which is currently testing on a fraction of live inter-DC traffic. We're also looking into what we can do for some forms of traffic analysis, e.g. mitigating response length issues. We plan to move forward as soon as possible on heavier HTTPS protection mechanisms like HSTS Preloading, HPKP, etc as well. We're committed to doing this right, we're just not done implementing it all yet :) -- BBlack (WMF) (talk) 01:53, 13 June 2015 (UTC)

@BBlack (WMF): I appreciate there's more to come, and I'm happy to see that its (finally) happening. However I think its important to give our users the full picture, the good, and the bad. HTTPS is great for confidentiality and integrity. Its somewhat ok for providing privacy, particularly against a weak adversary, and it makes bulk matching of packets against fixed strings in the body of the request impossible (Which is quite important given the selective censorship threat wikipedia faces). But its questionable how well it would hold up against a powerful nation state actor trying to simply de-anonoymize you. It certainly wouldn't hold up against a targeted attack, and its questionable if it would prevent a more broad attack (albeit it would certainly make a broad attack quite a bit more expensive to pull off). I'm also quite doubtful you can really foil traffic analysis with padding TLS sessions, unless you use extreme amounts of padding, far past what is acceptable performance wise. p.s. The ipsec project link is limited to those in the WMF-NDA group, so I can't see it (I'm in the security nda group only). However I can certainly see in puppet that IPSec is enabled on a small number of servers, and I noticed it was mentioned when I was reading the WMF quarterly report. Bawolff (talk) 03:03, 13 June 2015 (UTC)

@BBlack (WMF): It is great to see that the WMF is finally switching to HTTPS by default. I look forward to seeing Wikipedia send HSTS (includeSubDomains, long max-age, preload) and HPKP headers! However, phab:T81543 seems to have restricted access. Thanks, Tony Tan · talk 02:39, 14 June 2015 (UTC)

One of the nice things I just noticed that is really nice is that ru.wikipedia.org has an A+ on the SSL labs test [1]. Here's to looking forward to that for all Wikimedia domains, once HSTS is turned up :D Bawolff (talk) 05:20, 14 June 2015 (UTC)

Not such a difficult fix

Just want to make sure that everyone catches what contributors TTO (at phab:T55636) and GeoffreyT2000 (above) have been kind enough to share with us. Several of the above users may be happy to hear that I can confirm what TTO and GeoffreyT2000 say about Win8.1 and IE-11. I just upgraded, and the new software thus far seems to work a lot better under HTTPS than my old Win8.0 and IE-10 did. Forms do indeed autofil, which means that my old drop-down boxes with my edit-summary choices do show up again. I still sympathize with all the users above who feel they've lost something with this change, however, like I said, we don't edit in a vacuum any more than we become passengers on aircraft all by ourselves. As an analogy, airport security can be a real hassle and a serious time cruncher on occasion, but compare that to what has happened, and still could happen, and there should be none of us who would not want that security to keep our flying times safe. Same for the conversion to HTTPS – it is quite the hassle for some, but the very real need to protect our privacy and security is an overwhelming priority, in my humble opinion. So, /Johan (WMF), you don't have to find an IE fix for me, and I greatly appreciate the fact that you said you would! I also deeply thank the rest of you for your enlightening responses here. Best of Everything to You and Yours! – Paine  23:32, 12 June 2015 (UTC)

Thank you. I'll still at least ask around to see if there's anything I can do. We want editing Wikipedia to be as simple as possible, no matter which browser people use. If one is OK with upgrading to IE 11, that's probably the best solution, though. /Johan (WMF) (talk) 01:25, 13 June 2015 (UTC)

So, here's what I got on this issue so far. Yes, there appears to have been an open Phabricator ticket since 2013 reporting this issue, and no, given the number of tickets, the team that dealt with the transition wasn't aware of it. We'd obviously have preferred to be. Sorry, and I really mean it. Causing trouble for people who edit Wikipedia is the opposite of what we want to achieve. We're still in the process of transitioning (English Wikipedia was one of the first to switch over, and there are more than 800 Wikimedia wikis) and I haven't found an easy fix so far (except for upgrading to Internet Explorer 11), as this isn't so much a bug as how Internet Explorer 10 intentionally behaves. The team will be able to focus more on this as soon as the HTTPS transition is complete. We're not ignoring the issue. /Johan (WMF) (talk) 12:10, 16 June 2015 (UTC)

This broke my bot :( I'm using RestClient library to make API requests, and it apparently is unable to verify the certificate. Getting the error SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (RestClient::SSLCertificateNotVerified) Surely that's an issue on my end? I can force it to not verify the certificate but then what's the point of using HTTPS? — MusikAnimal ^talk 18:32, 13 June 2015 (UTC)

I took a quick look, and it seems that this library has a way to pass to the SSL library the CA certificates to be used for verification. It probably just doesn't have a default set of CA certificates. The solution would be to give it a copy of the correct root certificates to use. --cesarb (talk) 21:26, 13 June 2015 (UTC)

Who loses

@Johan (WMF): Hi, while you are here I would like to have something specific clarified. As always with these sorts of major changes, most people win and some people lose. I personal am iffy about the distribution of relative ideological and technical interest and need for this particular project, but I accept that that merely puts me in the middle of the Wikipedian spectrum, between people like TomStar81 who wants nothing to do with the ACLU and people like Jason Quinn who thinks it keeps us from being roasted on an open flame.

However in these sorts of changes I care less about who wins, because that's obvious. I can read the spam-ish blog post to find that out. I am more interested in the question: who loses?

Who does HTTPS hurt? Can we come to an understanding of this? Surely every change, no matter the size, hurts some stakeholders. ResMar 03:58, 13 June 2015 (UTC)

1. Can someone clarify what is going on with the IE 10 issues? Was the WMF aware of this problem? Is it really that significant?
2. Can someone clarify what the effect will be in mainland China? Can you quantify the impact there?

Thank you. ResMar 04:00, 13 June 2015 (UTC)

Hi, good question that deserves a good answer, not just what I can come up with on the top of my head. I'll ask around about a few things to make sure I (or maybe someone else, I'll spend much of this weekend travelling) can reply properly. /Johan (WMF) (talk) 04:19, 13 June 2015 (UTC)

Great! Thank you. I think this discussion so far has been high on posturing, low on content (speaking about the community response here), and I'd love to see a frank cost-benefit analysis from the WMF on this matter, and an associated community critique. After all, this is the communication that the volunteers so crave. Not, frankly, blog announcements. ResMar 04:44, 13 June 2015 (UTC)

I'd also like to see my transparency on WMF's the analysis. Everything seems to be shrouded in unnecessary secrecy. On the subject of China. I'm not that familiar with the situation, but according to https://en.greatfire.org/search/wikipedia-pages - HTTPS is currently not blocked There seems to be conflicting info on if HTTPS is blocked. The greatfire website says https is not blocked, but there actual test data seems to suggest that both normal http and https on zh is blocked starting may 19 [2] (The switchover for zh to https happened on June 9, so change in blocking status seems unrelated) but en is fine (both https and non-https). There are about 324 pages that are censored on the HTTP version, mostly on zh, however on en we had Students for a Free Tibet, Tiananmen_Papers, Tiananmen_square_massacre, Tibetan_independence_movement blocked. Switching to HTTPS forces china to decide either to block all of wikipedia or none of wikipedia (Possibly they can distinguish between languages and block say all zh, but not en. I'm not that familar with SNI, but my impression is the domain is sent in the clear). FWIW, greatfire strongly advocates switching to https on zh wikipedia [3], although they are obviously a special interest group that believes Chinese censorship needs to be fought tooth and nail. I imagine the situation is similar for Russia, which rumor had (Although I've not seen direct sources for this) was trying to censor pages related to Ukraine on ru, but can't anymore due to https. The other impact, is that it makes harder (but certainly not impossible depending on their traffic analysis capabilities) for China to generate lists of people who try to visit certain politically sensitive topics (Its unclear if they actually do that. I haven't heard of any evidence that they do, but it wouldn't surprise me). Other potential things to keep in mind, in the past China has DDOS'd websites (GitHub) that host material China finds objectionable, but cannot be censored selectively due to HTTPS and are too popular to block outright (However, I consider it very unlikely they would do something like that to Wikipedia. Wikipedia has a low enough popularity in China, that they would probably just block it totally if they decided to do something about Wikipedia). Bawolff (talk) 05:18, 13 June 2015 (UTC)

Regarding secrecy, or at least part of it: yeah, we didn’t really enjoy springing this on the community, though the WMF has publicly been talking about the intent to switch to HTTPS for the past years. The reason we didn’t say anything about the specific deadlines or make public the transition until it was in progress was because public statements opened us to possibility of man-in-the-middle attacks. Letting everyone know meant letting bad actors, so to speak, know our plans and timeline. We couldn’t have this debate in public without telling the world what we intended to do, which could have compromised the security and privacy of readers and editors in certain areas. We’d have preferred not having to worry about that, obviously. /Johan (WMF) (talk) 19:33, 16 June 2015 (UTC)

@Resident Mario: Other people that HTTPS could potentially hurt which we know about (Personally I think this is an acceptable hurt): People who use IE6 on windows XP will not be able to view any page on wikipedia. (IE6 on XP is incompatible with modern best practices for HTTPS). People on very old browsers which don't support SNI (e.g. Android 2.3.7, IE 8 / XP, Java 6u45), will get a certificate error when visiting a sister project (But wikipedia will be fine). Bawolff (talk) 20:02, 13 June 2015 (UTC)

@Bawolff: Sounds reasonable. ResMar 20:21, 13 June 2015 (UTC)

@Bawolff: The Wikimedia certificate uses subjectAltName, not Server Name Indication. SAN is supported by IE6. LFaraone 05:27, 14 June 2015 (UTC)

@LFaraone: IE6 doesn't work because it only supports SSLv3, and we require at least TLS1.0 (To prevent downgrade attacks/POODLE). We use both subject alt name, and SNI and wildcard certs. If no SNI is sent you get a certificate for *.wikipedia.org with an alt name of wikipedia.org. Which is great if you're browsing wikipedia. Not so great if your browsing wiktionary.org. Bawolff (talk) 05:45, 14 June 2015 (UTC)

@Bawolff: Browsing wiktionary.org works fine even if the browser doesn't send SNI. If the SNI is absent, the server sends a diffenert certificate whose subject alternative names include domain names of all sister projects. 191.237.1.8 (talk) 06:42, 14 June 2015 (UTC)

Oh, you're absolutely right, users get a uni cert when they don't have SNI. I saw the SNI behaviour of switching certificates and just assumed it would be broken without SNI. My bad. Bawolff (talk) 11:09, 14 June 2015 (UTC)

@Bawolff: I just checked my IE6, it has TLS 1.0
—Telpardec  TALK  20:57, 16 June 2015 (UTC)

Yes, but its disabled by default. The type of people who use internet explorer are probably not messing with the TLS settings. When I was running IE6 under wine, enabling TLS1.0 didn't seem to help anything, but that was probably just wine not working great. Bawolff (talk) 04:19, 17 June 2015 (UTC)

To Resident Mario: The switch to HTTPS will badly hurt those who chose to change their browser's default list of certification authorities and who, specifically, do not trust GlobalSign (the root authority from which Wikipedia's certificate emanates). At the very least, they will be forced to add security exceptions for all Wikipedia domains, and quite possibly will be locked out of Wikipedia altogether because browsers do not always allow security exceptions on HSTS sites. In effect, the switch means that users are forced to either trust everything that GlobalSign signs if they wish to use Wikipedia, whereas so long as HTTP transport was permitted, one could at least read Wikipedia on HTTP if one does not care about the security of public information on Wikipedia but doesn't want to trust GlobalSign. (I can't explain the problem with GlobalSign because I don't want to risk being sued for libel, but let's say that one might not necessarily wish to trust all, or any, certificate authorities.) So the irony is that this change, which is supposed to protect the "security" of users, actually forces security-conscious users to downgrade theirs, in effect a Trojan horse kind of attack. (In all fairness, Web browsers and HTTPS in general should be blamed for having an absurdly rigid approach to security: one can't restrict a certificate authority to certain domains, or things like that, so I can't say "I trust GlobalSign only for signing certificates in the wikipedia/wikimedia/wiktionary/etc.org domains".) --Gro-Tsen (talk) 21:15, 13 June 2015 (UTC)

For real? Any person who intentionally messes with their root certificate store, should be technically competent enough to make their own trust decisions of Wikimedia certs, by say verifying them in some other way. If you're not, you have no business removing CAs from your trust store. Bawolff (talk) 21:45, 13 June 2015 (UTC)

About 10% of HTTPS websites use GlobalSign, so it is not a Wikipedia-specific issue. One could say the same for any other CA that the WMF may decide to use. Moreover, Bawolff makes a great point that someone technically competent enough to mess with trusted roots would be able to work around this as well. They must know how to do so already, since there are numerous other sites using GlobalSign! If someone really lost faith in the CA system, they should try using Convergence, Perspectives, or Certificate Patrol. Tony Tan · talk 03:07, 14 June 2015 (UTC)

@Resident Mario: To answer your second question, according to zh:Template:Wiki-accessibility-CHN, zh.wikipedia.org is currently completely blocked in China using DNS poisoning. HTTPS versions of all other Wikimedia projects are not blocked. @Gro-Tsen: If you manually remove GlobalSign root certificates from your browsers' trust stores, you can manually add Wikipedia's leaf certificate to the trust store so that your access to https://en.wikipedia.org/ is not blocked by your browsers. 191.237.1.8 (talk) 05:09, 14 June 2015 (UTC)

And another problem: No browser history!

@Johan (WMF): - In addition to losing the drop-down edit summaries (as mentioned above), I've also lost the browser history for all newly-visited Wikipedia pages. Why the exclamation point?? Because this is absolutely crucial -- in fact, integral -- to my ability to work on Wikipedia. I totally depend on having those page links, which give me quick & easy access to all recently-visited pages.

Johan, you said above, "We want editing Wikipedia to be as simple as possible, no matter which browser people use." (I am using IE 8.) Please tell me there is going to be a technical fix for this problem ASAP. Because if there isn't, there is a very real possibility that I will have to give up editing. I am a long-time (since 2006), very conscientious editor, with nearly 60,000 edits. So I truly hope that does not become necessary. Cgingold (talk) 09:11, 13 June 2015 (UTC)

P.S. - I raised the very same issues a couple of years ago during the last discussion on this subject, which was resolved to my satisfaction when I learned that it was possible to opt out. So this is really a sore point for me. It sure would have been nice if you guys at least had the consideration to place a banner at the top of all pages for a week or two giving all of us a heads up about the impending change. Matter of fact, I believe I made the same point last time! :-( Cgingold (talk) 09:20, 13 June 2015 (UTC)

Best advice I can give is to use IE11 or another non broken browser. —TheDJ (talk • contribs) 10:19, 13 June 2015 (UTC)

Yup, this is a problem for me too that is admittedly a considerable annoyance. I always opted out previously for this reason. Connormah (talk) 11:21, 13 June 2015 (UTC)

@Cgingold: If you mean that you lost your browser history for all of the http domains, I would say: deal with it yourself. It's a petty issue. You will regenerate the URLs soon enough as you visit the new pages again; it's no different than if you were to clear your browser history. If you have lost the ability to generate new URLs in your URL history, then that is a problem. I hope it can be fixed, but if it cannot...wouldn't it be easier for you to move up to an Internet browser that's less than six years old? ResMar 13:48, 13 June 2015 (UTC)

Even if it was "merely" the loss of older browser history that I was referring to -- which it wasn't -- that would hardly be "petty", my friend. You might want to check your attitude at the door before you trivialize another editor's problem. But of course, I was talking about the fact that my browser no longer generates new URL links in the browser history. And it is indeed a very serious problem. Cgingold (talk) 21:29, 13 June 2015 (UTC)

Petty? The switch to HTTPS is petty. It is stark raving mad to switch to https to avoid NSA surveillance. I cannot believe the reasoning there, some people need to take their tin foil hats off. I bet if anyone were to read this at the NSA then would have a right good laugh at us all. Even if they were inclined to mine data off this site then the switch to https would be of little impediment to a body of that resources. Why do we not only operate on tor and demand VPN usage if we are trying to protect the hypothetical drug smugglers, money launderers and terrorists that apparently have abandoned the onion sites in favour of WP talk pages? There is no benefit for this change in policy and the reasoning behind is deranged.--EchetusXe 17:46, 13 June 2015 (UTC)

I am not here to hear your opinion, I am here to assess the damage. ResMar 19:39, 13 June 2015 (UTC)

@Connormah: As a sysop, you should probably use HTTPS. Otherwise, your account is at risk of being hijacked in a Firesheep-style attack, especially when you use a public network. A sysop account would be really useful for someone intending harm. :( If there are big issues, upgrading your browser to a newer version of IE, Chrome, Firefox, etc. should help. Tony Tan · talk 03:15, 14 June 2015 (UTC)

Cgingold, I just wanted to say that, yes, we really do care about your problems, we appreciate all the work you're doing, and I will ping you personally as soon as I have good answer or solution. /Johan (WMF) (talk) 12:15, 16 June 2015 (UTC)

For reference, IE < 11 represents about 5.5% of our traffic [4]. Bawolff (talk) 18:54, 13 June 2015 (UTC)

How about a 'in the clear' sub-wiki?

Like http://itc.en.wikipedia.org which just reflects the normal wiki. Then all users of 'normal' wikipedia get HTTPS, but people who want/need HTTP have to specifically ask for it.˥ Ǝ Ʉ H Ɔ I Ɯ (talk) 09:38, 13 June 2015 (UTC)

It would more likely be http://en.insecurewikipedia.org, but I don't think there would be many fans to maintain such a system.. We will have to see about what kind of case can be made for that, but I think it is unlikely that it will happen. —TheDJ (talk • contribs) 10:25, 13 June 2015 (UTC)

Anyone could setup a proxy to do this (e.g. http://crossorigin.me/https://en.wikipedia.org [maybe that's a bad example, as it doesn't fix the links]. Anyways, point is that it is trivial to set up an independent proxy to an HTTPS site. Allowing edits might be trickier, but not impossible ). Bawolff (talk) 18:28, 13 June 2015 (UTC)

We have had a discussion

Just a note that we have had a discussion at the village pump about this earlier this year (WP:VPR/HTTPS). The discussion was closed as WP:CONEXCEPT due to the highly technical nature of the issue.

From my point of view, this move to HTTPS-by-default is the correct one. Mozilla (Firefox), Chromium (Chrome), the IETF, and W3C TAG are all behind moving websites on the Internet in general to HTTPS and deprecating insecure HTTP.

HTTPS guarantees the authenticity of content sent from Wikipedia servers as it travels through the Internet, prevents tampering (whether it is censorship in another country or your internet service provider injecting ads or adding invasive tracking headers), and curbs mass surveillance (by a gov't or an internet provider) by making it difficult and expensive to monitor articles being read or written by individuals.

Regarding the potential negative effects of switching to HTTPS for older clients/browsers, we should be able to find a workable solution for them fairly quickly. A lot of the issues mentioned are software bugs that can be fixed without going back to HTTP. Google uses HTTPS by default, and there does not seem to be an issue with anyone using Google. Tony Tan · talk 20:43, 13 June 2015 (UTC)

Thank you so much, Tony, for pointing out that Google doesn't cause these kinds of problems! Somehow, I hadn't even noticed that -- I guess precisely because it doesn't cause any problems... SHEESH!! If these issues are, in fact, entirely unnecessary, then WHY WERE THEY IGNORED by WMF's tech people when they had been explicitly pointed out on this very page a couple of years ago??? Inexcusable. I am sitting here literally shaking my head in disbelief... Cgingold (talk) 21:48, 13 June 2015 (UTC)

Well, google (the search engine anyways, not counting other sites google runs) does its own auto-complete with javascript based on what it thinks you want to search for. It does not use the built in remember what I typed previously browser feature. You used the word "issues" in the plural. As far as I'm reading, the old version of IE disables auto-complete on HTTPS is the only actual issue reported in this thread that could possibly not affect Google (Or for that matter, is a reasonable complaint imo). Am I mistaken? Edit: I guess you're also complaining about browser history, so that makes 2 issues. All things considered, both are essentially minor inconveniences, both are experienced only by a relatively small number of users, and the autocomplete one has an easy way of mitigating (update your browser). Not exactly what I'd call the end of the world. Bawolff (talk) 04:45, 14 June 2015 (UTC)

Please enable HTTP mode

Hi. I'm from Iran. After WP enabled https as default (and no access to http), we have a lot of problem to access WP due to Internet censorship. Because Iranian government abuses https protocol. It's very slow and pages do not load properly. Time-out error happens frequently. Editing is not easy anymore. Please enable HTTP option for restricted countries again. Wikipedia is a great contribution to humanity. Thanks. --188.158.107.24 (talk) 10:41, 14 June 2015 (UTC)

All people everywhere possess the inalienable right to have access to information of any and every kind. And they should be able to express that right without intervention by any company, organization or government, to include suppression, censorship and secret monitoring. The sole exception would be information that is kept secret for reasons of national security. What I don't understand is why any government would suppress and censor this right by committing abuse of HTTPS and not also commit abuse of HTTP? Is HTTP really that much harder to abuse? to suppress and to censor? Since many of the problems that have erupted since Wikipedia converted to HTTPS-only are shown to be due to users using older versions of software, and perhaps older hardware as well, maybe if you upgraded to recent versions you would find that rather than governments being the problem, usage of non-recent versions of hardware and software is the problem? – Paine  16:06, 14 June 2015 (UTC)

They try to block HTTPS and other encrypted traffic because they can't see what you're doing. Cleartext traffic like HTTP can be examined. They want to give people some access to the Internet, because they know it's generally a lost cause to try to block Internet access completely, and trying to do so might spark a revolt, but they want to retain the ability to block some content, and keep tabs on what you're doing. For instance, China's "Great Firewall" selectively blocks access to information on things like the Tienanmen massacre through multiple techniques, including a blacklist of certain sites, and traffic analysis. --108.38.204.15 (talk) 22:33, 14 June 2015 (UTC)

@Legoktm: you might know who to pass this concern onto. Magog the Ogre (t • c) 22:35, 14 June 2015 (UTC)

I think I understand what it feels like to be faced with Internet censorship; I spend half my time in China, where the Great Firewall disrupts access to websites that are commonly used in countries like the U.S. It is very, very frustrating. What I do want to point out, however, is that by enabling forced HTTPS encryption, governments like that of Iran will be forced to make the decision to either block all of Wikipedia or none of it, instead of being able to selectively filter by the topic of individual articles. While in the short term users may find access to be unstable or even impossible, the government may eventually be forced to stop interfering with Wikipedia traffic if it decides that access to the "good" information is more important than filtering the "bad" information. So in the long run, it may be better to keep Wikipedia HTTPS only if users eventually end up having access to all of Wikipedia, without censorhip. There is no guarantee, but I think we should at least wait and see. Tony Tan · talk 01:50, 15 June 2015 (UTC)

@108.38.204.15: Out of curiosity, do you have a source for information about the great firewall using traffic analysis? Most of the things I read seem to suggest they mostly use deep packet inspection and DNS posioning. And I'd be really interested in reading any publicly available info about how their system works. Bawolff (talk) 02:10, 15 June 2015 (UTC)

I'm suspicious that HTTPS will do nothing to stop spying by the NSA or GCHQ, but has been introduced to make it much harder for whistleblowers to sit in the middle and see who they are spying on. It seems we're stuck with it though, and if you're using ancient browsers such as IE8, you'll just have to upgrade. Akld guy (talk) 06:24, 15 June 2015 (UTC)

That doesn't really make sense to me. What realistic opportunities would a whistleblower ever have to be in the middle of an NSA/GCHQ communication? And even if they were in such a position, the transport security of Wikimedia would be rather irrelevant. To the best of my knowledge, no whistleblower has ever intercepted communications in transit over the internet in order to release for the public interest. Whistleblowers are usually in a trusted position, and legitimately have access to the data which they decide to divulge. Bawolff (talk) 07:47, 15 June 2015 (UTC)

I want to clarify one thing that's turned up a couple of times in the general discussion (and I'm not replying to any specific user here). There have been a number of comments regarding the NSA. We know that the NSA has targeted Wikipedia traffic, and the Wikimedia Foundation doesn't believe Wikipedia readers and editors ought to be targeted, but while this may have been tangentially related to concerns over the NSA, it wasn’t the driving force. There are other governments and private actors to take into account, and, for example, the Firesheep style attacks that Bawolff has mentioned. Rather, it was driven by concern for the privacy and security of editors and readers all over the world, which means there are many different problems to consider. /Johan (WMF) (talk) 08:00, 15 June 2015 (UTC)

• Just to add my 5c, I do remember using a university Internet network a year ago that completely banned HTTPS (so I could use Wikipedia only in HTTP). I do not know the origin of this block (this should be definitely a setting by university network administrator), and I do not know if that block is still there (I haven't used it since then), but I would like to inform that such networks do exist, and I don't think there is a way to track them — NickK (talk) 09:16, 15 June 2015 (UTC)

Such networks probably exist, but I think it would be up to the network administrators to whitelist Wikipedia's servers if they believe access to Wikipedia is important. They would probably do it after realizing that it is no longer possible to access Wikipedia on plain HTTP. Tony Tan · talk 05:26, 16 June 2015 (UTC)

If Iran blocks HTTPS, there's no way Wikipedia/WMF will be changing their minds by blocking access to Wikipedia for Iranians through HTTP, which is probably a desirable outcome for the regime anyways. WMF should set up additional HTTP servers for static access to Wikipedia (no-edit access) then with a disclaimer stating that the content may be modified by third party man-in-the-middle vandalism in big banner statements at the top and bottom of every page. -- 70.51.203.69 (talk) 04:44, 17 June 2015 (UTC)

It would be trivial for the men-in-the-middle to remove the disclaimers. (talk to) TheOtherGaelan('s contributions) 06:16, 17 June 2015 (UTC)

Template works on some pages but not others (possible Lua/Wikidata issue?)

Resolved

Template:Tracks Wikidata is a new template I've recently created. It generates a box with a list of Wikidata properties, with Module:Uses Wikidata allowing for unlimited parameters, and pulling the labels for the properties from Wikidata – or the text "NO LABEL" if it can't find a label (usually because the property has been deleted, or has not yet been created). While the template works in the /testcases page, in my sandbox, and Template:Commons category/doc, it is not working for Template:Coord/doc (shows NO LABEL for P625 instead of coordinate location). The Parser profiling data at the bottom of the edit window for Template:Coord/doc doesn't show anything out of range:

• CPU time usage 0.480 seconds
• Real time usage 0.588 seconds
• Preprocessor visited node count 3347/1000000
• Preprocessor generated node count 0/1500000
• Post-expand include size 95745/2097152 bytes
• Template argument size 4020/2097152 bytes
• Highest expansion depth 10/40
• Expensive parser function count 1/500
• Lua time usage 0.141/10.000 seconds
• Lua memory usage 3.96 MB/50 MB

Any idea on what's gone wrong – and why for some pages but not others? - Evad37 [talk] 15:09, 12 June 2015 (UTC)

There was a non-displayed character U+200E (LEFT-TO-RIGHT MARK) at Template:Commons category/doc. I have removed it but it's hard to see what happens in the diff. PrimeHunter (talk) 15:49, 12 June 2015 (UTC)

Thanks PrimeHunter - Evad37 [talk] 23:51, 12 June 2015 (UTC)

Graph extension problems

There seem to be two problems with Graphs. The new template {{GraphChart}} has a number of examples on its documentation page, Template:GraphChart/doc. But none of them appear on the main template page despite being transcluded. Setting up a test at User:JohnBlackburne/GraphTest to try and reproduce this I noticed another problem. That transcludes fine but the animation where e.g. the colours change as you mouse over the chart or part of it only work in preview, not after the page is saved. This is the case on both pages, including where one is transcluded. I tried disabling navigation popups in case that was causing it but it made no difference. I'm using the latest version of Safari in Mac.--JohnBlackburne^words_deeds 19:02, 12 June 2015 (UTC)

The first, I'm not sure why that is. But the latter is intentional. In preview it uses Javascript (also with future live editing in mind for instance), but in content, you only get the image representation (because the JS is slow and adds a lot of bytes to the pages). —TheDJ (talk • contribs) 19:10, 12 June 2015 (UTC)

Renders the JS rather pointless then, if it's only seen when editing. I can see why it would be a performance problem, but could it be made an option? I won't be the last to notice this and wonder why it’s not working.--JohnBlackburne^words_deeds 19:16, 12 June 2015 (UTC)

Ah, purging didn't fix the transclusion but a null edit did; very odd. And the second issue seems to be a will not fix one so this is now resolved.--JohnBlackburne^words_deeds 19:24, 12 June 2015 (UTC)

Render to js happens during preview because there is a limitation in how its implemented, making the static image only work when the page is saved (Not only saved, also the most recent version). Similarly, if your viewing the graph of an old revision of the page, the graph won't work unless the image happens to be cached. Bawolff (talk) 22:29, 12 June 2015 (UTC)

I see. The problem is it’s not just rendering to JS but doing mouseover based highlighting/animation. It’s a problem as I’m sure I won’t be the first person to see this and wonder why it’s working in preview and not once saved. If there is no way to make it an option then it would probably be best to disable the animation code altogether, so preview returns to being WYSIWYG at least for this feature.--JohnBlackburne^words_deeds 23:39, 12 June 2015 (UTC)

 JohnBlackburne: A bit of context, this new extension was imported from the German Wikipedia. The Germans also have a map template that I can't seem to import the JSON file for, so I left it alone for now. Yurik pointed out on my talk page that, in the absence of the should-have-happened-ages-ago interwiki transclusion feature, the best solution for the quickly oncoming onslaught of template sprawl is the creation of a bot that copies all of the templates' content every once in a while from a master template somewhere: either on MediaWiki or on Meta. I am afraid that it is unlikely that someone will be found to do it fast enough, before the organic growth Wikipedia is so famous for smothers us all in the heat death of yet another thousand modules and templates on the various wikis all maintained independently but doing the same damn thing. ResMar 03:50, 13 June 2015 (UTC)

Don't hold your breath for interwiki transclusions. People have been talking about it since forever (There was even a gsoc project in 2010), and so far we are nowhere closer to having it then we ever were before. Bawolff (talk) 05:20, 13 June 2015 (UTC)

A framework bot is something that can be written, however. It just takes someone with a few days of free time and some experience with Labs to do the work. ResMar 13:40, 13 June 2015 (UTC)

The behavior seems to be coming from the graph extension's caching mechanism. If you look at the generated image URLs you will notice that they follow the name scheme "<name of transcluding page>/<ID>.png" for whatever reason as <ID>.png should just suffice. Therefore if a page A transcludes a template B with a graph image, it expects the image at A/<ID>.png but there was only an image generated for B/<ID>-png. If make a null edit at A the graph extension is then forced to generate the A/<ID>.png. --Mps (talk) 16:28, 13 June 2015 (UTC)

This should not be too much of a problem. It probably happened with the template as it was created first: seems I’m not the only one who puts the {{documentation}} link in a template then follows it to complete documenting it. Normally for transcluded templates the template will be made first. It will mean a lot of redundancy though with one copy of the image for every time the template is transcluded. Plus it will still break with changes to templates, especially adding a graph.--JohnBlackburne^words_deeds 16:47, 13 June 2015 (UTC)

Please file a bug report in [5]] on this problem. —TheDJ (talk • contribs) 17:04, 13 June 2015 (UTC)

Redlinks on Mobile Wikipedia

It appears that the mobile version of Wikipedia now shows redlinks. 2602:306:B8E0:82C0:2CB0:1CEE:A64E:B143 (talk) 01:46, 13 June 2015 (UTC)

bug report: wikipedia doesn't work on a browser without ssl support

bug report: wikipedia doesn't work on a browser without ssl support — Preceding unsigned comment added by 98.222.56.172 (talk) 13:41, 13 June 2015 (UTC)

It's not a bug, but intentional. On a related note, you should really stop using browsers that don't support SSL/TLS. —TheDJ (talk • contribs) 15:11, 13 June 2015 (UTC)

Where do you find a browser without SSL support these days? The only program I could find which didn't support SSL was Wget on my phone, although Wget supports SSL on my computer. --Stefan2 (talk) 22:39, 13 June 2015 (UTC)

MediaWiki:Visualeditor-quick-access-characters.json

I don't know if this the correct place (if not please point me to the proper one), but I want do update the VisualEditor special character list with typographic quotation marks so that users can more easily use them.

For this MediaWiki:Visualeditor-quick-access-characters.json would need to be extended with the following lines which however requires admin permissions:

    "“”": {
        "action": {
            "type": "encapsulate",
            "options": {
                "pre": "“",
                "post": "”"
            }
        }
    },
    "‘’": {
        "action": {
            "type": "encapsulate",
            "options": {
                "pre": "‘",
                "post": "’"
            }
        }
    }

Could someone with the proper permissions include this snippet? --Mps (talk) 16:16, 13 June 2015 (UTC)

@Mps: Wikipedia:Manual of Style#Quotation characters says that typographic quotes are "not recommended for Wikipedia", so until that is changed I don't think we should encourage editors to use them. -- John of Reading (talk) 17:00, 13 June 2015 (UTC)

@Mps: Moreover, these characters were removed from MediaWiki:Gadget-charinsert-core.js in September 2012, as a part of this discussion. --Redrose64 (talk) 08:35, 14 June 2015 (UTC)

Thank you both for the information. --Mps (talk) 09:40, 14 June 2015 (UTC)

false positive reports not being handled

I tried removing " (see locking nuts)" on Nyloc nut. The edit filter blocked me. I already reported this on the false positives forum (WP:FALSEPOS). Nothings been done. Why?96.52.0.249 (talk) 16:20, 13 June 2015 (UTC)

When did you report it? I don't see a report on that page or in your contributions history. RudolfRed (talk) 00:20, 16 June 2015 (UTC)

The report was posted on May 30. It was archived (unanswered) on June 13. DH85868993 (talk) 04:14, 16 June 2015 (UTC)

revision history statistics

hi...I know I come here often for the same reason, however if im not mistaken the link is down again, thank you --Ozzie10aaaa (talk) 17:03, 13 June 2015 (UTC)

@Ozzie10aaaa: Could you provide a link to that the "link" please? :) --AKlapper (WMF) (talk) 06:26, 15 June 2015 (UTC)

[6]AKlapper (WMF) heres the link --Ozzie10aaaa (talk) 09:02, 15 June 2015 (UTC)

Self redirect when retrieving https pages?

Hi all, am trying to retrieve a page for my nearest photographer tool (source). It worked like a charm some days ago, but the (apparantly with that switch to https only) it doesn't anymore.

I'm tying to retrieve page source code by this http request

GET https://en.wikipedia.org/w/index.php?action=raw&title=Wikipedia%3AWikipedians%2FPhotographers HTTP/1.0
Host: en.wikipedia.org 
User-Agent: script by de_user_Flominator

My answer looks like this:

HTTP/1.1 301 TLS Redirect
Server: Varnish
Location: https://en.wikipedia.org/w/index.php?action=raw&title=Wikipedia%3AWikipedians%2FPhotographers
Content-Length: 0
Accept-Ranges: bytes
Date: Sat, 13 Jun 2015 17:08:42 GMT
X-Varnish: 1491317678
Age: 0
Via: 1.1 varnish
Connection: close
X-Cache: cp3031 frontend miss (0)
Set-Cookie: GeoIP=DE::51.0000:9.0000:v4; Path=/; Domain=.wikipedia.org
Set-Cookie: WMF-Last-Access=13-Jun-2015;Path=/;HttpOnly;Expires=Wed, 15 Jul 2015 12:00:00 GMT

As far as I got it, that Varnish server redirects me in circles, right? What am I doing wrong?

On de.wp it works fine, there I get a 200 OK header.

Thanks, --Flominator (talk) 17:13, 13 June 2015 (UTC)

Works for me using cURL:

> GET /w/index.php?action=raw&title=Wikipedia%3AWikipedians%2FPhotographers HTTP/1.1
> User-Agent: curl/7.37.0
> Host: en.wikipedia.org
> Accept: */*
> 
< HTTP/1.1 200 OK
[...]

Notice the difference in the GET line. It should start with the path, you might be confusing the proxy by also including the protocol and host there. --cesarb (talk) 17:57, 13 June 2015 (UTC)

Works for me, using the full GET link. (Are you sure you are actually connecting on port 443 and encrypting on TLS, instead of just making an HTTP request where the GET line is a full uri with https. For the connection to work, you need a real https connection)

bawolff@Bawolff-L:~$ openssl s_client -connect en.wikipedia.org:443
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[.. certificate omitted..]
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 3658 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: A12E6886D254C01CC094FA3254BD7C774CFAA1C6DBFD0CA2DC7DA4DBEAF4D17B
    Session-ID-ctx:
    Master-Key: 7BA289973BB568325ECAF13803B607441D32C9A56ECB0D7D8B7CB33B315D42B1976582F28228A8972BB278900AA3BA30
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1434215498
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
GET https://en.wikipedia.org/w/index.php?action=raw&title=Wikipedia%3AWikipedians%2FPhotographers HTTP/1.0
host: en.wikipedia.org
user-agent: bawolff-test

HTTP/1.1 200 OK^M
Server: nginx/1.6.2^M
Date: Sat, 13 Jun 2015 18:06:31 GMT^M
Content-Type: text/x-wiki; charset=UTF-8^M
Content-Length: 46877^M
Connection: close^M
X-Powered-By: HHVM/3.6.1^M
X-Content-Type-Options: nosniff^M
Vary: Accept-Encoding^M
Last-Modified: Sun, 07 Jun 2015 10:06:03 GMT^M
X-Varnish: 744213003, 3153064536^M
Via: 1.1 varnish, 1.1 varnish^M
Accept-Ranges: bytes^M
Age: 0^M
X-Cache: cp1066 miss (0), cp1066 frontend miss (0)^M
Strict-Transport-Security: max-age=86400^M
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate^M
X-Analytics: https=1^M
Set-Cookie: WMF-Last-Access=13-Jun-2015;Path=/;HttpOnly;Expires=Wed, 15 Jul 2015 12:00:00 GMT^M
^M
A great many people have contributed photographs to Wikipedia. Many of those photographs were found on the Net; others were created by the Wikipedian. To appear on this list you must be a [[Wikipedia:Wikipedians|Wikipedian]] who has either contributed '''your own work''' to the project or is willing to do so.
[.. rest of response body omitted..]

Bawolff (talk) 18:10, 13 June 2015 (UTC)

p.s. It should be noted, that while it technically works (If you use right port and tunnel over tls), per RFC 1945, you are only supposed to use absolute URI's in the GET line if you are talking to a proxy. Bawolff (talk) 18:25, 13 June 2015 (UTC)

Thanks (also to User:Krenair on IRC): Reason why it worked on de/pl was this. Switched to using file_get_contents() and everything is fine now. --Flominator (talk) 18:57, 13 June 2015 (UTC)

How to question: How to get a list of all .svg files, i.e. their really correct locations, on commons.wikipedia.

Hi! I asked at https://en.wikipedia.org/wiki/Wikipedia:Help_desk first (#commonswiki-20150417-all-titles_contains_names_of_deleted_files), and it was suggested that I best try to ask here. I try here second so.

So I'm searching for all svg-files on wikipedia. While doing this I found out that commonswiki-20150417-all-titles seems to contain deleted files.

For example http://commons.wikimedia.org/wiki/File:34sassinu.svg (I don't know what sort of image that is. Obviously.)

So my questions are:

1. Is there another list-file similiar to commonswiki-20150417-all-titles that contains all deleted files, so I could do a cross check?

2. Is there an all-titles list-file that doesn't contain the deleted files?

3. Bonus question: Some of those files in commonswiki-20150417-all-titles have been renamed. In line with the two first questions: How to find out the current name?

I only want to download the svg-files, and not to download like 250% overload. Out of the 20 files I tried around half were renamed.

And some were deleted. Only around 5 were actually to find under the name given in the all-titles file.

By now I would have been faster if I just grabbed a whole wikipedia-dump. :/ But then that I really don't want to do .

Greetings John — Preceding unsigned comment added by 188.102.69.95 (talk) 18:43, 13 June 2015 (UTC)

Original thread appears to be Wikipedia:Help desk/Archives/2015 June 9#commonswiki-20150417-all-titles contains names of deleted files. --Redrose64 (talk) 11:01, 14 June 2015 (UTC)

AES 256 bit

Is it possible for our servers to use 256 bit AES instead of 128? All the best: Rich Farmbrough, 19:53, 13 June 2015 (UTC).

There's some attacks on AES 256 that suggest AES 256 bit is not really all that much better than 128 bit AES (From what I understand. Not a crypto expert). Bawolff (talk) — Preceding undated comment added 20:06, 13 June 2015 (UTC)

@Rich Farmbrough: I am not an expert either, but it seems like currently the best cipher suite recommended in the industry is ECDHE-RSA-AES128-GCM-SHA256 1, which is what Wikipedia servers are actively preferring right now. After all, we are using 2048-bit RSA asymmetric keys for key exchange, which should be of similar strength to a 112-bit symmetric key. 2 (Less than 128-bit) If someone is able to bruteforce a 128-bit key for AES (which is almost impossible right now), they might as well be able to factor a 2048-bit RSA key and perform a successful Man-in-the-middle attack. Tony Tan · talk 20:58, 13 June 2015 (UTC)

Interestingly that document suggests 15360 bit RSA keys to be equivalent to 256 bits of security. This much data might create difficulties in the TCP/IP window, causing more overhead, but again it might not. It also suggests that 256 128+ bits of security is needed for data that should be secure to 2030. It's certainly an interesting perspective on the security of the sites. All the best: Rich Farmbrough, 00:41, 14 June 2015 (UTC).

The certificate that signs Wikimedia's certificate uses 2048 bit RSA. Using an RSA modulus higher than that is pointless, since then you'd just forge the CA's signature instead. Bawolff (talk) 04:53, 14 June 2015 (UTC)

Doesn't matter. You would have to forge the certificate now for a MITM attack. Compromising the key exchange can be done in (let us say) 2030, when <128 bits of security is considered insufficient. (Perfect forward secrecy key exchanges would defeat this, if we don't have it it might be a better enhancement than forced HTTPS.)

All the best: Rich Farmbrough, 17:44, 15 June 2015 (UTC).
17:44, 15 June 2015 (UTC)

We do indeed use forward secrecy in most cases (It requires the client to support it as well as the server). Bawolff (talk) 21:01, 15 June 2015 (UTC)

@Bawolff: @Rich Farmbrough: It seems like we are using 256-bit ECDH keys for perfect forward secrecy exchanges, which is roughly equivalent to 3072 bits RSA, which provides 128-bits of security. (Which I think is adequate for now.) 1 Also, an attacker would only need to factor a 1024-bit RSA public key to pull off a successful MitM right now, because of the "Equifax Secure Certificate Authority 1024-bit root". 2. But HPKP (public key pinning) would mitigate such an attack, when the WMF implements it. Tony Tan · talk 05:39, 16 June 2015 (UTC)

I think its worth repeating the note on the mozilla page on why they recommend AES 128 over AES 256 - "AES 128 is preferred to AES 256. There has been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks. ". It should be noted that our servers will use 256 bit AES if the user's browser indicates it does not support 128 bit AES. Bawolff (talk) 21:16, 13 June 2015 (UTC)

AIUI a 32 bit phone might not like 256 bit AES, whereas a 64 bit phone will gobble it up. (Some blog about "Password1".) All the best: Rich Farmbrough, 00:44, 14 June 2015 (UTC).

The attacks on AES 256 (that I am aware of) are differential key attacks, provided the RNG generating the session keys is robust, AES 256 should be fine. The concerns over AES 128 (again that I am aware of) relate primarily to quantum computing, which (for reasons I am not aware of) are expected to square-root the difficulty of cracking these types of cyphers, making AES 128 the difficulty of AES 64 without quantum computing.

Thanks for the comments I will read the NIST pdf. All the best: Rich Farmbrough, 00:09, 14 June 2015 (UTC).

This is way out of my expertise, but... If someone had a quantum computer, that could break 128bit AES using Grover's algorithm, it'd need time proportional to 2⁶⁴. To break 2048 bit RSA (which we also rely on), they only need time proportional to 750 2048²*11*log₂(11) = 159608986 ≈ 2²⁷ using Shor's algorithm (If I read the wikipedia article right which I don't actually understand), albeit possibly more qubits. I really don't think we're at the point where we have to worry about practical quantum computers yet. Bawolff (talk) 04:38, 14 June 2015 (UTC)

Why no en-US locale in preferences?

If you go to special:preferences, in the Internationalisation section, in the Language drop-down box, there are three English locales: en, en-GB, and en-CA. A UK user, in this remark in VPProposals, not unreasonably supposed that "en" was being used for American English.

That does not appear to be true — witness the fact that the section is called "Internationalisation" and not "Internationalization". My guess is that the "en" locale was coded first, and spellings simply reflect the preferences of whoever did it; can anyone confirm or deny?

But it is still very strange. Why is there no en-US? Has just no one gotten around to implementing it? Isn't there some prefabricated corpus somewhere that could just be plugged in? We could at a stroke provide "Internationalization" for American users, and remove a perception of American bias on the part of non-American users. --Trovatore (talk) 20:15, 13 June 2015 (UTC)

If anything, they should be getting rid of the options for en-GB and en-CA, not adding more choices. They generate extra work, for no obvious benefit. – iridescent 20:18, 13 June 2015 (UTC)

That's a separate discussion, I think. Having multiple English locales may not add a lot of value, but I think it adds more than having, say Alemannisch or Nordfriisk or Interlingua, which are all current choices. But in any case the original concern was that British and Canadian English are so specified, whereas just plain "English" is apparently American English (even if somewhat imperfectly American, given "Internationalisation"). I agree that that's a problem, and it sort of looks like it might be dealt with at low cost, just by presenting the en locale as en-US in the user interface, without really changing much else. But I know that these apparently simple fixes sometimes turn into huge headaches in implementation, so I'm hoping that someone with MW developer experience can comment. --Trovatore (talk) 21:57, 13 June 2015 (UTC)

EN officially corresponds to United states english. Bawolff (talk) 20:26, 13 June 2015 (UTC)

I did not know that. So then maybe it's as simple as specifying it as "en-US English (United States)" in the UI, and nothing else would actually change? That would address the original complaint. (Still doesn't explain "internationalisation", though.) --Trovatore (talk) 20:29, 13 June 2015 (UTC)

I mean, in mediawiki it officially corresponds to US english (I get yelled at when I accidentally use Canadian english when adding new messages). In terms of official standards, EN means english generically. Edit: Trovatore is correct that all new system messages get added to the en locale by developers, and then translators make the other languages. Occasionally a dev will accidentally use the wrong variant, and occasionally you see people fixing that sort of mistake (e.g. gerrit:51994. Although looking at the code comments, it appears that that is somewhat disputed. I was always told it was supposed to be American English.) Bawolff (talk) 20:30, 13 June 2015 (UTC)

Is there any technical or policy impediment to our locally renaming it as en-US? --Trovatore (talk) 20:34, 13 June 2015 (UTC)

Speaking as a simple, non-technical writer of article content the present situation is confusing. The existence of a simple "English" option is very misleading. I imagine that many people click on "English" and then find that certain words are either spelt oddly or that some of their text spellings when editing are highlighted as being wrong. I cannot be the only person this has happened to. Given that options such as "British English" and "Canadian English" are available on these menus, that there is a simple "English" option renders the menu unsystematic at best. Perhaps the least confusing way to set out such menus would be in the form "English: American", "English: Canadian" etc. That way anyone looking for 'English' will find all available varieties together. Urselius (talk) 20:38, 13 June 2015 (UTC)

Just a side note here — the spellchecking is done by your browser, not by MediaWiki. There's nothing we can do about that; you'll have to adjust your browser settings yourself. --Trovatore (talk) 20:42, 13 June 2015 (UTC)

I see, this isn't entirely clear on the page - I presumed that 'preferences' were 'global'. — Preceding unsigned comment added by Urselius (talk • contribs) 20:52, 13 June 2015 (UTC)

User:Bawolff wrote "I mean, in mediawiki it officially corresponds to US english". Does MediaWiki actually have a document that officially defines this sort of thing? Where?

Even if MediaWiki does have such a definition, conventions adopted by developers who make MediaWiki work are not presented to, or accepted by, end users. So "en - English", when presented to an end user on a menu, means whatever it means in ordinary everyday English. Jc3s5h (talk) 20:39, 13 June 2015 (UTC)

I thought it did, but then I looked and couldn't find any sort of official thing, so maybe I'm wrong. At the very least people are encouraged to use American english in the en locale. Bawolff (talk) 20:41, 13 June 2015 (UTC)

In the coding conventions, it says to use American English - mw:Manual:Coding_conventions#Preferred_spelling. Bawolff (talk) 20:46, 13 June 2015 (UTC)

@Iridescent: I asked about that a few years ago, and (iirc) was told that these English variants were (at least partially) to assist with testing internationalization code, including aspects such as "fallback language".

Aha! Found it, via searching numerous old VP discussions, one linked to mw:Talk:Localisation statistics#en-GB and en-CA - notes, wherein I'd tried to summarize it all, and got 2 replies. Possibly there are some useful points in there, and plans that could come out of it? HTH. Quiddity (talk) 22:04, 13 June 2015 (UTC)

Going back to what Iridescent said: As a general rule, only the 'main variant' gets customized. That means that if you don't use plain "en", then you will miss locally customized messages here, many watchlist and sitenotices, and other information that you may have wanted. Any system that encourages people to move away from the default (e.g., by labeling "en" as being American) will have the unexpected side effect of cutting them off from messages that the community expects them to receive. I know a couple of people do this intentionally, but most don't learn about this side effect until they miss something that was important to them. Whatamidoing (WMF) (talk) 06:04, 14 June 2015 (UTC)

Ah, thanks. I think maybe I had heard something like that before. That certainly does add a wrinkle to the discussion.

It's not really a very satisfying answer, though. As long as we have en-GB and en-CA, some people are going to choose them, and I don't see any warning notice about the "side effect". Should there be a warning when you pick them? Or should we just get rid of them, at least for ordinary users, but let developers keep them for testing purposes? If we got rid of them, then probably we should prevail on MW to drop the "consistency" requirement, and let en be a mix of US and Commonwealth spellings (which it already is; I mentioned the example of "Internationalisation" right on the page we're discussing.) --Trovatore (talk) 06:12, 14 June 2015 (UTC)

It is very unlikely we will get rid of them on the MediaWiki side (Disabling for Wikipedia is a possibility, but MediaWiki is used by lots of groups outside of Wikipedia. Some of them want to use these locales). The real problem here, is that some messages which get modified by Wikipedia should be treated as content language messages on wikipedia, but in the general case are interface messages. We should fix that underlying issue instead of the band-aid of removing some languages (For those not familiar with MW terminology - content language messages are in the locale of the site, interface messages are in the locale of the user's preferences). Bawolff (talk) 06:37, 14 June 2015 (UTC)

Let me rephrase and see if I've got it. If we were able to get all these modified messages (can I have an example of one?) be "content-language messages" rather than "interface messages", then that would mean that a user who picked en-GB would still see them, albeit in MW's version of en, which is American English, or at least American-except-when-it-isn't English?

And then we would be able to relabel en as en-US for Wikipedia?

Without the last part, I don't think it solves the problem as it arose, namely that Commonwealth users see en, en-GB, and en-CA, and think isn't that strange, apparently AmE is now the default English. That would still be true under the hood for the modified messages, but hopefully that's a relatively small subset of messages, and at least it wouldn't be so in-your-face. --Trovatore (talk) 07:01, 14 June 2015 (UTC)

I think that the translations cause notices to go away issue, and EN being really en-US issue, are entirely separate issues. Adding more content langauge messages that people can use to write notices is very easy. Getting EN renamed en-US, or creating en-us as a dummy language in mediawiki is easy technically but probably would involve some politics and lobbying of different people.

For an example of a content message, see MediaWiki:Recentchangestext. Note how the message shows up the same on Special:Recentchanges, no matter if you're viewing it in en, en-gb, or even something obscure like sco. It would be very easy to add a new message named something like watchlist-info, which would be output immediately above where mediawiki:watchlist-details, but instead is a content message so would be unaffected by translations. Bawolff (talk) 02:31, 15 June 2015 (UTC)

MediaWiki:Editpage-head-copy-warn is a good example. Compare that "en" statement against MediaWiki:Editpage-head-copy-warn/en-gb or MediaWiki:Editpage-head-copy-warn/es, which are blank. If you set your language to anything except "en", then you won't see that notice above the editing window (try it in your userspace or an article; I believe that it doesn't appear on talk pages). For a temporary way to see what I mean, open a page, check for the warning, and then change the URL to read "&uselang=es" (to switch to Spanish) and reload the page. Whatamidoing (WMF) (talk) 05:02, 15 June 2015 (UTC)

Any further thoughts on this? If the answer is, "we know it's suboptimal, but we've thought about all possible solutions and they're all worse than the problem, so WONTFIX", then so be it, but I'm not convinced yet that that's the case. --Trovatore (talk) 02:16, 15 June 2015 (UTC)

I remember seeing discussion of a warning (along the lines you mention above) earlier this year; I believe you'll find it in the archives for this page. Whatamidoing (WMF) (talk) 05:02, 15 June 2015 (UTC)

Sorry, I wasn't clear. I suppose the warning thing is a little bit of a problem but I don't consider it very important. The problem I was talking about is that what is just called "English" in the user interface is actually American English (except when it isn't). Can we find a solution to that problem? (Obviously, not by making the same mistake in the other direction.) --Trovatore (talk) 05:08, 15 June 2015 (UTC)

But the language code "en" (see ISO 639-1) isn't "American" English - it's just English: a generic international form. This site is en.wikipedia.org - the English Wikipedia, not the American English Wikipedia. Such differences as there are between this generic English and the American, Australian, British, Canadian, New Zealand, South African etc. forms are really of no great consequence. We can easily gloss over color/colour and other differences as being somewhat minor in the larger scope of things. After all, the language selector at Preferences does not affect article text in any way at all, and it is writing the article text that we should all be concentrating on, not wasting time on how to say tomato. See also Wikipedia:Village pump (technical)/Archive 111#British English / American English converter? Wikipedia:Village pump (technical)/Archive 127#Interface problems and Wikipedia:Village pump (technical)/Archive 133#"Your language setting British English is not recommended." for some of the difficulties caused by having codes for different variants of English. I've also undeleted User:Gadget850/FAQ/Language. --Redrose64 (talk) 12:24, 15 June 2015 (UTC)

Trovatore, I don't know if it's possible to rename this locally (and I doubt that the WMF has a formal policy on the question, although I haven't asked), but I know that in previous discussions, the community here has said that they do not want to do that. If you label it "en-us", then more people will choose something else. The community here wants fewer people to choose something else. Therefore, the community does not want to rename it.

The reason the community wants fewer people to choose a different language is that choosing something else removes local messages. The community does not want to encourage people to remove local messages, even through the indirect method of signalling that 'this English (the one with all the useful local messages) is not the right English for people like you' in the prefs menu. Whatamidoing (WMF) (talk) 15:54, 15 June 2015 (UTC)

So I understood that bit. That's a good reason not to just rename en as en-US without doing anything else. So, what else can we do? Can we fix the issue that prevents people who choose (say) en-GB from receiving local messages?

How about setting it up so that, if there's a local message, even if it's an interface message, then if there's no translation into the individual user's interface language, the system falls back to displaying the local message in the content language? (And then rename en as en-US.) --Trovatore (talk) 17:32, 15 June 2015 (UTC)

That would cause problems with trivial translations. People often set other languages because they have difficulty reading English. They may be coming here and pasting everything into machine translation, or they may be looking for templates to port to another wiki, or whatever. If a non-default language setting gets overriden whenever there is a local translation, then even the most trivial translation change (e.g., from "Discussion" to "Talk" to save horizontal space on the screen) will overwrite the non-English language – all non-English languages, not just the English variants, where the language differences make almost no difference in comprehension at all. Whatamidoing (WMF) (talk) 19:35, 16 June 2015 (UTC)

See also phab:T33874 and Wikipedia:WikiProject User scripts/Scripts/Language Converter. Helder 18:52, 15 June 2015 (UTC)

Question about limit size of featured article

There is a technical limit to a size of a featured article? It is 2 megabytes same? Why? 191.185.218.122 (talk) 22:05, 13 June 2015 (UTC)

Yes, we have the default mw:Manual:$wgMaxArticleSize: 2048 kilobyte = 2 Megabyte. It applies to all pages. PrimeHunter (talk) 00:37, 14 June 2015 (UTC)

Grateful. 191.185.218.122 (talk) 20:14, 14 June 2015 (UTC)

Viewing Fossil Range template

A change was recently made to the {{Phanerozoic 220px}} template so that it uses the Ꞓ symbol (Unicode 792, I believe). This does not display in my browser (Firefox), and it's a template that's very widely used on the pages that I read, so I rather wish that it did. I've tried following the instructions here, but, insofar as I can even understand that page (it's quite poorly written, in my personal opinion) I appear to have done everything requested, and it's not made the slightest bit of difference. So, the question is, is this a widespread problem, or just me, and if the latter, is it possible for me to fix it? There was some brief discussion of the change to "Ꞓ" from the previously used "Є" n the relevant template talk page, which may indicate that the issue isn't entirely unique to me... but how common it is for users in general, I couldn't say. Anaxial (talk) 07:41, 14 June 2015 (UTC)

• Template:Phanerozoic 220px ( | talk | history | links | watch | logs)

The template appears at the top of the infobox in thousands of articles. For example, see Amphibian where "PreꞒ Ꞓ" denote periods under "Temporal range". Prior to the 20 April 2015 edit, that would have displayed as "PreЄ Є". It's fine to use correct Unicode symbols in articles that need to discuss relevant characters, but presenting a box to general readers in these circumstances is not helpful. The correct approach would be to raise the matter at a suitable wikiproject and get consensus about what is needed—try WT:BIOL. Johnuniq (talk) 08:01, 14 June 2015 (UTC)

I just noticed that Cambrian has an endorsement of "barred capital C" ⟨Є⟩, so reverting the change seems desirable, but a note at WT:BIOL may as well happen first. Johnuniq (talk) 08:04, 14 June 2015 (UTC)

Yes, if it isn't just me (or some small minority of readers) then that would be the obvious solution. Thanks. Anaxial (talk) 08:12, 14 June 2015 (UTC)

Belize does not have coordinates via API?

Hi there, when performing this API request, I don't get any coordinates. For Yucatán_Peninsula it works, though. Is this a known bug or something? --Flominator (talk) 14:05, 14 June 2015 (UTC)

Coordinates must be given in the article before they have a chance to appear in the API. There are no coordinates in Belize. Yucatán Peninsula uses {{coord}} in the external links section. PrimeHunter (talk) 15:31, 14 June 2015 (UTC)

Why do countries not use {{coord}}? --Flominator (talk) 16:18, 14 June 2015 (UTC)

Most of them probably do. It was removed in [7] for no apparent reason. We have 4.9 million articles written by tens of thousands of people. It's not possible to do everything identically everywhere. If you want coordinates in an article then just add them. No discussion is required here. PrimeHunter (talk) 16:31, 14 June 2015 (UTC)

Thanks. Did that. Thought there was a consensus about not having coordinates in country articles or something. --Flominator (talk) ~ — Preceding undated comment added 18:08, 14 June 2015 (UTC)

A way to determine the number of files in the history

Is there a non-Javascript method to determine the number of files in a page history? I have a Javascript method for admins that looks like this:

$(".filehistory a").filter(function() {
    return ($(this).attr("href") || "").indexOf("action=delete") > -1;
}).length;

However, I'd prefer a non-Javascript solution because editing the sitewide Javascript is a difficult process. Magog the Ogre (t • c) 01:37, 15 June 2015 (UTC)

It should be noted, that that won't work if there are more than 50 versions of a file. Bawolff (talk) 02:02, 15 June 2015 (UTC)

Personally I think the count of the number of versions a file has, would be the sort of thing that would make sense to add to the ?action=info of a file page. Bawolff (talk) 02:11, 15 June 2015 (UTC)

I am only looking for two or greater. Magog the Ogre (t • c) 05:31, 15 June 2015 (UTC)

In what context? In can be done with the api, e.g. this query shows the two most recent files uploaded at File:Albert Einstein Head.jpg, while the same query for File:Abin Sur character poster.jpg only lists the one existing version. —Cryptic 07:16, 15 June 2015 (UTC)

@Cryptic: um, in the context of a Wikipedia template. So, wikimarkup and/or Lua. Magog the Ogre (t • c) 01:52, 16 June 2015 (UTC)

Search engine problems

I'm having trouble when I type in a missing entry. Rather than the usual "you can start it" it comes up with a red error message "An error has occurred while searching: Search is currently too busy. Please try again later." and doesn't allow me to create it.♦ Dr. Blofeld 09:20, 15 June 2015 (UTC)

Same here. – iridescent 09:22, 15 June 2015 (UTC)

And here. I get a red message: "An error has occurred while searching: Search is currently too busy. Please try again later." This has been going on for more than an hour. Searches for existing pages usually work, but searching for a deleted page (in order to find why it was deleted) consistently gets the error. JohnCD (talk) 09:23, 15 June 2015 (UTC)

Also raised at Wikipedia:Help desk#Drop-down menu of the seach box at 09.03 - Arjayay (talk) 09:41, 15 June 2015 (UTC)

It's affecting all Wikimedia wikis. The Wikimedia operations team is currently trying to solve the problem - that's all I've heard from them so far. Yunshui ^雲_水 09:47, 15 June 2015 (UTC)

Search being down is of course a big problem but if you just want to create a page or see a deletion log then you can for example preview a red link and click it. PrimeHunter (talk) 10:11, 15 June 2015 (UTC)

If you want to actually search the English Wikipedia then you can say site:en.wikipedia.org in Google searches and some other external search engines. Special:Preferences#mw-prefsection-gadgets has the option "Add a selector to the Wikipedia search page allowing the use of external search engines." The selector is only on Special:Search (reached by making any search) and not the search box on every page. PrimeHunter (talk) 10:18, 15 June 2015 (UTC)

Bug report on Phabricator: https://phabricator.wikimedia.org/T102463 85.178.218.39 (talk) 10:52, 15 June 2015 (UTC)

Note that Nik Everett, the WMF search guru, has just restarted the entire search server cluster, which is a pretty serious measure. Operations staff are working hard to resolve the problem. (Nik says he has "been awake for >>24 hours", so he is certainly one very dedicated employee.) — This, that and the other (talk) 10:55, 15 June 2015 (UTC)

Perhaps an admin should modify MediaWiki:Search-error, so that it redlinks to the searched page, so that pages can be created even when search is down? --Yair rand (talk) 11:07, 15 June 2015 (UTC)

I don't understand what you mean, Yair rand. The search function doesn't find nonexistent pages (https://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=bfouesbgusbfouesbgusbfouesbgus will never find anything), so it's rather pointless. Nyttend (talk) 12:47, 15 June 2015 (UTC)

When search works, it includes a message like "You may create the page bfouesbgusbfouesbgusbfouesbgus" (don't remember the exact wording). Dr. Blofeld complained about missing that red link to create a page with the searched name. PrimeHunter (talk) 12:52, 15 June 2015 (UTC)

Yeah, but why go through the hassle of searching for it when you can just change the URL? Much easier to remove everything after /wiki/ and replace it with bfouesbgusbfouesbgusbfouesbgus than to go through Special:Search and hope that it doesn't exist, or hope that it exists, or something else. Nyttend (talk) 12:56, 15 June 2015 (UTC)

Page names need url encoding in the url. That can be difficult for a lot of characters. PrimeHunter (talk) 13:18, 15 June 2015 (UTC)

It appears from translatewiki:MediaWiki:Search-error/qqq that the pagename is not available. But we could give a better message like "The search function is currently down. We are working to get it back as soon as possible." The message is currently called with $1 = "Search is currently too busy. Please try again later", so it displays: "An error has occurred while searching: Search is currently too busy. Please try again later." PrimeHunter (talk) 11:16, 15 June 2015 (UTC)

When I go to [8], I get red text of

(search-error: (cirrussearch-too-busy-error))

Does this help? Meanwhile, I've implemented your suggestion. Nyttend (talk) 12:50, 15 June 2015 (UTC)

Search is back for me! PrimeHunter (talk) 12:55, 15 June 2015 (UTC)

I have deleted MediaWiki:Search-error since search works again, at least for me. When it was down, "(search-error: (cirrussearch-too-busy-error))" for uselang=qqx in the url meant that MediaWiki:Search-error was called with $1 = the content of MediaWiki:cirrussearch-too-busy-error. It wouldn't have helped to make a red link to the searched term, but it could have helped to only display "The search function is currently down" when the software claims the Search-error is cirrussearch-too-busy-error. PrimeHunter (talk) 13:18, 15 June 2015 (UTC)

Category-list comparison

Is there an easy way to take List of foo and Category:Foo and tell which links are in one and not the other? Nikkimaria (talk) 13:45, 15 June 2015 (UTC)

You can do this using the "List comparer" pane in AWB. In either list's dropdown, pick "Links on page". If you've not got AWB, drop me a note on my talk page, and I'll run the tool for you. Alakzi (talk) 15:15, 15 June 2015 (UTC)

Tech News: 2015-25

15:04, 15 June 2015 (UTC)

Editing a page is now faster. This is because some statistics about edit filters were removed

...at the cost of making it harder for sysops to debug filters and detect which ones can be optimized to consume fewer conditions. Helder 15:11, 15 June 2015 (UTC)

Pending Changes Weirdness

When I try to revert pending changes in Vlad the Impaler, I get a message about reverting 667,144,841...? Is something broken with pending changes? ηoian ‡orever ηew ‡rontiers 04:22, 16 June 2015 (UTC)

Search engine still down

I'm getting

An error has occurred while searching: Search is currently too busy. Please try again later.

for all searches, unlike comments further up this page saying the search engine is back up. -- 70.51.203.69 (talk) 04:44, 16 June 2015 (UTC)

Thanks for the report. I increased the priority on phab:T102463 to ensure the issue has the most visibility. --Dan Garry, Wikimedia Foundation (talk) 05:31, 16 June 2015 (UTC)

Confirmed still a problem. Tony Tan · talk 05:43, 16 June 2015 (UTC)

See the thread "Search engine problems" above. --AKlapper (WMF) (talk) 07:55, 16 June 2015 (UTC)

Problem starting previously deleted talk pages

Specifically I can't create Talk:Jay-P and Talk:Marc Latamie. --Racklever (talk) 08:33, 16 June 2015 (UTC)

@Racklever: Yes, that's because they have been WP:SALTed. The second of the two pink boxes (headed "This page has been locked so only some users can create it.") shows the protection log (full logs: Talk:Jay-P; Talk:Marc Latamie). You could ask the protecting admin to unsalt the pages. --Redrose64 (talk) 09:12, 16 June 2015 (UTC)

I've unSALTed them, since the situation has clearly changed since the SALTing (the articles in question were both seleted at the time of the SALTRing of the talk pages, and now they exist). You should have no problem creating these. עוד מישהו Od Mishehu 11:46, 16 June 2015 (UTC)

Thanks --Racklever (talk) 13:14, 16 June 2015 (UTC)

Global contributions account information wrong

My global contributions page has me registered on 16 March 2009 but my first edit seems to have been 10:50, 23 April 2006, which is about right. Any idea why it's wrong? Thanks. Doug Weller (talk) 16:05, 16 June 2015 (UTC)

I don't think that's the date you registered, I think that's the date your account was merged into your SUL. --Floquenbeam (talk) 16:24, 16 June 2015 (UTC)

more detail: When I look at https://tools.wmflabs.org/guc/?user=Doug+Weller, it says "en.wikipedia.org: For Doug Weller (contribs | talk | block log | uploads | logs | filter log) | 138398 edits | SUL: Account attached at 08:27, 16 Mar 2009" (emphasis mine). --Floquenbeam (talk) 16:27, 16 June 2015 (UTC)

Thanks User:Floquenbeam. But my bad, I shouldn't have said global contributions, but "Global account information".[16]. That doesn't give a clue that I was editing before 2009. Or passed my RfA 18 September 2008. I know it says "attached", but it also says "Registered: 08:27, 16 March 2009 (6 years ago)" which the average reader will think means that was when I created my account. Doug Weller (talk) 12:11, 17 June 2015 (UTC)

Incorrect category: Wikipedia pages with incorrect protection templates

Template:R fully protected is listed at Category:Wikipedia pages with incorrect protection templates. It shouldn't be, because the only place that [[Category:Wikipedia pages with incorrect protection templates]] occurs is inside a <includeonly>...</includeonly>. If I edit the page and preview it without changes, it shows Wikipedia pages with incorrect protection templates in the cat box at the bottom; if I remove that category, make no other changes and preview, it doesn't appear in the cat box. It's as though the <includeonly>...</includeonly> is completely ignored. --Redrose64 (talk) 21:08, 16 June 2015 (UTC)

The presense of {{This is a redirect/rcat}} makes the template transclude itself (I haven't examined why), so the <includeonly>...</includeonly> part is activated on the transclusion. PrimeHunter (talk) 22:09, 16 June 2015 (UTC)

I thought that self-transclusion was prohibited by the MediaWiki template parser? --Redrose64 (talk) 23:00, 16 June 2015 (UTC)

WP:TEMPLATE LOOP says: "A template can call itself, but will stop after one iteration to prevent an infinite loop." This for example means a template can transclude examples of use on its own documentation page. The bottom of edit windows have a list "Pages transcluded onto the current version of this page". For Template:R fully protected that list currently includes the page itself. The list is also at "Page information". PrimeHunter (talk) 00:10, 17 June 2015 (UTC)

xTools not working

Both the user edit count and articles history functions of xTools do not seem to be working for me. Does anyone know what the issue is? Buffaboy ^talk 22:36, 16 June 2015 (UTC)

I think it may be the newly enforced HTTPS, but I can't be sure. I'm trying to look into and get help. For the record, if anyone is a strong PHP developer, or has good experience settings up linux servers, we are actively looking for new maintainers! — MusikAnimal ^talk 22:42, 16 June 2015 (UTC)

• MusikAnimal, I talked to YuviPanda this morning and he said it appeared to be because it was moved from trusty to precise and needed to be moved back because it currently isn't coded to work on precise. I'm not sure how to move it back, so if you can do it, that would be great (I'm the PHP guy, not the configuring Ubuntu guy). If not, I'll have Yuvi walk me through it tomorrow. — {{U|Technical 13}} (e • t • c) 23:14, 16 June 2015 (UTC)

Interesting, well thanks for the update and good luck to all involved! Buffaboy ^talk 03:24, 17 June 2015 (UTC)

• Technical 13, it's the other way around. xTools was built for precise, and the move to trusty broke it. I'm trying to find the failing code source so I can get it to work on Trusty, but the code does not allow for easy debugging and the problem seems to be deeply nested somewhere. Somebody shoot me. :-(—^cyberpower_Chat:Online 12:51, 17 June 2015 (UTC)
  • Cyberpower678, my bad - you're right. Just a lot on my mind and I flipped em in my head. Sorry. — {{U|Technical 13}} (e • t • c) 13:21, 17 June 2015 (UTC)
• On the other hand, our custom environment being developed is using precise. If we can recruit some more active users familiar with Linux servers and setting them up, we can get the move started. That should provide xTools with the permanent stability it needs. If you are interested in joining xTools, please shoot me an email.—^cyberpower_Chat:Online 12:54, 17 June 2015 (UTC)

Alignment of image captions in a gallery

Is there a way to left-align image captions in a gallery? The specific gallery in question is at List of census designated places in West Virginia. I tried to use {{align}}, but that wouldn't work. Thanks again. Seattle (talk) 01:01, 17 June 2015 (UTC)

Try this opening gallery tag with the added style= attribute & setting instead....

<gallery mode=packed widths="180px" heights="120px" style="text-align:left;">

... it worked for me. -- George Orwell III (talk) 03:23, 17 June 2015 (UTC)

I documented it. --Redrose64 (talk) 07:21, 17 June 2015 (UTC)

It worked; thanks. Seattle (talk) 08:02, 17 June 2015 (UTC)

Link Colors

I've been fooling around with the CSS to change the color of links. I copied this into my CSS: /* standard link colors */ .mw-body a:link { color: #0645AD; } /* normal unvisited links */ .mw-body a:link:visited { color: #0645AD; } /* visited links */ .mw-body a:link:active { color: #0645AD; } /* active links */ .mw-body a:link.new { color: #CC2200; } /* new links */ .mw-body a:link.interwiki { color: #0645AD; } /* interwiki links */ .mw-body a:link.external { color: #0645AD; } /* external links */ .mw-body a:link.stub { color: #0645AD; } /* hovered links */

.mw-body a:link {color: #0645AD} .mw-body a:visited {color: #0645AD} .mw-body a:hover {color: #0645AD} .mw-body a:active {color: #0645AD}

Now the color of every article title changes. How can I reset this to default or reset everything to the default colors. — Preceding unsigned comment added by LT391 (talk • contribs) 01:03, 17 June 2015 (UTC) LT391 (talk) 02:17, 17 June 2015 (UTC)

Just delete the content from your CSS page. --Edgars2007 (talk/contribs) 06:37, 17 June 2015 (UTC)