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

[Platonides]

El 12/06/12 09:37, Thorsten Glaser escribió:
> 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.

Where's that patch? :S

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

If there's no need to update anything, it will be a no-op.


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

update.php will also run updates for the extensions which have
registered for that (they obviously need to be enabled at that point).


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

I think debian didn't run update.php automatically which is a big
drawback on the packaged version. I mean, What's the benefit on using
the package manager if that can (knowingly) leave the wiki in a broken
state?


>>> ++	'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.

The users see a link which doesn't work when clicked.
(and even if it worked, it would usually be meaningless unless it points
to some local share...)