Wikitech-l December 2014

wikitech-l@lists.wikimedia.org

88 participants
99 discussions

ApiFeatureUsage extension in testing
by Brad Jorsch (Anomie) 23 Dec '14

23 Dec '14

I've just deployed the ApiFeatureUsage extension to Beta Labs for testing. If an API client (e.g. a bot or a user script) sets a unique User-Agent or Api-User-Agent header, a summary of deprecated API features hit by that client may be fetched from Special:ApiFeatureUsage[1] or from the API itself.[2] Please try it out, and report any issues in Phabricator using the MediaWiki-extension-ApiFeatureUsage project. If things look good after testing I'll be looking at getting it deployed to production in the next month or so. [1]: http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiFeatureUsage [2]: http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=query+fe… -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

1 0

update on how to do local testing on WikiGrok
by Ryan Kaldari 22 Dec '14

22 Dec '14

Since https://gerrit.wikimedia.org/r/#/c/180811/ is now merged, the old WikiGrok suggestion data is now obsolete. You'll want to delete the old entries in your wikigrok_questions table and replace them with new ones. The specific changes are that the format version number (wgq_version) has changed from 1 to 2, and the data property in wgq_data called 'property' has been split into 'propertyId' and 'propertyName'. See https://www.mediawiki.org/wiki/Extension:MobileFrontend/WikiGrok#Assign_sug… for an example of the new data format. Kaldari

1 0

Spec for opt-in MediaWiki registration coming
by Mark A. Hershberger 22 Dec '14

22 Dec '14

