The long pause

I disappeared from the Blogosphere for a while. No need to panic, the project is going very well. Pretty much everything is working on SQL Server now. My intent was to record in the blog everything that was going on as it was happening. Instead, I got so wrapped up in working on the code I didn't have much energy left to do the blogging. My intent now is to get my work rolled into the MediaWiki baseline once MediaWiki 1.10 releases. The MediaWiki principals seem to be working fairly arduously on making the 1.10 release happen, and don't need to be distracted by worrying about incorporating completely new capabilities that come at them from out of the blue. Not surprisingly, there turned out to be a little bit of scope creep. MediaWiki doesn't seem to get much use on Microsoft Windows servers, so I discovered some things that needed to be done to make that work better too -- like getting the ImageMagick and Batik image management working (by default they don't). I also needed to work to get HTML Tidy working. It wasn't until pretty late in the game that I realized that was even going to be necessary. In particular, there's a lot of templates used in Wikipedia and related sites that just plain won't work right now without HTML Tidy. Having posted this latest status report now, it remains for me to go back and retrace the steps it took to get to a working MediaWiki engine on Microsoft SQL Server in upcoming blog posts.

First steps

In order to make MediaWiki do something new, we first watched how it does some of the old things. In particular, how a new Wiki gets created. Here's a summary. When MediaWiki is first installed, there is no database. How does the engine know this, and what does it do to create one? Well, it doesn't actually check for a database. Instead, a clean installation of the MediaWiki scripts looks for a LocalSettings.php file in the top-level directory (which we'll call "~"). If that file isn't found, then the script ultimately serves up the content of ~/includes/templates/NoLocalSettings.php. The most significant thing on that page is a link to ~/config/index.php. Clicking on that link will take you to the installation script. The top of the page generated by that script will report on the environment, and the bottom half will contain a form to allow the wiki to be configured. In our case, the second bullet in the environment report says "Found database drivers for: MySQL" and the form Database config section has a single radio button for Database type, labelled "MySQL". It looks like this page will be a good place to start looking for what needs to change. Obviously we want to expand the found database drivers and to make an additional radio button available.

Project Start

We decided to embark on a project to adapt the MediaWiki engine to support Microsoft SQL Server on the back end instead of MySQL. From monitoring the MediaWiki discussion group, I was aware that my team was not the only one to find this of interest, and one participant in the discussion asked that I set up a blog to discuss our progress on this project. Well, here it is! For development, we had access to a machine that already had PHP 4.4.4 installed on it. The first action we took was to upgrade that to PHP 5.1.6. MySQL was already up and running on the machine, as was Microsoft SQL 2000. The first hurdle we faced was getting PHP 5.1.6 to work properly with Microsoft Internet Information Server (IIS) version 6. Most of the instructions we found online relate to IIS 5, and were not particularly helpful. Finding our resident webmaster to point us in the right direction got us off the ground. Making changes to the PHP.ini file had no effect until I added a key to the registry using regedit. The new key has the name [HKEY_LOCAL_MACHINE\SOFTWARE\PHP] and the value "IniFilePath" = "C:\\PHP". After making this change, it was smooth sailing to get PHP configured. Copying the files from the MediaWiki distribution onto a web server directory and browsing to that directory, and we had MediaWiki up and running (with the MySQL back end) in a matter of moments. Now we want to watch the PHP as the web site runs our Wiki, so we want a debugger that runs on our desktops and that will let us step through code running on the server. That's where Komodo (http://www.activestate.com) comes in. What a great tool! The only confusing thing we ran into setting up Komodo is that we have to get rid of the PHP registry entry on the client or we can't set up Komodo for remote debugging. (Komodo runs with a special PHP.ini file when it's in debugging mode, and apparently the registry entry overrides Komodo's mechanism for specifying where to find this alternate INI file). Once that's set up, we put the magic words at the end of the Wiki URL, and presto!, we can step through the code from the Komodo client and watch how the MediaWiki PHP scripts do their magic.