Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in /home/syntaxpc/wiki.sultanik.com/includes/StubObject.php on line 58
MediaWiki as a blog - Evan Sultanik

    Strict Standards: Only variables should be passed by reference in /home/syntaxpc/wiki.sultanik.com/skins/GuMax.php on line 148
  • Log in
MediaWiki as a blog

    Strict Standards: Only variables should be passed by reference in /home/syntaxpc/wiki.sultanik.com/skins/GuMax.php on line 229
  • Page
  • Discussion
  • View source
  • History

MediaWiki as a blog

From Evan Sultanik

Jump to: navigation, search



Contents

Introduction and disclaimer

I use MediaWiki not only to power my personal website, but also my blog. This article describes why and how I do so.

Disclaimer (2009-03-09): after having used MediaWiki as the content management system (CMS) for my website for over a year, I would be remiss not to warn those interested in doing the same that this all feels like a colossal hack. It took the better part of said year for me to just get a decent RSS feed working, and that required a significant amount of custom PHP coding on my part. If you're not comfortable with PHP hacking and/or you really aren't sure that you need to use MediaWiki for your project, I suggest you first consider a CMS like Drupal.

History

First, a bit of history. The following is a timeline of the methods I have employed for publishing my website:

Motivation

My motivations for using MediaWiki as a blog are manifold.

My brain is nonlinear

Despite many claims that I can not concentrate on more than one thing at a time, my brain does not work linearly. Likewise, the sequence of events about which I'd like to blog are possibly only similar in that they are organized chronologically. What it really boils down to is the fact that a blog is just a (sometimes random) non-intersecting walk through the web of one's ideas and experiences. This wiki is my web, of which my blog is just a chronologically ordered subset.

A single tool for the job

Unlike most hackers that take a side in the great Editor War, I use both Emacs and Vim (the former primarily for editing LATEX and the latter primarily for programming). My experience with Emacs, in particular, has taught me that in some cases a monolithic environment is often very useful as long as the underlying constructs are simple. Sure, there are at least 1024 different ways to do a global search and replace in Emacs... but the underlying constructs of the system—buffers, the minibuffer, the mark, &c.—are all constant. MediaWiki is much the same; there is a great amount of flexibility thanks to transclusion and the templating system, however, all of the underlying wiki syntax stays constant. That, and I'd really like to integrate my blog entries with other, less blog-like articles in my system, which is not quite seamless if one is using a different content management system for one's articles than one's blog entries.

I'm a programmer

Continuing the complexity argument from above, monolithic Content Management Systems like Drupal are quite different than the "simpler" MediaWiki solution. It was my experience (albeit in the infancy of Drupal's existence) that every single third party extension/module had its own syntax/administration system. Want to configure module X? Chances are its configuration interface will look completely different and be hidden away in a different user interface location than that of module Y. This type of architectural organization is great for systems like Linux, in which atomic functionality can be combined hierarchically to produce complex behaviors (think piping find into xargs into sed...), however, it doesn't make much sense when practically none of the third party modules share any functionality. Furthermore, as a programmer, I often found it necessary to write my own modules for Drupal. This required hacking away at PHP code, half of which was required simply to create the aforementioned configuration interface. This was all exacerbated by the fact that every other release of Drupal (which were quite frequent) brought with it a new revision of the API which would, undoubtedly, require me to re-write all of my modules.

In MediaWiki, at least 75% of my coding can be done through the wiki itself by means of templates. The other 25% is a breeze; in my past month of using MediaWiki, I've already written five extensions, all of which are just a few lines of PHP code each.

Versioning

I maintain a personal SVN repository for all of my personal documents and code, and have done so since 2001. This SVN repository lets me look back in time and see, for example, the exact state of my Master's thesis as of 13:37 EST on December 5th, 2005. Much in the same way, MediaWiki keeps track of every single edit I make to my website, which, in turn, allows me to easily review (and possibly revert to) previous versions of pages.

Semantics

Despite Joe Kopena's claims that

Anything with 'Semantic' in its name is stupid!
I think Semantic MediaWiki is pretty cool. I can tag and categorize my blog entries semantically and search through them with complex semantic queries.

Technical approach

Now that I've breifly described why I chose to use MediaWiki, I can now describe how.

One article per blog entry?

The first question I had to answer was: how should individual blog entries be stored? Should each blog entry comprise its own MediaWiki article, or should all of the entries be on a single page? The latter option would have made life very easy. In fact, if the latter option is sufficient for you then you can simply use Jim Wilson's WikiArticleFeeds extension. You can see it in use on his blog. The former option (i.e. having one blog entry per article), however, is much more flexible. For example, it allows for:

  • tagging entries using MediaWiki categories;
  • extended length entries (my "blog" is more of a chronological collection of essays, e.g. this, this, & this); and
  • unique URLs for each blog entry.

It turns out that such a scheme makes things like RSS feeds a bit of a headache, though.

Templates

Aggregating the entries

RSS feeds