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
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.
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)"
-----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-----
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.
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
>
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
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
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
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