Posted on 2010-08-31
We at Varnish Software use mediawiki internally for various documentation-like tasks, as does Redpill Linpro and a number of projects I've been involved with. The problem is that Firefox and Chrome are web browsers, not editors. I prefer vim. A solution was needed. A geeky one. I checked around for cli-based mediawiki-editing tools, and found a bunch of broken crappy-ass tools. There were at least two different approaches to fuse-based mediawiki-editing, none of them really worked or were possible to hack without investing far more effort into the matter than it was worth. (Somehow, when people measure the quality of FUSE filesystems and playing games in wine, the definition of "works well" seem to be "it's theoretically possible with a lot of effort to get it to mostly do something somewhat similar to what you should want it to do."). Then there were some other tools that were even written in perl(!). The horror. So I wrote my own. Couldn't be THAT hard, right? And it gave me the opportunity to hack around with Awk, which is always a bonus.
Turns out, it wasn't that hard. wiki.sh is 219 line shell script, or 149 lines once comments and blank lines are removed. It uses basic auth to authenticate and uses the mediawiki api to fetch and edit content. It can be reviewed at: http://github.com/KristianLyng/wikish/raw/master/wiki.sh (http://github.com/KristianLyng/wikish/raw/master/wiki.sh) The code repository living at http://github.com/KristianLyng/wikish (http://github.com/KristianLyng/wikish) As it's mainly tested by myself on a single wiki, it's likely to break for other setups. But it's a simple shell script, and should be fairly straight forward to work with. It uses curl, "supports" XDG basedirs for configuration (aka: let's test how many environmental variables are never ever use before we try the default location), allows multiple configs based on PWD, has explicit POST and GET commands, or the more convenient EDIT command, which will fetch a page, open it in your $EDITOR then post the new version if you changed it. It fetches edit-tokens in mediawiki-style, but should probably not be used in environments where you anticipate edit conflicts yet, since it fetches the edit token right before the post, not when it fetches the content. All in all, it's a cute little hack. So far, I haven't been able to make it really break after the initial protocol-mick-mockery was resolved.
Step 1, pick a page to edit.
Step 2, it's now fetched and open in vim.
Step 3, edit it however you want, save in the normal vim-way.
Step 4, wikish updates the wiki for you.
The gpg-output is because I keep the password in a gpg-encrypted file. The result and title is to verify that it posted it to the right title. Step 5: Showing off the horribly complex configuration.
If you use rewrite rules for mediawiki, and not the overly ugly wikipedia naming scheme of having 'wiki' at least three or four times in a url, you'll want to set '$wgUsePathInfo = false' in mediawiki. This isn't specific to wiki.sh, but anything that wants to use the api. Otherwise, you're likely to find yourself editing /Mediawiki/Api.php instead of whatever you were really intending to edit. An other neat trick I use is to execute "cd /home/kristian/tmp/wikish/" at the top of the config. That way, I can keep all the trash in one place - with the added benefit of being able to do open old wiki pages directly in vim - even if I can't edit them directly. I also keep the passwords in a gpg file, as the example points out. You will almost certainly want to symlink wiki.sh to /usr/local/bin/wikiedit for example. wiki.sh checks how it was invoked: "wikiedit PAGE" is the equivalent of "./wiki.sh EDIT PAGE", "wikipost PAGE" == "./wiki.sh POST PAGE" etc. PAGE being the actual title you want to edit. Feel free to post issues on the github issue tracker. I do review them, though if they are not relevant to my own setup, you may want to add a patch too ;)