Last week, while researching and evaluating open-source software packages written in PHP, I naturally took the time to install some of them to see how difficult it was and note any problems I might encounter. One of these was of particular interest. MediaWiki is the software that drives Wikipedia and the rest of the projects under the Wikimedia Foundation umbrella.

Goals

Some of the goals I had in mind when I set out on this little project were:

Follow best practices. Virtualize the install so PHP scripts and other resources visitors should not have access to are hidden. Friendly URLs—I don’t want to see any .php extensions while browsing. Customize the install for my particular needs. Root

For security reasons, and the threat of downtime from customers who don’t know what they’re doing, most hosting companies severely limit what you’re capable of doing in a shared environment—and of all things they’re not going to give you root access or sudo(8) privileges. Even on a dedicated server this can be a sticky situation. In order to follow the instructions below, at some point you’re going to need that capability to, for example, restart you’re Web server daemon. If you’re running Ubuntu or another Linux distribution, or Mac OS X, on a local development box, you should be all set. You should also be comfortable using a shell and know how to edit text files.

Download

First you need to grab the source code from the MediaWiki Web site. You’ll find it on the Downloading MediaWiki page. It comes in a tarball—make sure you get the latest stable version. Also make sure you meet all the requirements before attempting the install. It helps to know which versions of PHP and MySQL you’re running beforehand.

Upload and unpack

After you download the file, upload it to your Web server into the docroot of your site. At the time I did this the MediaWiki latest stable version was 1.13.2 (released 10-2-2008), and the name of the compressed archive reflects this: mediawiki-1.13.2.tar.gz.

Fire-up your shell client and visit docroot. You can decompress and extract the source in one command:

$ tar xzvf mediawiki-1.13.2.tar.gz You’ll see a whole flurry of activity as the package is creating its source tree and populating the directories with files. You’ll be left with a directory, just off docroot, with the same basename as the archive. The first thing I did was rename it to something more manageable: $ mv mediawiki-1.13.2 w There’s no need for the archive any longer so get rid of it. $ rm mediawiki-1.13.2.tar.gz Then change into the w directory. $ cd w Configuration

The browser-based installer will want to write out a file called LocalSettings.php in the config directory. To forestall any permission problems make that directory world writable:

$ chmod a+w config

Now point your browser at the directory off docroot you just created: example.com/w/ and follow the instructions to set some basic options and create the database. In a bit you won’t access the w folder directly, since we are going to virtualize it and create friendly URLs. Two things to keep in mind: the virtual directory does not really exist in the sense you create it in your filesystem, and (this is important), do not use the same name for both. By MediaWiki convention this virtual directory is called “wiki,” which you should be familiar with from browsing around Wikipedia.

When the installation is complete, copy the config file down to the w directory and add a few lines.

$ cp config/LocalSettings.php . // docroot/w/LocalSettings.php $wgScriptPath = ‘/w’; // real path $wgArticlePath = ‘/wiki/$1′; // virtual path $wgUsePathInfo = true;

These settings, and one more task with your Apache config file, will take care of ever having to access the w path directly, and will give you the nice URLs we’re after.

Apache

You’re going to need to be root on the box to do at least one of the following steps. Since I have a virtual.conf file for this site there was no need to edit httpd.conf directly. Your mileage may vary. Either way, in the Directive “><VirtualHost> container for your site you need to add an Alias to finish this job:

Alias /wiki /real/path It’s probably a good idea to make sure your config file(s) have no errors, then restart Apache: $ apachectl configtest Syntax OK $ sudo apachectl graceful Apache gracefully restarted

Then point your browser at: example.com/wiki/ and if everything went well you’ll see the MediaWiki “Installed successfully” message on the Main_Page. An even cleaner set-up would be to create a sub-domain of your site, say: wiki.example.com, and install everything in the docroot. But I’m not going to get into that here.

mod_rewrite

There are a number of other solutions out there, many of them involving mod_rewrite. Unless you understand regular expressions and have some experience using mod_rewrite, or enjoy pain of the voodoo variety, I recommend going the Alias route. Why hit a tack with a sledgehammer?

Conclusion

MediaWiki is a large program and it uses lots of system resources. If you’re in the market for a simple Wiki and one only you will be using then consider shopping around for something less complicated. I went for Big Daddy for a couple of reasons. One, I wanted to gain the experience of installing it, and two, I wanted to have my own sandbox, so to speak, to better understand the system, and in particular, to improve my skills editing Wiki documents using their markup language. With that said, it was worth the effort.

