As part of writing my extension for MediaWiki, I created a mechanism for
plugging in namespace handlers, which work similarly to the way that
"Image:" and "Category:" are handled, but defined outside the core code.
I wrote the attached patch for MediaWiki 1.5.1. I haven't yet tried to
port it to head, but I intend to, assuming I receive no negative
feedback on the idea here. I see the code is slightly different in the
head, but it doesn't look like a drastically different approach.
The way this patch works is by introducing a new global array:
$wgNamespaceHandler. Here's the structure:
$wgNamespaceHandler[$nid] = array containing the namespace handler for
namespace with numeric id of $nid
$wgNamespaceHandler[$nid]['ArticleClass'] = class name of the class
meant to extend the Article class.
$wgNamespaceHandler[$nid]['ArticleInclude'] = include file for the above
$wgNamespaceHandler[$nid]['EditClass'] = class name of the class meant
to extend the EditPage class.
$wgNamespaceHandler[$nid]['EditInclude'] = include file for the above
$wgNamespaceHandler[$nid]['NameSpaceKey'] = the l10n key for the article
tab in the UI
The patch adds checks for the presence of this array, and potentially
instantiates the defined classes instead of Article and EditPage if set.
One could theoretically simplify the code by implementing categories and
images this way, too, but in the interest of keeping my patch as
non-invasive as possible, I'm not doing that.
Anyway, I don't expect that the patch below would be accepted for the
1.5.x branch. What I'm hoping to do is get some feedback on the
approach for getting this in the head before tearing in.
Is there a tarball somewhere of the Help namespace available here:
Our local network gets pretty slow during the day, and I'd like to pre-load
our Help: namespace with this tree.
Hi. I am trying to get LDAP up and running under 1.5.1 and when I attempted to use the diff's in version 1.0 of the LDAP patch from http://bugzilla.wikipedia.org/attachment.cgi?id=551&action=view I keep getting errors such as:
patching file AuthPlugin.php
Hunk #1 FAILED at 65.
Hunk #2 FAILED at 133.
Hunk #3 FAILED at 210.
3 out of 3 hunks FAILED -- saving rejects to file AuthPlugin.php.rej
the date on the AuthPlugin.php file shows as Jul 24 05:48
Is there a more recent patch or should I be looking somewhere else.
Thanks in advance for any help you can offer.
> Fatal error: mime_magic could not be initialized, magic file (null) is
> not avaliable in C:\apache2\htdocs\mediawiki15\includes\MimeMagic.php on
> line 476
This is a PHP issue - mime_content_type seems to be buggy under windows.
1) See http://www.php.net/manual/en/function.mime-content-type.php,
about half way down the page:
The function mime_content_type only worked for me on Microsoft Windows
after I added the directive "mime_magic.debug" to my php.ini with the
value of "On". The default value appears to be "Off". Exampe:
mime_magic.debug = On
mime_magic.magicfile = "c:\php\extras\magic.mime"
2) Install PHP with the fileinfo extension enabled (see
http://pecl.php.net/package/fileinfo). MediaWiki will use it instead of
mime_content_type, if it's available. Note that this probably also uses
a mime.magic file somewhere, somehow...
If (and only if!) you install fileinfo as a shared library, also set
$wgLoadFileinfoExtension= true; in LocalSettings.php.
3) Use an external program for mime detection by setting
$wgMimeDetectorCommand (in LocalSettings.php) to a command that will
return the mime type of a file. Under linux, "file -bi" works fine, but
that is not available under windows without a little fiddling. You might
get it to work via cygwin.
I hope this helps - please give feedback which solution works for you,
so other people running 1.5 under windows have an idea how to solve this
Thanks for giving feedback!