Web Apps with Tiger: MediaWiki

It's not prom night. It's not graduation. It's not time to pop the question. No raise, no bonus, no Ed McMahon, no free song from iTunes. Instead, we're going to install our first web application. Now, I know, I know: installing software versus a lifetime of acceptances from your partner is a teensy bit of a skewed comparison. And if I had something to tie the two together, to suggest that they're equivalent coming-of-ages where you evolve from beastdom or innocence into civilized society, I'd probably have stated it by now. But I don't, so I won't. Let's just start this crazy thing, eh? (If you're behind, catch up with Web Apps with Tiger: Getting Started and Web Apps with Tiger: Security and MySQL.)

Choosing the Right Software

In our previous articles, there hasn't been much of a chance to make choices: to decide if we really want PHP, or if MySQL was the best outcome we could've reached regarding databases. PHP and MySQL are such entrenched expectations that you simply can't go wrong with them (calm the flames, you muckrakers!). Now that those are outta the way, we're entering a familiar world where you or the person you're asking are right, and all others are wrong, and laughably so.

What's your favorite text editor on OS X? What about image manipulation? Is AppleScript worth learning? The Dock is great! No, it's not! I love the Dashboard! You're an idiot! Et cetera, et cetera, et cetera. The same software decisions you've made regarding your local OS X applications apply equally to web software.

With web applications, however, there's a big difference: instead of just one person, you, fiddling with a text or image editor, every one of your web site's visitors is going to be messing with, innocently or maliciously, the software you make available on your server. That's quite a different dynamic than what you're probably used to.

Mentally, I have a fluctuating set of things I look for when I'm choosing a web app. They're not hard and fast rules, merely "be awares" that help me decide if a particular software is even worth investigating. Making the right choice up front is abnormally important with web applications: if you make the wrong one, you're going to be looking at possible site downtime, custom scripts to import old data into a replacement system, and the constant harassment of users who preferred whatever you had installed before. My list of concerns include (currently... once this article has been posted, I'll be all, "ArgGHh! I forget Aloofness!"):

Related Reading Apache Cookbook By KenCoar, RichBowen Table of Contents Index Sample Chapter

• Community: You're going to want some sort of support system when you're dealing with software that has to stand up to the pokes and prods of thousands of bloodthirsty visitors. Is there a strong community? Are there regular progress reports from the developers? Are users sharing their success stories? Or is the community floundering, with numerous questions being unanswered, or worse, answered rudely? How quickly do security updates appear? Are people happy?
• Dependence: Can you depend on the software to be around for another few years? Are there any major sites where the removal of the software could cripple their operations? Is the dog food properly ingested? The goal here is to determine if there's another upgrade path, should the core developers give up the ghost. Are there smart enough people around to keep progress moving should something dastardly happen?
• Reputation: What are other folks saying about the software? Is it buggy or full of security holes? Has anyone important™ used the code or thrown his or her weight behind its future? If there's a blood drive to buy a new server, do unexpected benefactors appear with Dickensian delight? Have people from your regular tech hangouts heard of it or used it themselves?
• Resources: How complicated is it to install? Do you need custom tweaks to your back end, or new libraries, modules, or supplementary software you'll also need to install? Once it's up and running, does it create a high server load, or use an obscene amount of memory? Are there lots of moving parts that make upgrading a lengthy process? Unfortunately, this particular concern can often only be addressed after it's too late--when you've configured the software just right, unleashed it on your public, and then realize it's destroying your server.
• Readability: Is the code readable, well-written, and well-documented? If something broke or you needed a small tweak here and there, would you be able to hack your desire in there without a lot of effort? Does the code show some sort of intelligent design (heh, heh) or is it sloppy, poorly blackboxed, or full of tricky passages that require hours of hard staring, debugging, and enough liqueur shots to warrant a hunting license?
• Expandability: In relation to the community, is there a lot of healthy hacking going on? Are people expanding the software to follow their own whims and desires? Are these expansions or plugins fully supported with a documented API, or are they truly "add-ons" that were never meant to be? How easily can you get your data out of the software? How about getting it back in? Does it play well with others or existing standards? Is it friendly to modifications that are more than just a "small tweak here and there," but rather a tested addition for the community at large?