Although there is little to see or do, you can visit wikiZero to see the results of a fairly fresh install. Also, if you’re really planning on diving into this, and you’re a dead-tree fan like me, O’Reilly published MediaWiki just last month. I took a look at it and read some third-party reviews. It’s a keeper if you plan on using this software to any great extent.

We can divide programming languages into two categories:

• Flexible and powerful: PHP, C, C++, and Perl.
• Structured and organized: Java, Ruby, and ASP.NET.

I don’t disagree with the cultural grouping. PHP’s cultural heritage is definitely in the Unix programming, C/Perl camp as I suggested in building a culture of objects in PHP and Why isn’t PHP the natural successor to Java?

I prefer to group languages in a different way.

Garbage Collection

To me, this is the single biggest language comparison issue. Managing memory is orthogonal to the task most programmers are trying to accomplish. Thats a fancy way of saying a waste of time. Additionally, memory management is easy to screw up. Any process that relies on humans repeatedly doing something correctly is destined for disappointment. Sure, there are tools that help avoid memory management bugs. The best of these is to take it off the programmers plate entirely with garbage collection and let the programmer concentrate on other things.

Sure, there can be resource usage and performance issues. However, for most cases computer hardware is cheaper than computer programmers.

We can divide our languages along this axis:

• Quickly runs: PHP, Java, Ruby, C#, Perl, Python, Smalltalk
• Runs quickly: C, C++, Objective C, Delphi

Interestingly, this corresponds fairly closely with native executable versus virtual machine.

Static or Dynamic Typing

The next most important axis of comparison is dynamic or static typing. In static typing type information is associated with the variable. In dynamic typing type information is associated with the value in the variable.

The benefit of dynamic typing is that you do not waste programmer time and attention with typecasting (“static types get in my way”). The benefit of static typing is that the compiler can catch certain errors (“The compiler finds my mistakes”).

• Risk tolerant: PHP, Ruby, Python, Smalltalk, Perl
• Risk averse: Java, C#

Interactive or Batch

Some might call this axis interpreted versus compiled. The issue is how long does it take to switch contexts from coding to running? Is there a lengthy build process or a deployment stage? The shorter the build process, the more productive development can be.

• Interactive: PHP, Ruby
• Batch: Java

A good example of this in the PHP world is to look at Smarty and Propel. They both generate code to execute. Smarty does it interactively, while Propel requires a build process. The build process is the primary reason I don’t use Propel.

Scope

One should not underestimate the importance of this factor. Why is Java considered so complicated? One reason is that it is designed to run on everything from servers to cell phones, from desktops to dishwashers. It’s scope is impossibly general. Of course, specialized tools such as Rails and PHP are more productive for their sweet spot applications.

• General: Java, .NET
• Specific: PHP, Rails

PHP and Ruby on Rails are two peas in a pod

Looking at these factors so far, PHP and Ruby on Rails are two peas in a pod. Lets start looking at some of the factors where Ruby and PHP begin to diverge.

Popularity

Popularity brings better tools, more available developers, better documentation, and better productivity. Programming on a discontinued or rarely used platform is more difficult.

• Popular: PHP, .NET, Java
• Rare: Python, Ruby, Smalltalk

Abstraction

Working at a higher level of abstraction allows the programmer to be more productive. The computer industry has continuously been heading up the abstraction scale without looking back. Professional programmers want to work with higher level constructs because they are more expressive. One can get more done with less code. The draw back is that higher level language features can require more programmer skill to use well.

• Simple: PHP, C, Java
• Powerful: Ruby, Smalltalk, Lisp

I’m talking about the language, not the libraries when I classify Java as simple. Dynamic versus static typing aside, I see the Java and PHP languages as similarly expressive.

I have alot of respect for Anders Hejlsberg and there is some serious innovation going on in the C# world on this front. Java can barely keep up.

The Rails folks are fond of saying that Rails couldn’t be written without the expressive features of the Ruby language. It would be interesting to get the opinions of some of the cake developers on this idea.

Library Organization

Not my favorite part of PHP.

• Function oriented: C, PHP
• Object oriented: Java, .Net, Python, Ruby

Stiffies?

I think Ruby is misclassified when placed with Java and C#. Ruby is closer to PHP than it is to either Java or C#. Rails and PHP share most of the same sources of productivity: garbage collection, dynamic typing, interactivity, and focus on web applications.

Please post your blogs and write comments here.