Here’s one from the list of "stuff I should have done eons ago."
I’m working on consolidating internal developer documentation into a Wiki. I wanted to pick a Wiki which was free, didn’t require a DB server I don’t already have installed, didn’t require a web server we don’t already own, was reasonably easy to install and had decent features. After spending some time at the completely excellent WikiMatrix and the sites for the various tools I settled on DokuWiki.
I thought the server I was going to install the thing on already had IIS on it, but I tried to connect and discovered I was wrong. But no problem, it’s Server 2003 so I just go to Add/Remove, right?
No, not that simple. I get prompted for the CD, but even before that happens the installer shuts down SQL Server without telling me, locking up StarTeam. Never mind that StarTeam is on its own SQL Server instance. OK, a reboot later and I can see the IIS default page.
Now I need to install PHP. I haven’t done that before, but shouldn’t be too hard, right? I go to php.net, grab the Windows installer, which claims to configure IIS for me, and run it like the trusting soul I am. I don’t like the default location since I try to keep things off the server’s C drive, so I select a location on another HDD. The installer finishes without complaint, but I have no idea if it worked. So after a little poking around I find this useful guide which allows me to determine that, in fact, PHP is not working. Seems IIS didn’t like the spaces in the folder name of the parent folder of my install path, and the installer used a shortened version which didn’t work anyway. It also didn’t add the web service extension. So I fix that. Now when I try to load the test page I get, "The specified procedure could not be found." Oh, to hell with it. I uninstall PHP and reinstall it in a directory without spaces in the parent path. This time the installer manages to get IIS configured correctly, but when I go to the test page I see, "The specified CGI application misbehaved by not returning a complete set of HTTP headers." Following the install docs I try php-cgi.exe from the command line and determine it’s working fine there. OK, so IUSR_myserver just can’t see it. Only it can; it should already have permission to see and run the EXE and even granting it explicitly doesn’t help.
Well I bring in another guy to look at the thing and it turns out after a lot of poking around it turns out that the Windows installer version of PHP simply doesn’t work if you change certain options in the install wizard. There are two different download options for PHP; a Windows installer which claims to set up PHP as a CGI, and a ZIP file which includes much more stuff, including an ISAPI option. The Windows installer doesn’t give you any version of php.iniputs php.ini in the wrong place, and PHP can’t deal with a non-default install location without it. John goes back and grabs the full ZIP file for PHP which does include the INI filemoves php.ini out of Administrator’s Windows directory and into the root Windows folder, configures it for our install location, and PHP is now functioning on the server. I’m so glad that PHP returns absolutely nothing to the server when it can’t find its INI file.
OK, prerequisites in place I can now install DokuWiki. It’s only available in TGZ format, so I have to put 7-zip on the server to unpack it. No problem there, and how refreshing to have an MSI that "just works" for a change after the previous step. Why 7-zip doesn’t un-TAR when a TGZ only contains a single TAR, I don’t know, but what’s an extra step at this point? After unpacking I have to create an empty file called "changes.log" in the data folder. Not sure why, but this is simple enough. I want DokuWiki to be the home page for this server so I reconfigure the site in IIS manager to point there. I’m supposed to edit conf/dokuwiki.php to "configure" the server but it’s not clear from the install instructions what, if anything, needs to be changed at this point. Looks to me like everything, except maybe permissions on the server, is in place. I hit F5 on my browser and, indeed, I have a wiki.
Cool. Now I need to go write some stuff.
Update: Here’s a useful script to help turn on user security for DokuWiki.
Update 2: One nice DokuWiki feature I just discovered: It will syntax highlight Delphi (and other languages) code using GeSHi.
{ 3 } Comments
Hmmm. Sounds too difficult, but I suppose that was the fault of PHP, and not the Wiki you chose. I was wondering why you chose DokuWiki over PmWiki? It seems to have very similar features, so I was wondering which particular feature attracted you to Doku?
Lori, both DokuWiki and PMWiki both seem to be pretty good. I can’t really state with any authority that one is better than the other, but I found this comparison interesting:
http://www.sitepoint.com/blogs/2004/10/11/pick-of-the-wikis-dokuwiki/
The wiki I prefer to use is MediaWiki, but it’s not the wiki I prefer to administer! We have a small team here and I don’t need that kind of feature set / effort.
I’d recommend, http://www.easyphp.org/, I’ve instaled it on windows in minutes, it includes all you need, php/mysql and the apache web server, no need for iis. I use dokuwiki too and once you have easyphp installed you it”ll work when you have untarred ( I use the excellent http://www.7-zip.org/) it.
Post a Comment