Command of the day: git-mediawiki
Many posts in this blog talk about WiKo, Hyde, pandoc… Solutions we can use to edit wiki like pages as plain text files, so that I can edit them with my preferred editor (vim), do site wide search and replace, track revisions using a version control system such subversion or git, and reuse the same content to generate multiple media: pdf documents, web pages…
After that Grial Quest I have some solutions that works for me. Indeed I am writting this entry using MarkDown which turns into a web page by means of Hyde. But, meanwhile, some of the projects I am involved in already use some kind of traditional wiki system, and most of them use Mediawiki.
Lucky for me, this week, I have come across a useful git extension. It git clones the content of a Mediawiki site as it were a git remote repository so that you can pull revisions into your hard drive, edit them and push them back into the wiki.
A quick tutorial
You can install it on debian/ubuntu with:
sudo apt-get install git-mediawiki
Once you do that you can execute:
git clone mediawiki::http://clam-project.org/w clam-wiki
Since 3k4 revisions we have in CLAM are a quite long download and the wiki api and the server are quite slow, you can avoid the history with:
git clone -c remote.origin.shallow=true mediawiki::http://clam-project.org/w clam-wiki
Before you push back you must set the wiki user.
git config remote.origin.mwLogin MyUser
git-mediawiki stores git-commit to mediawiki-revision mappings in a parallel branch.
As migration path way
This extension is not just useful to edit MediaWiki as it where a git remote repository.
It is a nice path to move your wiki to a different system like Hyde, by turning the pages into markdown with pandoc.
for mwfile in *.mw do pandoc -f mediawiki -o $(basename $mwfile .mw).md $mwfile done
The wish list
The tool is quite useful by itself, but there are some edges that could be improved (bug reports linked):
- Attachments are not included. So if you have, for instance, images, you won’t have them in local.
- Cloning, pulling and pushing are slow. Those are the operations that interact with the remote MediaWiki. All the revision handling intelligence happens at users computer, so git-mediawiki has to download a lot of information from mediawiki previously to do any action. MediaWiki API entry points are not designed with those use cases in mind.
- Supages do not generate directories.
For instance, if you have a wiki page named
Devel/ToDo
, which is a subpage ofDevel
, instead of generating a folderDevel
and aToDo.mw
file inside, it replaces the slash by%2F
,Devel%2FToDo.mw
, which looks quite unreadable when you list the files.
It is a pity, that git-mediawiki is written in Perl instead of Python. If it were written in Python I would be fixing those bugs right now :-)