Wikitech-l September 2010

wikitech-l@lists.wikimedia.org

102 participants
96 discussions

Static dump of German Wikipedia
by Marco Schuster 24 Sep '10

24 Sep '10

Hi all, I have made a list of all the 1.9M articles in NS0 (including redirects / short pages) using the Toolserver; now I have the list I'm going to download every single of 'em (after the trial period tonight, I want to see how this works out. I'd like to begin with downloading the whole thing in 3 or 4 days, if noone objects) and then publish a static dump of it. Data collection will be on the Toolserver (/mnt/user-store/dewiki-static/articles/); the request rate will be 1 article per second and I'll download the new files once or twice a day to my home PC, so there should be no problem with the TS or Wikimedia server load. When this is finished in ~ 21-22 days, I'm going to compress them and upload them to my private server (well, if Wikimedia has an archive server, that 'd be better) as a tgz file so others can play with it. Furthermore, though I have no idea if I'll succeed, I plan on hacking a static Vector skin file which will load the articles using jQuery's excellent .load() feature, so that everyone with JS can enjoy a truly offline Wikipedia. Marco PS: When trying to invoke /w/index.php?action=render with an invalid oldid, the server returns HTTP/1.1 200 OK and an error message, but shouldn't this be a 404 or 500? -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de

1 0

MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
by Rob Lanphier 23 Sep '10

23 Sep '10

On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride <z(a)mzmcbride.com> wrote: > Quite a few people are under the impression that MediaWiki 1.17 will be > released in October or November of this year. I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. The goal, as I recall, was branching October 15 or thereabouts, with first beta in November, and a release sometime after that (perhaps as late as January, depending on how well we do with the first beta). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. Rob

16 30

API architecture
by Dmitriy Sintsov 23 Sep '10

23 Sep '10

Hi! I am developing my API extension. It's enumerating revisions, but in a different way (not like in ApiQueryRevisions class). Also, it can optionally create xml dumps via WikiExporter, like API action=query&export&exportnowrap (so I need to change output printer to raw mode sometimes). Because it's enumerating the lists (however not titles) I've choosed "list in non-generator mode" (derived from ApiQueryBase). However, after initial development I've figured out that I cannot change default printer in such case, because it's not being called at all. The reason is explained in following message by Roan Kattouw: https://bugzilla.wikimedia.org/show_bug.cgi?id=25232 > Query submodules can be called in conjunction with other query submodules > In this case, if your module would switch to a custom printer, the others would quite likely freak out. But, I don't need to query in conjunction. Ok, I've derived from ApiBase class (my own API action). Then, it starts to fail on huge amount of generally useful methods, like SQL query building methods (addJoinConds, addWhereRange) and list continuation methods (setContinueEnumParameter), because these are not defined in ApiBase. I understand that not every ApiBase derived class needs these, but many could have. Why not make inheritance chain like this: ApiBase -> ApiListBase -> ApiQueryBase where ApiListBase would have at least these nice SQL query buliding methods but also the possibility to override the default printer? Why these methods are limited to action=query lists and generators only? Dmitriy

3 7

Slow file downloads from commons...
by Paul Houle 23 Sep '10

23 Sep '10

Right now I'm seeing that image downloads on wikimedia commons have slowed down by a factor of ten or so since the last weekend. I used to download about 700 images an hour, so it's possible that my bandwidth is being throttled, but it might be something affecting other people too. Something I notice is that sometimes I can download a file very quickly: [paul@haruhi ~]$ curl -O http://upload.wikimedia.org/wikipedia/commons/7/7b/Barabinsk_station1.jpg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 807k 100 807k 0 0 797k 0 0:00:01 0:00:01 --:--:-- 863k ---------------- Then sometimes the download takes orders of magnitude longer: [paul@haruhi ~]$ curl -O http://upload.wikimedia.org/wikipedia/commons/7/7b/Barabinsk_station1.jpg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 807k 100 807k 0 0 16431 0 0:00:50 0:00:50 --:--:-- 14436 ---------------- I'm wondering if there's some specific problem here, if I'm being throttled, or if there's just a general need for more bandwidth & servers. In any case I'd be pretty happy to make a donation that would cover any operational costs that my activities incur and then some.

1 0

Re: [Wikitech-l] Problem with maintenance/dumpBackup.php
by Chad 22 Sep '10

22 Sep '10