These are all questions that run through my head when I'm researching a particular web program. Naturally, they've all been asked for the pieces of software we'll be exploring within this series. Be aware, however, that there are very few projects that satisfy every little quibble; the final decision often devolves into a listing of pros and cons and how much a particular negative outweighs a specific positive.

Web Apps with Tiger: MediaWiki
Pages: 1, 2, 3

Installing MediaWiki

The first piece of software we're going to install is from a breed called a wiki. Wikis are a relatively ("relatively") new type of software that some folks absolutely hate, some absolutely love, and some think'll be good enough in a few years. According to Wikipedia, the quite popular community created encyclopedia:

A wiki is a web application that allows users to add content . . . but also allows anyone to edit the content. The term Wiki also refers to the collaborative software used to create such a website . . .

At the time of this writing, 1.4.9 is the latest version of the MediaWiki software. 1.5 is currently in release candidate testing, but you should only consider installing that if you're self-sufficient enough to not really need this series of articles. The following assumes an installation of 1.4.9. It also, for the sake of readability, instructs you to install MediaWiki into a subdirectory called wiki. In real life, however, you'd want to name this something that describes purpose, not implementation (see Cool URIs Don't Change). Download MediaWiki to your Desktop, and then run the following commands to create /Library/WebServer/Documents/wiki:

morbus@:~ > cd /Library/WebServer/Documents

morbus@:~ > tar xvzf ~/Desktop/mediawiki-1.4.9.tar.gz

morbus@:~ > mv mediawiki-1.4.9 wiki

Before we move on with the installation, we'll have to create a MySQL database for MediaWiki to use for all our content. Running the following commands (which assume you've set up your environment and root password as instructed in the previous article) will do that for us. Replace the italicized text with your own unique decisions. The middle two commands are word-wrapped, but should each be typed as all one line.

morbus@:~ > mysqladmin -u root -p create wiki_dbname

morbus@:~ >

   mysql -u root -p -e "GRANT ALL PRIVILEGES ON wiki_dbname.*

   TO wiki_user IDENTIFIED BY 'wiki_password'"

morbus@:~ > 

   mysql -u root -p -e "SET PASSWORD FOR

   wiki_user = OLD_PASSWORD('wiki_password')"

morbus@:~ > mysql -u root -p -e "FLUSH PRIVILEGES"

Next, open the wiki/INSTALL file in a text editor, and follow the instructions under "In-place web install." MediaWiki will then be available at http://127.0.0.1/wiki/. The installation wizard is simple enough to not warrant further hand holding; for the "Database config," you'll want to use the database name, user, and password you chose and created in the MySQL commands above. If you don't know what a particular option means, leave it as the default setting.

With the wizard completed, go to the main page of your wiki and create your user by clicking the "create an account or log in" menu item in the upper right. Usernames can contain spaces if you'd like. Alternatively, you can login using the "Sysop" account you created as part of the installation wizard. Once logged in, you'll be returned to the front, and suitably boring, page of your new installation.

As is typical with new software, there's that inevitable, "What next?" If you've never used a wiki before, the most important maxim to take to heart is, you can't screw up, fixes are an edit away. Go ahead and click on that "edit" tab at the top of your main page, and be greeted with a text area with which you can modify the contents, preview, and eventually, save. Every time you change and save a wiki page, a backup is made. Did you screw up or accidentally delete something? You can view the "history" of a page to recover (or re-edit) that missing data, or "rollback" a page to a previous version. A list of recent content changes, as well as specific differences, are accessible from the "Recent changes" link in the "navigation" box on the left.

Most wiki software is shipped with its own Markup: shorthand for the various HTML elements you'd normally use to design your content. Instead of typing <i>eh oh!</i> for italicized text, MediaWiki allows you to use two single quotes instead: ''eh oh!'' (a full list of shorthand possibilities is available). The syntax you'll use the most, [[Some Words]], makes links to other wiki pages. For example, [[Deltab Pains Me]] will automatically create a link to the wiki page named "Deltab Pains Me," whether it exists yet or not. If it exists, clicking the link will show you the article; otherwise, you'll be given a chance to fill it with relevant content.