As a result of the Opt-In RFC[1] and discussion in the RFC meeting earlier this month[2], I will be presenting a draft specification for the feature before the end of the new year. Please see the meeting summary for an overview of what was agreed[3]. I will need (even if I don't remember to request it) some design help for this feature, so lots of comments are encouraged and desired. [1] https://www.mediawiki.org/wiki/Requests_for_comment/Opt-in_site_registratio… [2] http://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.201… [3] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-12-03#… -- Mark A. Hershberger NicheWork LLC 717-271-1084

1 0

template condition performance
by Amir E. Aharoni 22 Dec '14

22 Dec '14

Hallo, The second most popular tempate in the Hebrew Wikipedia is one that inserts the rlm character[1]. It has an optional parameter. If it's used, it inserts the lrm character instead. The condition runs in every transclusion. Running a condition every time seems to me like an unnecessary thing, especially that the parameter is (probably) not used most of the time. It could be avoided by replacing all the instances where that parameter is used by another template that simply inserts the lrm. But maybe it's not actually needed because MediaWiki's caching avoids the performance problem? I'm not much of a performance person, so I'd like the experts' opinion. Thanks. [1] https://en.wikipedia.org/wiki/Right-to-left_mark -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2 1

ResourceLoader module wrapping
by Gergo Tisza 21 Dec '14

21 Dec '14

I am experimenting with catching Javascript errors with raven.js [1] (see the JS error logging RfC [2] for background; see T1345 [3] for a prototype for JS error logging). For various reasons, Javascript does not have a reliable way to install a global exception handler like e.g. PHP does with set_exception_handler(), so the standard way of doing this is to wrap modules into a try-catch block. ResourceLoader already wraps minified scripts with something like mw.loader.implement( "<module name>", function() { <module code> } ); so this could be changed to something like mw.loader.implement( "<module name>", Raven.wrap( function() { <module code> } ) ); That means that the error logging module would have to be loaded by the time other modules are initialized, so I imagine it would have to become a startup module. My questions are: 1. do you see any problems with such a setup? The eventual goal would be to use this on the Wikimedia production cluster. 2. especially, is adding another startup script acceptable? (Adding raven.js to the jquery and mediawiki modules would mean a ~10% size increase.) 3. what would be the proper way of doing this from an extension? Add two new hooks for module wrapping and for defining additional startup modules? [1] https://github.com/getsentry/raven-js [2] https://www.mediawiki.org/wiki/Requests_for_comment/Server-side_Javascript_… [3] https://phabricator.wikimedia.org/T1345

2 2

RT is down now, Phabricator will be down at 00:00 UTC
by Quim Gil 20 Dec '14

20 Dec '14

Hi, the RT migration to Phabricator is starting right now. All the RT queues have been frozen. Please don't send any emails to @ rt.wikimedia.org. This includes access-requests@ and procurement@, the two RT queues that will not be migrated at this point, which will be in read-only mode during the migration. phabricator.wikimedia.org will be down between 00:00 UTC (16:00 Pacific) and 08:00 UTC (00:00 Pacific). In those eight hours, urgent issues which cannot wait should be brought up either on #wikimedia-tech IRC or https://www.mediawiki.org/wiki/Project:Support_desk As soon as Wikimedia Phabricator is back, requests to the Operations team will be submitted through the regular process of creating a task, associating them to the #Operations project. If you really miss sending requests to Ops via email, task(a)phabricator.wikimedia.org including "#Operations" will do the job as well. Even requests sent through the now deprecated @rt.wikimedia.org email addresses will create Phabricator tasks for a while too, but the web UI process is clearly preferred. Remember, the exceptions are access-requests@ and procurement@, which will be migrated at a later stage. The Operations team will be vigilant during the migration (as they usually are, on the other hand). Please contact them only for urgent requests during this period. Thank you very much! PS: we are updating https://www.mediawiki.org/wiki/Phabricator/versus_RT -- you will find all the details documented or linked from there. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 1

Andre's Bugzilla-Phabricator migration analysis
by Quim Gil 20 Dec '14

20 Dec '14

Andre won't tell you, but he wrote this: http://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/ The best in-depth analysis of a Bugzilla to Phabricator migration available in the Internet. Not that there is much competition... I'm sure it will be useful to someone, especially in conjunction with Chase's migration script and the detailed logs and tasks archived. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

5 4

lsearchd/MWSearch EOL at Wikimedia
by Chad 19 Dec '14

19 Dec '14

All, lsearchd/MWSearch has powered Wikimedia search for many now. With the successful deployment of Elasticsearch/CirrusSearch to all wikis we've completed the migration and lsearchd has reached its end of life and is no longer being supported in development or usage. Any 3rd party users of MWSearch are encouraged to use CirrusSearch which attempts to remain largely compatible with behavior in MWSearch. I didn't want to break any gadgets or scripts, so I checked the API logs going back about a month. enwiki, ruwiki and nlwiki still have a bit of traffic using the old search backend so I left them enabled. lsearchd has been disabled on all other Wikimedia wikis though and is now in ops' hands for decomissioning. Once any bot/tool/etc authors using the old search are contacted (and helped, if possible) lsearchd will go away there too. lsearchd is dead. Long live Elasticsearch. -Chad

1 0

Re: [Wikitech-l] Your stand proposal for Wikimedia has been accepted (FOSDEM)
by Quim Gil 19 Dec '14

19 Dec '14

(CCing wikitech-l) Dimitar, this is great news! Second year with a Wikimedia stand. With Wikimedia Belgium officially constituted and conversations started with the Wikimedia Shop, we should have a much better setup this year. We should get other European chapters as well, so they can bring swag and hopefully some volunteer time to take a shift. I have just created two tasks to coordinate Wikimedia's presence in FOSDEM: https://phabricator.wikimedia.org/T84972 is for general coordination. Any wikimedia attending is encouraged to subscribe to this task and use it to stay in touch. https://phabricator.wikimedia.org/T84971 is specifically about organizing the Wikimedia stand. On Wed, Dec 17, 2014 at 3:42 PM, Dimitar Dimitrov < dimitar.dimitrov(a)wikimedia.de> wrote: > > > ---------- Forwarded message ---------- > From: FOSDEM Stands Team <stands(a)fosdem.org> > Date: 2014-12-17 15:35 GMT+01:00 > Subject: Your stand proposal for Wikimedia has been accepted > To: Dimitar Dimitrov <dimitar.dimitrov(a)wikimedia.de> > > Hi Dimitar, > > The FOSDEM stands team is glad to be able to inform you that your request > for a stand for Wikimedia has been accepted. > There will be one table reserved for you. > > You will receive further information about what's expected of you closer > to the event date. > > Looking forward to seeing you at FOSDEM 2015! > > > Kind regards, > > Wynke Stulemeijer > FOSDEM stands team > > > -- > Dimitar Dimitrov > Wikimedian in Brussels > > mobile: +32497720374 > landline: +32 2 540 2483 > Rue du Trône 51 Troonstraat > > *Imagine a world in which every single human being can freely share in the > sum of all knowledge. That's our commitment. Help us with it in the EU! > <http://meta.wikimedia.org/wiki/EU_Policy>* > www.wikimedia.org > > -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

LivePreview's 10th birthday
by Ricordisamoa 19 Dec '14

19 Dec '14

Hi folks! According to the Git log, on December 19, 2004, the 'live preview' functionality made its first appearance in MediaWiki core. (for the record: commit c05eeb66755f74272b4a5f82acc6caaeafc0fb54 <https://git.wikimedia.org/commit/mediawiki%2Fcore/c05eeb66755f74272b4a5f82a…>, Special:Code/MediaWiki/6709 <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/6709>) Imagine how much time it has helped saving since then! Related note: As you may have noticed, its code is currently undergoing a major refactoring. If you can, please take a moment to triage its bugs <https://phabricator.wikimedia.org/T41272> and/or help drafting this RFC <https://www.mediawiki.org/wiki/Requests_for_comment/Live_preview>.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

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 December 2014