My fault. Will apply as soon as I get in front of a computer if no one beats me to it. On Sep 22, 2010 9:43 AM, "Asia Jedrzejewska-Szmek" <asia(a)fuw.edu.pl> wrote: The script to dump pages fails with the following error: zbyszek@escher:/srv/www/eduwiki$ sudo -u www-data php maintenance/dumpBackup.php --full > /tmp/dump-full2 PHP Fatal error: Call to undefined method DumpFilter::DumpFilter() in /home/srv/mediawiki/mediawiki-trunk/maintenance/backup.inc on line 306 This behaviour is the same in 1.16-wmf4 and trunk@72382. This is easily corrected with the following patch: diff --git a/maintenance/backup.inc b/maintenance/backup.inc index 9b2ff89..88da915 100644 --- a/maintenance/backup.inc +++ b/maintenance/backup.inc @@ -303,7 +303,7 @@ class BackupDumper { class ExportProgressFilter extends DumpFilter { function ExportProgressFilter( &$sink, &$progress ) { - parent::DumpFilter( $sink ); + parent::__construct( $sink ); $this->progress = $progress; } HTH, Asia Jedrzejewska-Szmek _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 1

Problem with maintenance/dumpBackup.php
by Asia Jedrzejewska-Szmek 22 Sep '10

22 Sep '10

The script to dump pages fails with the following error: zbyszek@escher:/srv/www/eduwiki$ sudo -u www-data php maintenance/dumpBackup.php --full > /tmp/dump-full2 PHP Fatal error: Call to undefined method DumpFilter::DumpFilter() in /home/srv/mediawiki/mediawiki-trunk/maintenance/backup.inc on line 306 This behaviour is the same in 1.16-wmf4 and trunk@72382. This is easily corrected with the following patch: diff --git a/maintenance/backup.inc b/maintenance/backup.inc index 9b2ff89..88da915 100644 --- a/maintenance/backup.inc +++ b/maintenance/backup.inc @@ -303,7 +303,7 @@ class BackupDumper { class ExportProgressFilter extends DumpFilter { function ExportProgressFilter( &$sink, &$progress ) { - parent::DumpFilter( $sink ); + parent::__construct( $sink ); $this->progress = $progress; } HTH, Asia Jedrzejewska-Szmek

1 0

Sites using InstantCommons (was: wikimedia commons slow lately?)
by Erik Moeller 22 Sep '10

22 Sep '10

2010/9/21 David Gerard <dgerard(a)gmail.com>: > Is this the problem that broke InstantCommons for pretty much everyone > a few days ago? Unless there's another obvious source of this information, I think it would be useful for folks using the InstantCommons feature to be included in a public list somewhere -- I just started such a list here: http://www.mediawiki.org/wiki/Sites_using_InstantCommons I think this would help to create more visibility and awareness for this functionality, and greater sensitivity to accidental breakage. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

3 2

wikimedia commons slow lately?
by Paul Houle 22 Sep '10

22 Sep '10

In the last few days I've noticed sporadically that API calls time out on Wikimedia Commons and also that sometimes file downloads from Wikimedia Commons are really slow. Are there any performance problems going on?

4 4

UsabilityInitiative extension is going to die
by Trevor Parscal 22 Sep '10

22 Sep '10

As I mentioned in a prior email, I have been converting UsabilityInitiative/* extensions to work with ResourceLoader, and in the process removing their dependency on UsabilityInitiative.php. Some of these extensions were not really using any functionality in UsabilityInitiative.php, so their "conversion" was more like cleanup and removing a line that included it unnecessarily. The remaining extensions (WikiEditor, Vector, ClickTracking and PrefStats) are now only compatible with MediaWiki 1.17 because they depend on ResourceLoader functionality. I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Please see the README for UsabilityInitiative (http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UsabilityInitiat…) which you will notice ends in calling out that these extensions should be moved. I've already moved Vector and WikiEditor, and the remaining ones will likely be moved soon if there are no objections. This should put the last nail in the coffin for UsabilityInitiative. (the extension that is, the grant has been over for ages!) - Trevor

7 11

Bugzilla Weekly Report
by reporter 20 Sep '10

20 Sep '10

MediaWiki Bugzilla Report for September 13, 2010 - September 20, 2010 Status changes this week Bugs NEW : 83 Bugs ASSIGNED : 9 Bugs REOPENED : 13 Bugs RESOLVED : 58 Total bugs still open: 4901 Resolutions for the week: Bugs marked FIXED : 36 Bugs marked REMIND : 0 Bugs marked INVALID : 8 Bugs marked DUPLICATE : 8 Bugs marked WONTFIX : 3 Bugs marked WORKSFORME : 2 Bugs marked LATER : 1 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 5 DonationInterface 3 General/Unknown 3 SemanticForms 3 UsabilityInitiative 3 New Bugs Per Product MediaWiki 11 Wikimedia 9 MediaWiki extensions 19 Top 5 Bug Resolvers roan.kattouw [AT] gmail.com 7 niklas.laxstrom [AT] gmail.com 7 jeluf [AT] gmx.de 7 tparscal [AT] wikimedia.org 6 innocentkiller [AT] gmail.com 4

1 0

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

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 September 2010