Wikitech-l April 2012

wikitech-l@lists.wikimedia.org

152 participants
192 discussions

OAuth
by Petr Bena 30 Apr '12

30 Apr '12

Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis. Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki. Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.

12 27

Cutting MediaWiki loose from wikitext
by Daniel Kinzler 30 Apr '12

30 Apr '12

Hi all. I have a bold proposal (read: evil plan). To put it briefly: I want to remove the assumption that MediaWiki pages contain always wikitext. Instead, I propose a pluggable handler system for different types of content, similar to what we have for file uploads. So, I propose to associate a "content model" identifier with each page, and have handlers for each model that provide serialization, rendering, an editor, etc. The background is that the Wikidata project needs a way to store structured data (JSON) on wiki pages instead of wikitext. Having a pluggable system would solve that problem along with several others, like doing away with the special cases for JS/CSS, the ability to maintain categories etc separate from body text, manage Gadgets sanely on a wiki page, or several other things (see the link below). I have described my plans in more detail on meta: http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler A very rough prototype is in a dev branch here: http://svn.wikimedia.org/svnroot/mediawiki/branches/Wikidata/phase3/ Please let me know what you think (here on the list, preferably, not on the talk page there, at least for now). Note that we *definitely* need this ability for Wikidata. We could do it differently, but I think this would be the cleanest solution, and would have a lot of mid- and long term benefits, even if it's a short term pain. I'm presenting my plan here to find out if I'm on the right track, and whether it is feasible to put this on the road map for 1.20. It would be my (and the Wikidata team's) priority to implement this and see it through before Wikimania. I'm convinced we have the manpower to get it done. Cheers, Daniel

8 16

Bugzilla Weekly Report
by reporter 30 Apr '12

30 Apr '12

MediaWiki Bugzilla Report for April 23, 2012 - April 30, 2012 Status changes this week Bugs NEW : 290 Bugs ASSIGNED : 13 Bugs REOPENED : 29 Bugs RESOLVED : 106 Total bugs still open: 7661 Resolutions for the week: Bugs marked FIXED : 79 Bugs marked REMIND : 0 Bugs marked INVALID : 11 Bugs marked DUPLICATE : 5 Bugs marked WONTFIX : 4 Bugs marked WORKSFORME : 6 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component wikistats 10 Translate 8 ArticleFeedbackv5 7 Git/Gerrit 7 Site requests 5 New Bugs Per Product MediaWiki 32 Wikimedia 22 MediaWiki extensions 52 Datasets 2 Wikimedia Labs 16 Top 5 Bug Resolvers mah [AT] everybody.org 12 jrobson [AT] wikimedia.org 12 maxsem.wiki [AT] gmail.com 8 beau [AT] adres.pl 6 umherirrender_de.wp [AT] web.de 5

1 0

enwiki enotifs come now with a deep link for "unwatching"
by Thomas Gries 29 Apr '12

29 Apr '12

I just wanted to make you aware that enotifs on enwiki (like on dewiki) are now sent with a further "convenience link" in the footer. The link allows mail recipients to easily "unwatch" the page by following the link (if not yet done, users must log in). see https://bugzilla.wikimedia.org/show_bug.cgi?id=36331

1 0

git reading tips
by Thomas Gries 29 Apr '12

29 Apr '12

I like that http://sitaramc.github.com/gcs/index.html and that http://sitaramc.github.com/concepts/detached-head.html

1 0

Git - I just want to pull the HEAD version
by Stephan Gambke 28 Apr '12

28 Apr '12

Ok, I don't get it. All the time I do a pull I get conflicts. Latest just now: CONFLICT (delete/modify): includes/api/ApiTokens.php deleted in HEAD and modified in 4cee7f1bb6f5b40134f211a626fd70504fc216dd. Version 4cee7f1bb6f5b40134f211a626fd70504fc216dd of includes/api/ApiTokens.php left in tree. Also the IDE I use (Netbeans) shows loads of local changes I never did. Can somebody please enlighten me on how to just pull the latest HEAD version, no questions asked?! Thanks, Stephan

3 6

Fwd: Cache hit rate changes - deliberate?
by Harry Burt 28 Apr '12

28 Apr '12

Hey all. Around the time of the 1.19 deployments back in February-time, there was some concern on this list about the downwards spike in the parser cache hit rate, as shown on [1]. There was, however, also evidence that it was returning to "normal" (previous) rates and so the concern dissipated. Contrary to expectation, however, we're now two months on and the new "normal" rates are still significantly below the old "normal" rates (or to put it another way, the miss rate is still considerably higher than it used to be). I confess this is an area I know little about, so I thought I'd just flag it up for review. Regards, Harry (User:Jarry1250) [1] http://bit.ly/JI41CR

1 0

22 new extensions in Git
by Chad 27 Apr '12

27 Apr '12

Hi everyone, I've migrated the 22 extensions that were on the queue today. I set permissions based on the requests--if anything needs adjusting, just let me know. -Chad

3 3

Commits IDs, change IDs, legacy change IDs, oh my!
by Erik Moeller 27 Apr '12

27 Apr '12

Hi all, can we agree on how we want to identify changes - when deploying code - when merging follow-ups - when commenting on bugzilla? Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to see an example of a mix between Gerrit legacy change IDs (integers, as URLs) and commit IDs. For commit messages the recommendation is to use change IDs (as hashes). So this means constant back and forth between different ID types, which is confusing to developers and users. I'm personally not a fan of the Gerrit change-IDs in plain form, because I can't use them with commands like 'git log' or 'git show' without grepping through commit messages. They tie us pretty heavily to Gerrit as the gateway to all info as opposed to using Git's native lookup capabilities. One proposal: - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to un-merged commits - Commit SHA-1s for deployment log entries and follow-ups to merged commits Rationale: - A Gerrit URL helps others skip past the fragile Gerrit search and go right to the relevant change. This gives them access to change-ID, SHA-1s, and anything else they may need. It's appropriate when you're likely to need to go into the full context of a change. - A SHA-1 gives you instant visibility to the code in your repo without having to use Gerrit as an intermediary, or having to do slow searches of your commit messages for a change-ID. Just do 'git show'. Git intelligently parses abbreviated hashes as well. It's appropriate when you're past the point of code review and are just referring to a change that's sitting somewhere in the repo. This is just one possible approach, and I'm sure this is something we can argue about endlessly. I don't much care what pattern we adopt, as long as it's reasonably consistent, especially for deployment log entries and follow-ups. Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

7 6

@param documentation
by Jeremy Postlethwaite 27 Apr '12

27 Apr '12

Hello! In the Mediawiki coding conventions section on PHP, the format for @param tag is not what Doxygen recommends. http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Comments_and_Do… We have: General format for parameters is such: @param $varname [type]: [description]. Multiple types can be listed by separating with a pipe character. I added a note in the document: Doxygen documentation states that @param should have the same format as phpDocumentor[1]<http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#cite_note-0> : @param datatype1|datatype2 $paramname description How should we deal with this? Thanks. -- Jeremy Postlethwaite jpostlethwaite(a)wikimedia.org 415-839-6885 x6790 Backend Software Developer Wikimedia Foundation <http://wikimediafoundation.org/>

7 8

Jump to page:

2026

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 April 2012