Wikitech-l February 2015

wikitech-l@lists.wikimedia.org

134 participants
136 discussions

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

New RFC: better JS minification
by Max Semenik 01 Nov '15

01 Nov '15

Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier It is about how we can shave 10-15% off the size if JavaScript delivered to users. Your comments are highly welcome!:) -- Best regards, Max Semenik ([[User:MaxSem]])

9 12

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 11 Aug '15

11 Aug '15

When api.php was basically the only API in MediaWiki, calling it "the API" worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying "the API" is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like "the api.php API". I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

30 38

Re: [Wikitech-l] Bug in the Wikipedia main web page
by Sukyoung Ryu 24 May '15

24 May '15

Thank you for the quick fix! Best, -- Sukyoung On Jan 29, 2014, at 9:55 AM, Nathan wrote: > FYI in case you aren't subscribed to the list. > > ---------- Forwarded message ---------- > From: Yair Rand <yyairrand(a)gmail.com> > Date: Tue, Jan 28, 2014 at 7:25 PM > Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Thank you for pointing out this bug. Your suggested change to > MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki > administrator User:PiRSquared17. > > > On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote: > > > Dear all, > > > > We are researchers at KAIST in Korea working on finding JavaScript bugs in > > web pages. While analyzing top websites from Alexa.com, we found an issue, > > which seems to be a bug, on the Wikipedia main web page (wikipedia.org). > > We would be grateful if you can either confirm that it is a bug and even > > better fix it or let us know what we're missing. > > > > Here's the issue. When a user selects a language in which search results > > are displayed via the language selection button from the Wikipedia main web > > page, the following JavaScript function is executed: > > > > 1 function setLang(lang) { > > 2 var uiLang = navigator.language || navigator.userLanguage, date > > = new Date(); > > 3 > > 4 if (uiLang.match(/^\w+/) === lang) { > > 5 date.setTime(date.getTime() - 1); > > 6 } else { > > 7 date.setFullYear(date.getFullYear() + 1); > > 8 } > > 9 > > 10 document.cookie = "searchLang=" + lang + ";expires=" + > > date.toUTCString() + ";domain=" + location.host + ";"; > > 11 } > > > > Depending on the evaluation result of the conditional expression on line > > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave > > the selected language information on the user's computer through a cookie. > > But we found that the expression, "uiLang.match(/^\w+/) === lang", always > > evaluates to false, which results in that the function always leaves > > cookies on users' computers. We think that changing the contidional > > expression, "uiLang.match(/^\w+/) === lang", to the expression, > > "uiLang.match(/^\w+/) == lang", will solve the problem. > > > > This problem may occur in the main web pages of all the Wikimedia sites. > > Could you kindly let us know what you think? Thank you in advance. > > > > Best, > > Changhee Park and Sukyoung Ryu > > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

3 3

Please Review These Patches
by Tyler Romeo 21 Apr '15

21 Apr '15

I don’t usually email the list for this kind of stuff, but if you have some spare time to test an extension, please check out this patch chain. I’d like to get it merged before May (when they become a year old). In order of dependency: https://gerrit.wikimedia.org/r/132783 https://gerrit.wikimedia.org/r/132784 https://gerrit.wikimedia.org/r/134050 https://gerrit.wikimedia.org/r/134789 https://gerrit.wikimedia.org/r/135597 As a description, these five patches severely refactor Extension:OATHAuth, in hopes that I can try and get it deployed on wiki so that enwiki users can use two factor authentication. Thanks, -- Tyler Romeo 0x405D34A7C86B42DF

2 2

new extension
by Ricordisamoa 18 Apr '15

18 Apr '15

I've written a simple MediaWiki extension that uses an instance of the W3C Validator service (via the Services_W3C_HTMLValidator <http://pear.php.net/package/Services_W3C_HTMLValidator> PEAR package) to validate SVG images hosted on a wiki. It is meant to replace the current system on Commons, that relies on individual contributors adding templates (e.g. InvalidSVG <https://commons.wikimedia.org/wiki/Template:InvalidSVG>) by hand to file description pages. It exposes a simple API (and a Scribunto module as well) to get the validation status of existing SVG files, can emit warnings when trying to upload invalid ones, and is well integrated with MediaWiki's native ObjectCache mechanism. I'm in the process of publishing the code, but have some questions I think the community could help me answer. * Given that the W3C Validator can also parse HTML files, would it be useful to validate wiki pages as well? Even if sometimes the validation errors appear to be caused by MediaWiki itself, they can also depend on malformed templates. * Does storing the validation status of old revisions of images (and/or articles) make sense? * Do you think the extension should use the extmetadata property of ApiQueryImageInfo instead of a its own module? * Is it advisable to store validation data permanently in the database?

3 8

Requiring PHP >= 5.3.3 for MediaWiki core
by Legoktm 07 Apr '15

07 Apr '15

