Wikitech-l August 2011

wikitech-l@lists.wikimedia.org

122 participants
122 discussions

Re: [Wikitech-l] Please fix your FIXMEs
by Nikola Smolenski 31 Aug '11

31 Aug '11

On 31/08/11 04:46, Mark A. Hershberger wrote: > As promised on wikitech-l (http://hexm.de/5u), I'm sending email to > all MediaWiki developers with any FIXME'd revisions. I'll be sending > a reminder at least twice a week from now on for any outstanding > FIXMEs. > > Link to all your FIXMEs: > http://mediawiki.org/wiki/Special:Code/MediaWiki/status/fixme?author=nikola > > Rev #: Commit message > r86692: CSS, per http://www.mediawiki.org/wiki/Extension:Interlanguage/WMF_Design_Pass > r74208: Pair to the Interlanguage extension.... > r74204: July 30 2010: Display link(s) to the page(s) on the central wiki with... > > Please address them as soon as possible. When you think you've > addressed one, change its status field from "fixme" to "new" and make > sure your new revision shows up under "Follow-up revisions" > > If you have any questions about this, then please feel free to email > me. I asked Mark already, but he hasn't answered (or at least I haven't noticed his answer), so I guess it is appropriate to ask the questions here. How can I change the status of a revision from fixme to new? And how can I make a revision show up under Follow-up revisions?

9 10

Requesting code review for Extension:SignupAPI
by Akshay Agarwal 31 Aug '11

31 Aug '11

Hi, I am a GSoC'11 student, this summer I have developed Extension:SignupAPI http://www.mediawiki.org/wiki/Extension:SignupAPI with jorm as my mentor. This extension creates a special page that cleans up SpecialUserLogin from signup related stuff, adds an API for signup, adds sourcetracking for account creation & provides Ajax-ified validation for signup form. A few concerns are:- 1) Security over Ajax validation, there was quite some debate over this during project start but a common consensus could not be reached. Therefore, I have made this option user configurable 2) Managing layout with the extra space occupied by the client side validation indicators. Currently, I have added <span> tags for displaying them next to their respective input fields but it is not consistent especially when there are long messages to be displayed. 3) Integration with Clicktracking extension. Can the sourcetracking part of my extension be integrated with clicktracking? Would it offer additional benefits? 4) Integration with core. Currently, my extension supports only MW 1.19, should it also support earlier versions? Would that affect its early adoption into core? What other factors need to be handled before core integration? I am eagerly looking forward to all your comments & suggestions. Overall, working with MediaWiki as my GSoC organisation has been a wonderful learning experience & am excited to continue contributing in the coming days. Thanks to everyone of you who has helped me in making this project a reality! User: Akshay.agarwal

1 0

RFC: Geo RSS for recent changes
by Strainu 31 Aug '11

31 Aug '11

Hi, Just a quick thought about the recent change feed [1]. Wouldn't it be interesting to transform it in a GeoRSS [2]? This would be done by adding the coordinate from the articles, if available, and/or by using rssToGeo [3] where coordinates are unavailable? I'm not necessarily looking to get that included in MediaWiki, but I would like to see if creating a "recent changes on a map" service would be useful to someone. Thanks for your feedback, Strainu [1] http://ro.wikipedia.org/w/index.php?title=Special:Schimb%E3ri_recente&feed=… [2] http://georss.org/Main_Page [3] http://www.geonames.org/rss-to-georss-converter.html

4 4

Removing * {{msg}} support from MediaWiki:Sidebar
by Daniel Friesen 31 Aug '11

31 Aug '11

The current implementation of MediaWiki:Sidebar supports a completely undocumented * {{msg}} syntax. It works along the lines of: * header ** {{msgname}} And ends up with a 'header' section with the parsed contents of MediaWiki:Msgname outputted into it. This feature didn't exist in 1.16, was introduced but was seemingly completely broken in 1.17 and finally made to work in 1.18. However I have a number of issues with it: Conceptually: * The concept makes little sense, it uses the {{}} template syntax, but actually takes a message from the MediaWiki namespace, and it of course doesn't support any real transclusion syntax Implementation: * The implementation is a mess, with successive {{msgname}} calls in the same header replacing rather than appending to, and using a mess of a setup where these blocks are actually put into a separate array which is array_merged into the real sidebar array at the end. But mostly I have a problem with the fact that it's getting in my way. I'm currently trying to fix up the limitation in our skin system that only allows us to sanely have one type of navigation (the sidebar). With the implementation of a new navigation message parser that can handle varying formats of messages. However {{msgname}} is not something that can see be cleanly implemented in it. I'd like to remove this feature from 1.18 before it ends up released and people actually start using this feature in production where we start having to deal with backcompat. Are there any objections to it being removed? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

6 11

Spammers with Google OpenIDs?
by Dan Bolser 30 Aug '11

30 Aug '11

Hi, I installed OpenID to try to keep my wiki as open as possible while hoping to stop spam. (Since the 'human spambot' attack earlier this year, I've changed from my 'captcha all anonymous and no registered edits' strategy). However, I'm now seeing spam from people logging in to my wiki using Google OpenID accounts, e.g. http://metadatabase.org/wiki/User:Mykaila298 How can I report these accounts to Google? I think OpenID is a great way to consolidate identities across multiple wikis, and to identify contributors semi-formally, however, if OpenID providers are easy for spammers to infiltrate, I'll have to rethink the whole approach. Thanks for any suggestions. Dan.

4 3

When the edit counts don't match ... where to check?
by Billinghurst 30 Aug '11

30 Aug '11

I am trying to relate the edit counts at English Wikisource and I am wondering whether one or more of the namespace is not being added to the count. I cannot find where or how one can see the configuration for edit count for the system. I have done some comparisons and do see a discrepancy but cannot find the tool author's (hunting in IRC) to ask questions, so I am coming back to the general forum for info. Tools used * [[Special:Preferences]] [0] --> edit count * vvv's YAEC [1]; and --> edit count and per namespace count * Soxred's editcounter [2] --> edit count and per namespace count (with a live and deleted count) When I do a comparison of the _total_ edit counts [0] = [1] != [2] When I do a sanity check of the tools [1] total != sum [1] of namespace [2] total = sum [2] of namespace (live edits only, not deleted) BUT sum [1] of namepsace = sum [2] of namespace To me the [2] data seems to be correct as it matches the namespace counts, and the totals are correct. This leads me to believe that * [1] total is pulling a separate total count, and not a summed total. * [0] count is wrong, missing data, and one cannot tell from where, so I am presuming that it is missing from omitting one or more namespace pairs As mentioned, I tried to check where one may do some verification, however that is not evident. Some guidance would be appreciated. [1] toolserver.org/~vvv/yaec.php? [2] toolserver.org/~soxred93/pcount/index.php Regards, Andrew PS. I have not done a similar comparison for other wikis, as I thought that I would understand the basics first.

2 1

PHP 5.3.8 (ok)
by Thomas Gries 30 Aug '11

30 Aug '11

for those being interested: MediaWiki trunk works with PHP 5.3.8 (also with Extension:OpenID) # ./configure '--prefix=/usr' '--datadir=/usr/share/php' '--mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/share' '--includedir=/usr/include' '--sysconfdir=/etc' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib64/php/bin' '--with-apxs2=/usr/sbin/apxs2-prefork' '--with-openssl' '--with-bz2' '--with-zlib' '--with-curl' '--with-ldap' '--with-mysql' '--enable-soap' '--enable-mbstring' '--with-xsl' '--enable-calendar' '--with-gd' '--with-iconv' '--with-pspell' '--with-gmp' '--with-mcrypt' '--enable-zip' # make # make install # libtool --finish /usr/local/src/php-5.3.8/libs

2 1

Re: [Wikitech-l] On third-party users of MediaWiki and collaboration with upstream
by Jack Phoenix 29 Aug '11

29 Aug '11

Hi Joachim, thank you for your message. I agree that it'd be brilliant if third-party users wouldn't have to branch MediaWiki for their code! Hiding some things behind a configuration variable, like how Markus suggested, is certainly doable, to an extent. However, there will be things that need to be rethought and maybe even completely rewritten; patches like http://trac.wikia-code.com/changeset/11900/wikia/trunk/includes/api come to mind. Likewise, both Wikia and wikiHow have some custom methods and member variables in some core files, such as includes/User.php; some can be moved to a custom class and/or done via hooks, but there are some things that I'm not too sure of, such as wikiHow's getBotIDs() method in includes/User.php, for example. I actually sent this message to wikitech-l and CC'd various third-party developers on it; I don't know why your message isn't showing up in the wikitech-l archives ( http://lists.wikimedia.org/pipermail/wikitech-l/2011-August/thread.html), though. Like K. Peachey mentioned earlier, using SVN's "external" property might be a good way of including libraries that we don't want to host on svn.wikimedia.org for one reason or another. I'd like to know more about frameworks used by third parties and why you use them. If I recall correctly, wikiHow uses Prototype for some of their JavaScript code, but they're moving towards jQuery. Wikia has various different frameworks (http://trac.wikia-code.com/browser/wikia/trunk/lib) on their SVN, such as phpFlickr, PHPUnit, Stomp and more. One interesting point to consider is the edge case of having to edit library code for some reason. For example, you might need to fix a PHP notice (like what was done in http://trac.wikia-code.com/changeset?new=40808@wikia%2Ftrunk%2Flib%2FHTTP&o…) or even a fatal or something like that. What'd be the best solution in such case? I think that submitting a patch to the upstream developers of the library would be the best approach, obviously, but it might be that some libraries aren't even maintained anymore or the maintainers do not have very much time...maybe then we should note somewhere that you need to patch the code. Let's say that we have an extension called FooBar in svn.wikimedia.org/mediawiki/trunk/extensions/FooBar. It has an external dependency on a library called Baz, which is hosted on Google Code. However, line 15 of Baz's BazClass.php contains code that throws a notice on modern PHP versions. In this case, I'd keep the Baz library as the svn:external of the FooBar extension but I'd add a README to the extension directory, to explain what needs patching in the external library and why and how to apply the patch. On Fri, Aug 26, 2011 at 7:08 PM, Joachim Bode <joachim.bode(a)twoonix.com>wrote: > Hi Jack, hi all, > > I think it is indeed a good idea to provide a possibility for 3rd party > devs to store branches at /mediawiki/branches/. To me the attempt of > creating a way to add additional hooks *without* having to branch, that is > tied to this question, is even more important. I like Markus' idea of a > $wgExecuteExpensiveHooks Setting. > > How about CC-ing the wikitech-l list for this? > > We use GIT internally, but I don't Know about an option that allows for > "hooking" a remote repository. There are hooks, but afaik - like in mw - > only to call e.g. pre and post commit operations. But I doubt that would > make us get rid of the legal aspects anyway. > > For inclusion of frameworks I would prefer providing a framework management > that integrates them in one single location for the whole installation. This > would check for version inconsistencies especially for JS fws and make sure > that the same fw is not stored inside multiple extensions which does not > work for different JS fw versions anyway. > > All the best, > Achim > > > Sent from my iPhone > Thanks and regards, -- Jack Phoenix MediaWiki developer

1 0

please smoketest Kiwix on Ubuntu Linux
by Sumana Harihareswara 29 Aug '11

29 Aug '11

The developers of Kiwix, an offline Wikipedia reader, had a problem in the .deb package of Kiwix 0.9 beta1, as delivered via Ubuntu's Personal Package Archive: Kiwix simply would not launch at all. Emmanuel Engelhart, Kiwix developer, believes his team just fixed it (thanks to some troubleshooting they and I did at Wikimania). Can someone on Ubuntu install Kiwix 0.9 beta2 via the Ubuntu PPA and verify that it launches? http://www.kiwix.org/index.php/Ubuntu_PPA has the directions -- ppa:kiwixteam/ppa is the repository, as you can see on https://launchpad.net/~kiwixteam/+archive/ppa . (And if you're interested in testing Kiwix more thoroughly, you can join the Kiwix testers' mailing list at https://lists.sourceforge.net/lists/listinfo/kiwix-testing . Kiwix is cross-platform and needs testers on Windows, Macintosh & Linux.) -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

3 2

Bugzilla Weekly Report
by reporter 29 Aug '11

29 Aug '11

MediaWiki Bugzilla Report for August 22, 2011 - August 29, 2011 Status changes this week Bugs NEW : 152 Bugs ASSIGNED : 17 Bugs REOPENED : 37 Bugs RESOLVED : 127 Total bugs still open: 5981 Resolutions for the week: Bugs marked FIXED : 82 Bugs marked REMIND : 0 Bugs marked INVALID : 14 Bugs marked DUPLICATE : 8 Bugs marked WONTFIX : 14 Bugs marked WORKSFORME : 5 Bugs marked LATER : 4 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Images and files 6 Collection 3 Mailing lists 3 CodeReview 3 SemanticForms 2 New Bugs Per Product MediaWiki 17 Wikimedia 8 MediaWiki extensions 31 Wikimedia Mobile 2 XML Snapshots 1 Top 5 Bug Resolvers john [AT] compwhizii.net 14 sam [AT] reedyboy.net 12 preilly [AT] wikimedia.org 11 brion [AT] wikimedia.org 8 jeroen_dedauw [AT] yahoo.com 7

1 0

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 August 2011