Every wiki software has a different shorthand, and very few are capable of supporting other formats. This shorthand can actually contribute to a negative mindset: this wiki is hard to use because it doesn't support what I've come to expect elsewhere. MediaWiki is no different: out of the box, it only supports its internal house format. Typing this shorthand is entirely optional; if you prefer using HTML, go right ahead, or use the buttons above the text area to click your way through.

If there's one piece of shorthand you should grow fond of, however, it's --~~~~. This odd looking creature forms a signature that will automatically link your name, user page, and timestamp of your edit, in the form of "--Morbus Iff 02:33, 13 Sep 2005 (EDT)." This becomes very helpful to keep track of who's who during conversation, or simply to keep tabs on the age of the content without running through the page's "history" trying to find the point of origin.

Web Apps with Tiger: MediaWiki
Pages: 1, 2, 3

Exploring MediaWiki's Features

While I certainly can't run you through every feature of MediaWiki in my remaining word count, I can give you a taste of some of my favorites. You can read more about these, as well as everything else possible, over at MediaWiki.org.

• Categorize content with [[Category:CategoryName]]. Did you just finish a big page about your favorite video game moment? Add [[Category:Games]] to the bottom of that page's content, save it, and that page is now categorized in "Games." You can add more than one category, [[Category:Religion]], perhaps, to indicate it deals in theistic content. Categories spring into existence once they've been assigned to a page; you don't have to worry about defining them beforehand. You can see all content assigned to a particular category by clicking the category name, or get an overview of all categories by visiting Special:Categories. Category pages themselves can also be edited, described, and assigned to other categories in the same way, creating a browseable hierarchy. For instance, you could create a Category:PS2 page and add [[Category:Games]] to indicate it is a child of "Games."
• MediaWiki's change tracking is one of the best I've seen. In addition to the "Recent changes" page mentioned above, there's also the ability to "enhance" its display via a user preference: when enabled, all daily changes to a single document are condensed into an expandable group, which substantially reduces the clutter of an undecided and frequent content editor. Also, the ability to include a comment summarizing your changes creates a readable changelog, and the visual display of each individual "diff" is quite nice too.
• The use of templates can help standardize and reduce the amount of work you need to do: templates allow you to include one page inside another (a process known as transclusion). As a quick example, create a page called Template:Example, write and save some gobbledygook in there, and then edit your main page to include the text {{Example}}. Once you save your changes, {{Example}} will always be replaced with the latest contents of Template:Example. There's a lot more possible with templates than I can delve into here.
• User notifications allow you to leave a message on a particular user's Talk: page. Talk: is a MediaWiki namespace reserved for discussions about the corresponding topic. Every relevant page has a "talk" tab that you can use for this purpose. The next time that user logs in, he'll receive a notification that he has a message to address. This feature allows you to alert someone far more obviously than expecting they'll keep track of the "Recent changes" on a heavily-trafficked site.

And more. If there's one document that should be treasured like a million-dollar lifeline, then it's the MediaWiki FAQ, which includes answers to such common concerns as changing the links in the sidebar, that blasted logo, allowing edits for authenticated users only, messing with the various bits of text sprinkled through the interface, et cetera, et cetera.

Final Thoughts

This article was finished whilst listening to Bernard Herrmann's North by Northwest soundtrack. (Yes, that revelation had even less meaning or import than the bungling comparison I made in the introduction.) In my next article, I'll backpedal a bit to explore some further helper monkeys for our server. As always, wax poetic in the comments below. Particularly, some folks desire an Apache/PHP compiling tutorial--to that, I ask, what needs are you missing with the various precompiled OS X versions available?

Kevin Hemenway is the coauthor of Mac OS X Hacks, author of Spidering Hacks, and the alter ego of the pervasively strange Morbus Iff, creator of disobey.com, which bills itself as "content for the discontented."

Return to the Mac DevCenter