Hi, As part of the librarization project[1], we are planning on taking the CSSJanus library that is currently in includes/lib/ and bringing it in with composer. However, it requires PHP >=5.3.3 in its composer.json[2]. Krinkle has stated[3] that is due to the fact that it has only been tested on 5.3.3 and higher, and it's also what travis-ci provides. After doing some research[4], it appears that we would be dropping support for Ubuntu 10.04LTS, which has security support until April 2015. MediaWiki 1.25.0 is expected to be released in May 2015. Does anyone have any objections to dropping 5.3.2 support? I've uploaded [5] that actually increments the required version number. Thanks, -- Legoktm [1] https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [2] https://github.com/cssjanus/php-cssjanus/blob/master/composer.json [3] https://github.com/cssjanus/php-cssjanus/pull/5#issuecomment-60069126 [4] https://phabricator.wikimedia.org/T839#14160 [5] https://gerrit.wikimedia.org/r/168535

11 14

Our CAPTCHA is very unfriendly
by Jon Harald Søby 17 Mar '15

17 Mar '15

Hi all, My apologies if this is the wrong place to start a discussion on this, but it's a better place than nowhere. I recently took part in two very different Wikipedia workshops -- one in Uganda for schoolchildren aged 14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly obvious barrier of entry that was common for both groups is that the CAPTCHA we use is too freaking hard. The main concern is obviously that it is really hard to read, but there are also some other issues, namely that all the fields in the user registration form (except for the username) are wiped if you enter the CAPTCHA incorrectly. So when you make a mistake, not only do you have to re-type a whole new CAPTCHA (where you may make another mistake), you also have to re-type the password twice *and* your e-mail address. This takes a long time, especially if you're not a fast typer (which was the case for the first group), or if you are on a tablet or phone (which was the case for some in the second group). So I would like to start a discussion about changing to a CAPTCHA that is more user-friendly, and hopefully one that isn't as English/Latin-alphabet-centric as the one we currently use. If Ugandan children and old Norwegian people, which all use the Latin alphabet, have such problems deciphering the CAPTCHA, what about people speaking languages that don't use the Latin alphabet? I would prefer something more simplistic, like some sort of math or image-based CAPTCHA, instead of the current CAPTCHA we use. -- mvh Jon Harald Søby <http://meta.wikimedia.org/wiki/User:Jon_Harald_S%C3%B8by>

28 68

MediaWiki tests will verify the completeness of $wgAvailableRights
by hoo 16 Mar '15

16 Mar '15

Hi Everyone, just wanted to quickly let you know that MediaWiki will verify that extensions register all rights they define in $wgAvailableRights (or using the "UserGetAllRights" hook). To make sure your extension complies with that just add all the rights your extension defines to $wgAvailableRights (which is a simple string[] of theses user rights). This test will be introduced with https://gerrit.wikimedia.org/r/192087 Cheers, Marius

1 1

Changing contentmodel of pages
by Erik Bernhardson 15 Mar '15

15 Mar '15

When ContentHandler support was added to MediaWiki in 2012, the content type and content model of a revision is stored with it. However, the DB tables for WMF wikis did not have the new columns, so $wgContentHandlerUseDB was set to false on our wikis. Eventually the database jobs to add and populate the columns completed, and $wgContentHandlerUseDB has been true on some wikis including mediawiki.org for months. There are several projects that are requesting this be set true everywhere, T51193. However, changing the content model of an existing page is a disruptive change. We added the right `editcontentmodel` without which attempts to change content model through the API or EditPage.php fail. Currently no group (user or bot) has this right. So we think it's OK and safe to enable $wgContentHandlerUseDB on WMF wikis. https://gerrit.wikimedia.org/r/#/c/170129/ is the patch. There are issues with granting the editcontentmodel right, see T85847. The Flow discussion and collaboration software has its own contentmodel. Currently the Flow team changes a talk page to a Flow board by editing a PHP config variable (!), which doesn't scale. (FYI, plans for enabling Flow are at [1], and it is happening slowly.) When we do we archive the existing talk page content. The first change to the status quo is allowing a *new* page to be a Flow board. In particular, the Co-op project[2] wants to provide a Flow board for each new editor who signs up to collaborate with a mentor. This doesn't feel like changing the content model of a page, since there was nothing present before. So Flow has its own right, 'flow-create-board', which we grant to flow-bot group; attempting to add a Flow topic or Flow board header to an non-existent page fails unless the user has this right. The Co-op team will ask the Bot Approval Group on enwiki to grant their bot this right. Eventually we envision having a Special:Flowify page that will let admins turn a page into a Flow board. This will run PHP code to archive the current page, handle redirects, and then create a Flow board revision, etc. This feels like the 'editcontentmodel' right, but it will probably be a more restrictive right, 'flow-flowify'. Daniel Kinzler proposed that we should not grant the editcontentmodel right because any change to content model is a special case that requires smart handling via dedicated PHP code. Which is what Flow is doing for both the Co-op bot and the future Special:Flowify. So is there anything to discuss? :) [1] https://www.mediawiki.org/wiki/Flow/Rollout Relax, is happening slowly. [2] https://en.wikipedia.org/wiki/Wikipedia:Co-op

7 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2015