[Pkg-mediawiki-devel] Fwd: Re: MediaWiki tarballs and the WMF

Thorsten Glaser t.glaser at tarent.de
Tue Jun 12 07:37:41 UTC 2012


On Mon, 11 Jun 2012, Platonides wrote:

> How are extensions there loaded?

mediawiki-extensions-base ships /etc/mediawiki-extensions/extensions.php
which includes all enabled ones, and is included by the standard MW as
patched in Debian.

> Note:
> http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki-extensions/trunk/sbin/mwenext?view=markup
> should also run update.php in case the new extension needs extra tables.

Hm. How does update.php cope with disabling and enabling extensions
often? I’m enabling a lot of them in the metapackage we use at work,
and disabling them before uninstalling/upgrading just to enable them
again thereafter.

This would *also* need to trigger DB upgrades for things like FF,
so we apparently need to register a non-file interest on the FF
side and trigger that on the mw-extensions side. *sigh* this gets
complicated.

The alternative would be to have the user run update.php themselves;
AFAIK currently the DB upgrade for standalone MW isn’t handled auto‐
matically (did I read that right, Jonathan?) anyway, and FF’s doing
that on every postinst of ff-plugin-mw already, so no worries there.

> >> A supported release shouldn't need any patching...
> > 
> > There’s always distribution-specific patching, but yes, anything
> > other than that should probably sent upstream. I’ve not been the
> > best citizen with that always, especially due to bad experience
> > with other projects.
> 
> Then that would lead to us having a bad experience with Debian :)

Right. I will try to submit more things… unless I get told to replace
our database with a toy again.

> This could be added without much problems. Although 'webdav://' seems a
> candidate to add with it, too. Do you have a RFC number defining the
> protocol?

webdav:// is a candidate, yes, this just hadn’t happened here yet
because we (try to) force https everywhere.

> > ++	'file:',
> What's the advantage of using file://? Many browsers forbid file://
> links from working.

What’s the disadvantage if they forbid it by default? I don’t remember
the specific pages where we used it, in contrast to webdavs:// which
is used a lot here, but we had it once at least… and it would have
worked as otherwise it had not ended up in the patch.

> I don't think it's appropiate to have by default.
> If the wiki really needs them (eg. they use file:// to link to a shared
> mount point)

Ah, I think the shared mountpoint it was. (That was before we moved
house, so no surprises it’s not in current use.)

> they can either add it themselves or install one of file
> linking extensions:
> http://www.mediawiki.org/wiki/Extension:FileLink
> http://www.mediawiki.org/wiki/Extension:FileProtocolLinks

Mh. I can live with that, too, I guess.

[ search failures ]

Sorry, my PostgreSQL knowledge is pretty thin, I cannot comment
on that, which is why I’ve added Roland who provided this patch
that either solved or workarounded the issue for us.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke



More information about the Pkg-mediawiki-devel mailing list