Wikitech-l September 2008

wikitech-l@lists.wikimedia.org

85 participants
73 discussions

Wiki-to-Print: mwlib and Collection extension
by Johannes Beigel 29 Sep '08

29 Sep '08

Hello. As the testing of the wiki-to-print project (see WMF press release http://wikimediafoundation.org/wiki/Wikis_Go_Printable) is currently in progress on labs (http://en.labs.wikimedia.org/wiki/Main_Page, http://de.labs.wikimedia.org/wiki/Hauptseite), I'd like to tell you a bit about the project to open up the topic to a broader audience. The goal of the wiki-to-print project is to add a high quality print and export facility to the MediaWiki. Users can easily collect wiki articles which are rendered as PDFs (or OpenDocument Text, Docbook, XHTML; more formats possible) or sent to print-on-demand services. The two OpenSource software parts used to realize this functionality are * the Python packages mwlib and mwlib.rl (http://code.pediapress.com/mwlib , http://code.pediapress.com/mwlib.rl) that contain a MediaWiki wikitext parser, tools to fetch articles/images/templates via MediaWiki API and several writers that render documents in different formats. * and the Collection extension (http://www.mediawiki.org/wiki/Extension:Collection) -- a MediaWiki extension that allows collecting of articles, saving/loading them as regular wiki pages, rendering documents in PDF or another format and ordering printed books from a print on demand partner like PediaPress. We have a mailing list (http://groups.google.com/group/mwlib) and a wiki + bug tracker (http://code.pediapress.com). If you have specific suggestions or problems feel free to discuss on that list or create tickets. In coordination with Erik Möller and Brion Vibber, we are looking forward to a soonish deployment on Wikibooks and eventually on Wikipedias. Probably lots of you have their own MediaWiki installations. We invite you to try out the Collection extension: If you have a low-traffic wiki, you don't even have to install any Python software, because you can use the public render server (which is configured by default). Just make sure that your wiki is reachable from the outside internet and has api.php enabled. -- Johannes Beigel

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [41222] trunk/phase3/includes
by Aryeh Gregor 28 Sep '08

28 Sep '08

On Wed, Sep 24, 2008 at 5:44 AM, <tstarling(a)svn.wikimedia.org> wrote: > Revision: 41222 > Author: tstarling > Date: 2008-09-24 09:44:45 +0000 (Wed, 24 Sep 2008) > > Log Message: > ----------- > Fixes for r41154 and r41155: > * Boolean parameters are widely accepted to reduce readability. Replaced the new boolean parameters with class constant parameters instead. I thought you said you preferred literal strings to class constants.

4 8

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [40209] trunk/phase3
by Aryeh Gregor 28 Sep '08

28 Sep '08

On Fri, Aug 29, 2008 at 4:35 AM, <tstarling(a)svn.wikimedia.org> wrote: > Revision: 40209 > Author: tstarling > Date: 2008-08-29 08:35:00 +0000 (Fri, 29 Aug 2008) > > Log Message: > ----------- > * Fixed intermittent deadlock errors involving objectcache table queries. Use a separate database connection for the objectcache table to avoid long-lasting locks on that table. > > Modified Paths: > -------------- > trunk/phase3/RELEASE-NOTES > trunk/phase3/includes/BagOStuff.php This broke parser tests for me: This is MediaWiki version 1.14alpha. Reading tests from "maintenance/parserTests.txt"... A database query syntax error has occurred. The last attempted database query was: "SELECT value,exptime FROM `parsertest_objectcache` WHERE keyname='wikidb-parsertest_:messages:en'" from within function "MediaWikiBagOStuff::_doquery". MySQL returned error "1146: Table 'wikidb.parsertest_objectcache' doesn't exist (localhost)"

1 0

Page saving slowness and some loading breakage today
by Brion Vibber 26 Sep '08

26 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Posted this summary on blog, going out to en.planet.wikimedia.org... http://leuksman.com/log/2008/09/24/why-is-everything-broken-this-week/ We’ve tracked down today’s problems to a combination of a couple of things: 1. There’ve been ongoing database locking issues with the site statistics updates — these would all block on each other, making page saves very slow at times 2. … which held open database connections, causing the text storage servers to start locking out new connections … 3. … which exacerbated problems with the failover behavior of recent changes to the storage and load balancing code. The code changes have been rolled back, fixing the slow site load behavior. (doing this correctly unfortunately was a bit painful, as we had to restore the broken code for a while in order to pick out what was going on enough to fully revert it again.) Domas believes the main culprit on the database locking is actually an issue with our mail server — some actions (such as creation of new accounts) would involve both mail and updates to the site statistics table. With overload to the mail server, and a very simple local mail client called from MediaWiki, the outgoing mail would sometimes hang, while the transaction was still open, causing the locks, causing other updates to stall. As a temporary measure I’ve disabled the site stats updates, fixing the failures on page save. (They’ll need to be re-updated after we’ve totally resolved it.) We’re looking at the way the mail servers are set up to see if we can ensure that internal connections don’t stall the way they were; we should also be able to rearrange the transactions so that things are committed before the mail goes out! - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjamZsACgkQwRnhpk1wk45STQCfTkw4Goq2N96nj5uSYSMLoJ/G z6gAnicZzMjlVbaVUxtNGt8Rkgyd/yui =aEqy -----END PGP SIGNATURE-----

6 11

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [41244] trunk/phase3/includes
by Voice of All 26 Sep '08

26 Sep '08

Unless strong comparisons are used (none did in the r41244 fixes) by functions that check the value of doEdit(), then r41198 wouldn't affect, or "break", them. This is because it returns 0 instead of false, and an integer > 0 instead of true. -- View this message in context: http://www.nabble.com/Re%3A--MediaWiki-CVS--SVN%3A--41244--trunk-phase3-inc… Sent from the Wikipedia Developers mailing list archive at Nabble.com.

2 1

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [41248] trunk/phase3
by Matt Johnston 25 Sep '08

25 Sep '08

It was suggested me to do it that way on IRC, I can't remember who by. I'll change it now (so that that variable only makes the checkbox enabled) -Matt -------------------------------------------------- From: "Chad" <innocentkiller(a)gmail.com> Sent: Friday, September 26, 2008 1:44 AM To: <wikitech-l(a)lists.wikimedia.org> Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [41248] trunk/phase3 > On Thu, Sep 25, 2008 at 7:45 AM, <mattj(a)svn.wikimedia.org> wrote: > >> Revision: 41248 >> Author: mattj >> Date: 2008-09-25 11:45:26 +0000 (Thu, 25 Sep 2008) >> >> Log Message: >> ----------- >> (bug 8440) Allow preventing blocked users from editing their talk pages >> * Adds database field to ipblocks table, ipb_allow_usertalk, storing >> whether or not the user can edit their own talk page. Defaults to 0 to >> coincide with the default value of $wgBlockAllowsUTEdit. >> * Recommended to update all current blocks to have a allow_usertalk value >> of whatever the current setting is >> * Retasks $wgBlockAllowsUTEdit to be the default value of the field in >> the >> blocking screen - unless a sysop changes the checkbox, will use whatever >> that variable is set to. >> >> > Suggest reverting this. Repurposing $wgBlockAllowsUTEdit is a bad idea > imo. > Sysadmins > who set that to false (ie: not allowing edits) shouldn't expect their > sysops > to be able to > override that (which they now can). > > -Chad > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

1 0

inprop=readable (Re: [MediaWiki-CVS] SVN: [41261] trunk/phase3)
by Bryan Tong Minh 25 Sep '08

25 Sep '08

On Thu, Sep 25, 2008 at 5:55 PM, <catrope(a)svn.wikimedia.org> wrote: > Revision: 41261 > Author: catrope > Date: 2008-09-25 15:55:09 +0000 (Thu, 25 Sep 2008) > > Log Message: > ----------- > (bug 15609) Add inprop=url (full URL to page and edit form) and inprop=readable (whether the current user can read the page) to prop=info > If a user has insufficient permissions to read a page, he should not be able to fetch any information at all about it I think. Bryan

6 7

Problem in installing WhiteList extension
by madn002 madn002 25 Sep '08

25 Sep '08

Hi, I tried to install WhiteList Extension and got the following message. Warning: Invalid argument supplied for foreach() in \mediawiki\includes\MessageCache.php . Has anyone got the same problem or can help me to sort out. I am using MediaWiki 1.13 Regards Mehnaz

1 0

Python exception handling ([MediaWiki-CVS] SVN: [41218] trunk)
by Bryan Tong Minh 25 Sep '08

25 Sep '08

On 9/24/08, tstarling(a)svn.wikimedia.org <tstarling(a)svn.wikimedia.org> wrote: > Revision: 41218 > Author: tstarling > Date: 2008-09-24 08:17:35 +0000 (Wed, 24 Sep 2008) > > Log Message: > ----------- > * Add a simple log demultiplexer, written in python, for low-volume MediaWiki logs > * in wfErrorLog(): clean up log text so that it works properly with the multiplexer > > Modified Paths: > -------------- > trunk/phase3/includes/GlobalFunctions.php > > Added Paths: > ----------- > trunk/udplog/demux.py > > + > + try: > + (name, text) = line.split(" ", 1) > + except: > + # No name > + continue The proper way is to catch the real error (ValueError) or even check whether there is a whitespace in the string: if " " not in line: continue > + except: > + # Exit if it was a ctrl-C > + if sys.exc_info()[0] == 'KeyboardInterrupt': > + break better use: except (KeyboardInterrupt, SystemExit): break except: ... Bryan

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [41248] trunk/phase3
by Chad 25 Sep '08

25 Sep '08

On Thu, Sep 25, 2008 at 7:45 AM, <mattj(a)svn.wikimedia.org> wrote: > Revision: 41248 > Author: mattj > Date: 2008-09-25 11:45:26 +0000 (Thu, 25 Sep 2008) > > Log Message: > ----------- > (bug 8440) Allow preventing blocked users from editing their talk pages > * Adds database field to ipblocks table, ipb_allow_usertalk, storing > whether or not the user can edit their own talk page. Defaults to 0 to > coincide with the default value of $wgBlockAllowsUTEdit. > * Recommended to update all current blocks to have a allow_usertalk value > of whatever the current setting is > * Retasks $wgBlockAllowsUTEdit to be the default value of the field in the > blocking screen - unless a sysop changes the checkbox, will use whatever > that variable is set to. > > Suggest reverting this. Repurposing $wgBlockAllowsUTEdit is a bad idea imo. Sysadmins who set that to false (ie: not allowing edits) shouldn't expect their sysops to be able to override that (which they now can). -Chad

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