This technical article covers Mediawiki:
- as a minimalist Content Management System
- installation / configuration / hacking
- information space design
- complaints / suggestions
It currently applies to Mediawiki version 1.7.1 and modified to run at shearer.org. I notice (May 2008) that at least as of version 1.1.12 the rights management is improved and can probably do everything my hacked 1.7.1 does.
Mediawiki source code is fairly self-explanatory so making changes is not difficult. Some of the changes I made probably can be abstracted into configurable parameters and I will consider doing this. Others changes I have reverted having discovered namespaces (editable pages) that override the functionality in the PHP code.
Defining Goals for Functionality, Look and Feel
Having decided that for now my minimalist Content Management System will be Mediawiki, I needed to see how well my goals matched Mediawiki's design goals. Mediawiki is intended firstly to deliver what Wikipedia needs, and secondly support the needs of the many private and public deployments. So Mediawiki is biased towards encouraging the general browsing public to edit content, and to have as little in the way of granular security as possible.
My goals are to:
- confuse the general browsing public as little as possible. It should be a simple, clean website
- make it very easy for a small number of editors (say, less than one hundred) to do their job with minimum hassle
Consider Wikipedia, the flagship deployment of Mediawiki. In my opinion the Mediawiki project has done a bad job of user interface design. A user who is not logged in sees twenty-two navigation items, some of them duplicates, others of dubious relevance to most casual users and all distributed in an odd sort of grouping. That's even with Wikipedia's goals. My intention is not to offer an account to casual browsers, so I'll need fewer navigation items again.
Mediawiki does have a facility for denying by default the ability to create accounts, but unfortunately:
- users get prompted to apply for an account (which I don't want. I'll hand out accounts when I wish to.)
- oddly, users who are not logged in do not get the opportunity to see the wikitext source (except in the special case of a Protected page.) One of my main goals is to let casual users see the entire source of my content so they can either copy it to their own Mediawiki installation (or Wikipedia, where the license allows) and more importantly provide me fixes in wikitext format I can apply without editing.
So more detailed goals are to:
- fix the user interface, provide the minimum navigational functionality
- provide no hint to a user at any point that logging in is an option
- de-clutter the user interface, removing boxes and anything else that looks busy. That's subjective of course!
- have article URLs as short as possible
- expose the maximum of the excellent Mediwiki functionality as possible to users, especially giving them the wikitext so they can fix it and send me the results
- Wikidrops by James Robbins
helps give a 3D feel to the flat Wikispace. The breadcrumbs are calculated on a popularity basis and it is re-generated every time a page is used. The result is a kind of self-modifying tree structure -- or it would be if a wiki was a tree, which it cannot be :-)I tried this but it kept creating long ways of getting between pages. That's because I don't have many pages so even two references on a page is enough to create a new path. When the website is bigger it will probably work better.
- Newest Pages Blog by Benjamin Bradley is this bloggy-looking list of new and updated pages. It can also output RSS.
- Cite/Cite.php by Ævar Arnfjörð Bjarmason gives footnotes. It is the one used on Wikipedia.
- Monobook skin
- If you want to change Monobook, all you have to do is edit Monobook.css in the Mediawiki namespace, ie [[Mediawiki:Monobook.css]] . This gets appended to the CSS in skins/Monobook.css, and will clearly be slower, but not enough to stop Wikipedia using it. For shearer.org, see Mediawiki:Monobook.css , all of which I modelled after the very good tutorial at http://www.planetmysql.org/entries/3114 .
- Contrary to what many seem to think, the Mediawiki security is robust and does exactly what it says, and there is more in DefaultSettings than people generally seem to realise. So where I make a mistake and some functionality requiring authorisation is accidentally visible to general users, I am quite confident that access will be denied.
- mw has some support, but the back-end rendering tools (there's four listed in DefaultSettings.php, I'm using the current version of ImageMagick) don't seem to do a perfect job. And mw will not serve up SVG to browsers, it will only hand out rendered PNGs. There is a plan to fix this but it is a pain, especially since the Wikipedia Commons is moving extensively to SVG for icons and charts etc.
- This is a problem that has a solution specification but no implementation. "The only way to run a multilingual site is to create separate databases for each language", it says. Under LocalSettings.php at Meta you'll find instructions for changing the default language. Unfortunately this then applies to everyone who isn't logged in (users with an account can choose a language preference.) There is also a lag between messages kept in places like es:Especial:Allmessages and languages/MessagesEs.php. I offered to fix this but Platonides told me he updated a bit the betawiki (changes are supposed to move to svn) which indicates there is a mechanism, it just isn't immediately obvious.
- Fragile Templates
- The Template code is currently being refactored but as it stands is quite fragile when used for more than basic things. Although Wikipedia is full of complicated templates, it often takes considerable experimentation to get them right and there is no debugging short of using the global PHP source-level debugging features. This particularly shows up when using nested templates with substitution parameters that are themselves substituted parameters. New features of templates include logic flow control such as #if, #else and this should alleviate the problem. Counting large number of curly brackets quickly gets boring.
Problems with Non-Monobook Skins
I started trying to hack the CologneBlue skin to something I liked, because I thought it was closer to what I wanted. Unfortunately I didn't know that Skins in Mediawiki are informally separate software subprojects although I should have guessed.
All skins are not equal, in fact any skin that is not Monobook is not equal. This is because:
- infrastructure changes in MediaWiki can break a skin, but you can be sure Monobook will always work because it is maintained as the reference skin
- Monobook has some of its CSS generated automatically, an increasing amount of it according to the Subversion history, so this makes things easier to change and more resilient to infrastructure changes (see previous point.) So although CologneBlue looks like an attractive place to start for removing functionality because there is less of it there, it isn't.
- Skin functionality is not documented anywhere, neither is it formally treated as a software development project with goals and measurables. So if it isn't Monobook (with which you are presumably familiar) then you will get some surprises. For example, <pre> </pre> tags are not interpreted in the CologneBlue style at all, which means that millions of mediawiki pages that rely on it producing a nice box give unexpected results.
The primary list of available skins is in the Mediawiki.org Gallery_of_user_styles . This is divided into Monobook-derived and others, but unfortunately there is no effort made to track how things are derived from Monobook, whether they can be catered for from the same codebase or what.
If you don't extend Monobook, then at least descend from SkinTemplate in SkinTemplate.php rather than Skin in Skin.php to protect yourself from changes as much as possible.
| || This content is licensed under the Creative Commons|
Attribution ShareAlike License v. 2.5:
|GFDL: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". (shearer.org uses but does not currently recommend the GDFL and here's the explanation why. )|