The Problem

My first step was to determine exactly what was wrong. My home page displayed fine, but all other links to articles, tags, and categories were not working. I then tried URLs corresponding to actual files on the web server, and these resolved fine. My site is powered by WordPress running on a Microsoft IIS web server. The IIS ISAPI_rewrite module is used to rewrite URLs to provide custom SEO-friendly URLs for permanent links (permalinks in WordPress terminology), as described in my article Running WordPress 2.0 under IIS. My problem was that these WordPress permalinks were not working. I confirmed this by going to the Permalink Settings page within my WordPress Site Admin and changing the common settings to default – all pages were now accessible.

This problem happened to me shortly after I upgraded to WordPress 2.8, so I suspected a compatibility issue between WordPress and PHP, although I had no idea why I had not noticed the problem when I initially upgraded. I checked the WordPress installation requirements and confirmed that the version of PHP I was running (v4.4.9) was greater than the minimum requirement of 4.3 or greater.

Solution #1

I then turned to Google to find out if others had experienced this problem and what they had done about it. My search surprisingly turned up mostly unhelpful results, with the exception of one article: CodeIgniter - No input file specified error - .htaccess - PHP5 - Apache 2. This lifesaver article provided the first solution that truly worked. While this article provides two separate solutions and states that only one of the two needs to be used, I found I had to use both. The changes I had to make were:

1. Modify my PHP settings (in php.ini) to set cgi.fix_pathinfo = 0.
2. Change my URL rewriting (in httpd.ini) to rewrite custom URLs into URLs starting with "index.php?" instead of just "index.php" – i.e. add a question mark '?' to the end of "index.php". The revised rewrite rule is: RewriteRule /psd/(.*) /psd/index.php?/$1 [L,U].

I experienced difficulties testing this solution – it appeared as though the web server was caching the PHP or rewrite settings and not immediately applying my changes. This may have been why I never noticed the problem immediately after upgrading to WordPress 2.8.

Solution #2

Once I determined the problem was related to PHP, I decided to upgrade to PHP version 5 rather than PHP version 4. I requested the upgrade while I resolved the problem using the above solution. Once the upgrade to PHP version 5 was completed, I reverted my URL rewriting change and found that the problem did not reoccur. So I now strongly recommend only running WordPress 2.8 under IIS using PHP version 5.

I am going to start my retrospective by listing my top seven posts that have received the most traffic (page views):

1. Running WordPress 2.0 under IIS: This is one of the first articles I wrote. It provides detailed, technical how-to information on a topic that has been of continued interest. As a result, this post has received the most traffic by far – double that of the second-place finisher.
2. Strategies for Effective Code Reviews: I thought and worked hard on the ideas that went into this post so I am happy to see it occupying the number two position.
3. How to Achieve Peak Performance: This article was written for one of Problogger’s group writing projects, and I am sure that its position in this list is due in part to the extra links and traffic the post received as a result.
4. Overtime Considered Harmful: Perhaps one of my more provocative articles, at least with employers. Given that I feel that some common I.T. industry practices such as overtime are counter-productive or discourage the development of expertise in software development, I am happy to see this particular article appear in the top seven.
5. How to do Root Cause Analysis: Slow and steady wins the race. This article did well but not great when it first came out. Over time, however, the traffic it has been receiving has been increasing, and it has gradually earned enough views to put it in the number five position.
6. Top Five Essential Practices for Developing Software: This post was also an entry in one of Problogger’s group writing projects. While not the most insightful article, I feel it is a good starting point for juniors. I do feel the article is a good reflection of my underlying motivation to help others grow into better software developers.
7. Advanced Uses of Java 5 Enums: This is a very technical how-to article on a narrow topic. I was certainly surprised to find this in the top seven: it beat out a number of other technical posts on topics I thought would be of more interest.

As I looked back at my prior 99 articles there were a number that stood out for a variety of reasons:

• How to Write Good Unit Tests : This article was used as reading material for an university computing science course (UBC CS310).
• Are You a Rule Maker or a Rule Breaker?: I still find the insight I relayed in this article to be useful for myself today and I really liked the diagram I produced for the article. I would like to use more diagrams and graphics in my articles when appropriate, but producing them is sometimes difficult and usually time-consuming.
• EnvGen - the Environment-Specific File Generator: I have created a number of open source software programs that are available (for free) from my Software page. Of these, I am the most pleased with EnvGen, which not only scratches an itch I had at work, but has received kudos from other coworkers who have found it equally useful.
• How to Handle Null Values in Code: This post generated a surprising amount of discussion and debate – I did not think the topic would be that contentious. I always wanted my site to be a place where intelligent and useful discussions take place, so I was pleased to see it occur in this case. Of particular note is one comment by El Gregorio which convinced me that I was incorrect in using Java asserts for precondition checks. While I want others to benefit from my site, I also treasure the opportunities I get to learn and grow, so thanks to El Gregorio for that comment.
• My Vision for IT: In this article I articulate my vision for what I want to achieve with my website. Even though I wrote it two years ago, it is still mostly on target. I have recently been doing some reflection on my values, vision, and mission for myself as a software developer and have refined or altered some of what I mention in the article. I hope at some point soon to produce an article to share my most recent thoughts.
• Error Handling and Reliability: This article and its predecessor Fail Fast or Degrade Gracefully? nicely demonstrate how I have been learning and evolving my understanding and viewpoint over time. Learning and growing as professionals is an important theme of my website, so I am pleased to have some articles that demonstrate my continuing growth.

This has been on my to-do list for a while, but I was never satisfied with the libraries I found. (I mostly looked for WordPress plug-ins, since this site is based on WordPress.) I then came across a recommendation by Software By Rob for the Google Code Prettify library and immediately liked how simple it was to use: basically just one stylesheet and one javascript file.

To see some examples of the syntax highlighting at work check out the following articles:

• Working with Java 5 Annotations
• Creating Custom Tags Using JSP
• Parsing and Generating XML with Java
• How to Handle Null Values in Code

WordPress previously only supported categories, which I used on this site. WordPress supports associating a post with any number of categories, just like tags. So how do they differ? The first major difference is that WordPress expects categories to be predefined, whereas it allows new tags to be added without restriction. The second major difference is that the navigation element for categories is most frequently a list. Since a category list takes up much more vertical space than a tag cloud for the same number of elements, there is the expectation that the total number of categories will remain small. See the image below.

Comparing the two images, we see that the tag cloud actually takes less vertical space despite showing four times as many items. The tag cloud does use more horizontal space, but this is actually an advantage: the format of the tag cloud allows it to use almost all of the available horizontal space, unlike the category list. The tag cloud, therefore, uses the screen real estate more effectively.

Which format is more usable? The main goals of both the category list and tag cloud are to (1) provide an overview of what the site is about, and (2) help users navigate to articles of interest. I believe that the tag cloud does a better job of achieving both goals. Displaying so many more tags than the category list gives a much more complete overview of the content available on the site. There is a risk that too many tags will cause the more important content to be lost in the crowd, but this is offset by the use of larger fonts for more frequently-used tags. I suspect that navigation is generally easier for users looking for a particular topic because it is much more likely there will be a tag that corresponds to their topic. If there isn't, they do have more tags to navigate through compared to a category list, which is a disadvantage. But on average there are less articles per tag then there are per category, so they can try several tags fairly quickly. For myself, I often look up old articles while writing new ones, and I find it much easier to navigate to a specific old article via a tag than via a category. Why? I often have difficulties remembering exact what 'vague' category I filed an article under, while there is usually at least one tag I know is linked to the article.

This brings me to what I believe is the most significant advantage of tags over categories: tags correspond more closer to how our minds store and retrieve information. Categories imply a hierarchical, structured way of organizing information, with each post usually being filed in a single category. Tags imply a more arbitrary network of relationships between articles which supports multiple ways of categorizing the content. I have often struggled in the past trying to assign a post to a single category, especially when part of the post is about another category. Assigning multiple tags is much more natural in this situation.

I haven't seen any consensus on the web regarding whether tags or categories are better. Among popular social bookmarking sites Digg uses categories and Technorati uses tags. An article on Problogger about tags and categories and the resulting discussion revealed a diverse set of opinions; the article itself stated that tags compliment categories and both can co-exist on a site.

I myself am leaning towards eliminating the use of categories on my site and just using tags with the tag cloud. I would be interested in hearing your opinions on the matter. Do you prefer the tag cloud or the category list? Should I keep both? Should the tag cloud display less tags, or have a smaller size for the largest font? Please leave a comment and let me know.

I am quite pleased that I was able to maintain my goal of publishing one article per week for the entire year. It has sometimes been challenging to meet this schedule since I have a full-time job and a family. Working four days a week instead of five has definitely helped. However, this fixed posting frequency has had some downsides. While I have no shortage of ideas for articles, I choose a topic based on what I am motivated to discuss, or based on issues I am currently dealing with. Some weeks I do not have a particularly strong motivation to write about a topic. I therefore have to push myself to produce an article which often I am not as happy with as my articles on topics I feel strongly about. Another downside is that writing an article a week does not leave enough free time for me to work on other projects. For example, I have an idea for a software utility that I would like to implement and add to my Software page, but this requires significant blocks of free time. Due to these factors, I am changing my publishing goals. My new goal is to publish a quality article at least every two weeks. I will also publish the articles immediately once they are written rather than always post on a fixed day.

One change to my website in the last nine months is the addition of advertising - specifically Google's Adsense ads. Adding advertising to a site can be controversial, so why did I do it? I do work full-time, so I do not need an income from this website. I do spend a considerable amount of time writing articles, however, and feel it is appropriate to be compensated for doing so. The deciding factor for me, however, was that it represented a learning opportunity I did not want to pass up. As I found out, I did have a lot to learn. Choosing ad placements was difficult: more visible positions above the fold would likely earn more, but would also be more intrusive for viewers. I wanted to maintain a good viewing experience for the reader, and did not want to plaster ads all over my site. Initially, I erred on the side of caution and only placed a small ad below each article. This placement earned very little revenue. I then used A/B testing to test a larger ad format in the same position. It performed about twice as well in terms of ePCM (effective cost per 1000 impressions), so I switched to that format. Later, I tried a new ad placement above the fold, and it performed even better. Currently, my ad placements are earning roughly five times my initial setup in terms of ePCM, which shows the importance of ad optimization. I have recently made other changes that I am looking forward to evaluating.

I have also changed the search functionality on this site. When I actually went to use the default WordPress search functionality, I was not pleased with the results that were returned (only posts are searched, not pages), and how the results were presented. I decided to switch to use Google's search, which not only returns better results in a format everyone is familiar with, but also can earn income if ads on the search result pages are clicked. I am quite happy with this change, and highly recommend it for other blogs.

To implement Google ads and search functionality required changing my custom WordPress theme. During my initial development of this theme, I had not bothered to check the code into version control. This caused me a few problems once I made changes after my website was live. One change made the site render badly in Internet Explorer, which I did not discover until after promoting the change to my live site, and without having the changes recorded in version control, I could not easily reverse the changes or determine what caused the problem. I therefore put my entire WordPress installation - not just my custom theme - into version control. This was very helpful not just for making changes but also for upgrading to new versions of WordPress. I always knew that version control was important, so I am not sure now why I did not use it from the start. At least now I have a better appreciation for its importance. For version control software, I use Subversion, and have written about my experience with it.

I regularly analyze my web server statistics, tracking metrics such as page views and referrer sources. I am pleased with how I was able to grow my traffic: my page views in December were more than the first four months of the year combined. I have used a few methods to promote my site including social bookmarking sites such as reddit.com, blog carnivals, and ProBlogger's group writing projects, which have all helped. One interesting lesson I have learned from my server statistics is that technical how-to articles that address a particular issue for a particular technology generally do better for drawing search engine traffic. One example of such an article is Tips for Using Log4j. Based on the search terms used, I can tell that people encounter problems working with a technology, search online for an answer, and come to my site. Partially as a result of such articles, my search engine traffic has increased by a factor of seven over the last six months.

Overall, I am pleased with this first year for my website and look forward to this coming year. I would like to thank all my readers, especially those who contributed via leaving a comment, linking to my site, or shared my site on a social bookmarking site. I would especially like to thank those of you who left donations. Your generosity and support is greatly appreciated.

I was a little surprised when I started receiving negative feedback. After the initial shock wore off, I realized that many of the changes people were recommending made sense. A common complaint was that I had too much text crammed onto the screen with insufficient white space around it. I had deliberately left out vertical spacing bars present on most websites because I didn't (and still don't) like the idea of not using that space. For my design, however, I had inadvertently gone to the opposite extreme. All that text crammed together made the articles harder to read.

Based on the feedback, I decreased the width of the article text by adding white space around it. I also increased the spacing around the article title to make it stand out more. Below are images of my website from before and after these changes.

Website Before Changes

Website After Changes

Receiving this feedback was a good experience. My web site is much improved and I increased my knowledge of web design. Handling negative feedback, however, is never easy. The natural instinct is for our ego to put us on the defensive. We defend our work rather than honestly evaluate the feedback. This is a conundrum for us as professionals. We should take pride in our work when it is done to the best of our ability. But to grow in our craft, we must set aside our ego and acknowledge our weaknesses and limitations. This is hardest for the expert: the term implies no such faults exist. In my case, I have never claimed to be a professional website designer. As a software developer I have done website design, but I know my skills in this area are not at a professional level. So this made it easier for me to seek feedback concerning my site's design.

Even with our ego set aside, evaluating feedback is not easy because it is not consistent. People have different likes and dislikes or hold contrary views. In the feedback I received there were opposing viewpoints: one person liked an aspect of the site while another criticized it. My strategy was to pay closer attention to recommendations suggested by more than one person, especially when there were no dissenting views.

If you seek feedback, then you must be prepared to act on it. While I was able to make the changes described above, I did receive other useful advice that I haven't had the time or resources to make use of yet. So don't be surprised if I make more changes to this site in the future. If you have any opinions about my website, including these recent changes, I'd love to receive the feedback.

Blogging software is typically used to create blogs. Once past the hurdle of initial setup, such software makes it very easy for a user to create blog entries. But content creation software has existed since the early days of the web, so there must be more to blogging than that. Blogs have a consistent structure: a series of entries tracked by day of entry. Such a structure matches that of a journal or diary - everyday concepts that the non-technologically-savvy person is familiar with. Thus, the mental model of a blog is very understandable, which not only makes them easy to create, but also makes them easy to read and navigate (as compared to personal websites, whose structure and content have no such regularity). This is an important usability principle: have the system's model match the user's mental model as closely as possible.

But blogs have another feature that I think is even more important from a usability point of view, and that is web feeds, also known as syndication. Before the days of web feeds, you had to manually visit someone's website to determine if they posted new content. And due to the lack of regularity in structure for personal websites, it was not always easy to tell if there was new content. Or, if there was content marked as new, did you read it last week already? The net result: few return visitors to personal websites.

Web feeds use protocols such as RSS to publish website changes to a single file on the website. New visitors to a site can use web feed reader software to monitor this special web feed file. The feed reader software will regularly poll this file, and inform the user when there is new content. This functionality offers a major boost in usability to website readers, as they can find out quickly and painlessly when there is new content on a site, and based on the summary of the change, decide whether it is of interest.

Blogs have another important feature that I haven't mentioned yet, and that's comments. The comment feature allows visitors to the blog to enter comments for a particular blog entry, which then become visible to other readers. This feature engages visitors, and allows them to participate in the blog, turning it into more of a dialog rather than a broadcast. Over time, a popular blog can end up with a regular group of readers / commentors. A related phenomenon is a group of bloggers who comment on each other's blogs and/or write blog entries in response to others' blog entries. In both these cases, the blog(s) have been transformed into an online community. Humans are social creatures and naturally form communities (social structures) of all kinds. An excellent article I came across on this topic is Building Communities with Software from the great Joel on Software site.

Besides the usability improvements for both writers and readers, blogs provide the ingredients for new communities to arise in a way that personal websites never did. I believe it is the combination of these factors that have propelled the popularity of blogs into the mainstream today.

Before launching my website, I had created a local development environment to run my website using WAMP (a package combining Apache web server, MySQL database and PHP for windows), installed WordPress (the software running this website), and ensured everything was running properly. Satisfied I would not have any problems, I uploaded the website files to my ISP, did the necessary setup (i.e. created the database) and tried to view the home page. Naturally, I promptly ran into all sorts of problems. After a few frantic days, I had resolved most of the issues and the website was working to my satisfaction. The root cause for the problems was that my ISP used Microsoft's IIS web server instead of Apache. I had known that my ISP used both IIS and Apache web servers, so I had hoped Apache would be used instead of IIS, but such was not the case. There are two lessons to learn here: the first is that the more closely your development environment resembles your production environment, the better. The second lesson is to not make hopeful assumptions, and instead verify and test everything.

Immediately after announcing my website I was interested in obtaining feedback on the number of viewers. My ISP provided web server statistics analysis, so I took a look. I quickly realized there were problems with the statistics: every hit on the site was being recorded, including my hits to either test the site, administer the site, or to write articles through the web interface. The statistics I was interested in were being obscured or distorted by my own hits. So I ended up downloading the raw web server log file to my local machine and analyzed it with AWstats, which is open source software for analyzing web server logs. I set up the software to exclude administration URLs and to exclude hits from my IP address, and the results better matched what I was looking for. I was also happier with the statistics produced by AWstats compared to the software used by my ISP because AWstats automatically filters out hits by robots (automated programs navigating the site) rather than combining these hits with those by human readers. I think measuring usage of an application or website by users is a great idea - I certainly found it useful, and will have more to say about what I learned below. But the lesson here is to not blindly trust the numbers provided by an analysis program and to be careful of what you are measuring.

I quickly grew tired of manually downloading the web server log (since I wanted to look at the latest day's or week's statistics) and automated the whole process using an ant build script. Now with one click I can download the latest server log and run the analysis software. One lesson I learned is that I should have automated the process much sooner that when I did - I did it manually for about five days longer than I should have, in part because I thought it would take longer to automate than it actually did, and in part because the amount of manual work was fairly small. But once I fully automated the process, I immediately regretted not having done it sooner.

My initial analysis of the web server logs provided some interesting statistics, one of which was the large number of page-not-found requests (http error code 404). Further investigation revealed that almost all of these were due to the absence of a robots.txt file in my website (used by web crawlers to determine which portions of the site to avoid). I immediately added a blank robots.txt file in order to prevent more 404s from occurring. I'm sure the absence of a robots.txt file didn't cause any problems to the crawlers, but I considered the 404 errors in the log a warning mechanism, and didn't want it unnecessarily cluttered, just like having too many warnings displayed by your build or IDE causes you to ignore all of them.

When a new version of WordPress came out, I decided to upgrade. Because of the differences between my local development environment (running Apache) and the production environment (running IIS), I realized that I needed a staging / testing environment running on my ISP to experiment with and test out changes before going to production. I could have tried running IIS in my local development environment, but I wasn't sure if a free version existed, and had heard of many people having problems configuring IIS, so I figured I was better off using my ISP's configuration for both the staging and production environments. As I set up the staging environment and began the upgrade process, I realized that it was somewhat complicated and involved, in part because I wanted to minimize downtime for the website. To address this I created an upgrade process document to describe the steps necessary to perform the upgrade. Not only was this useful in ensuring I didn't forget any necessary steps, but I can use the document as a basis for performing future upgrades. The lesson I learned is that a public website is no different from any other software application in production: in particular have a separate staging / testing environment and have a documented migration / upgrade process. If you have an application in production without these things in place (and I do know of at least one case where this is true), you can expect to have problems. Since I set up the staging environment I have found it quite useful, especially for trying out IIS-related changes that I cannot try in my local development environment. Since my website is in a sub-directory of my domain (basilv.com/psd/), it was easy to put the staging environment in a parallel directory. If you are setting up a website, I'd recommend using this structure instead of putting your website directly in your domain's root. If you want to receive traffic going to your domain root, you can always add redirects (i.e. the URL basilv.com is redirected to basilv.com/psd/).

It was never my goal to have lots of search engine traffic, yet when setting up my site I tried to follow basic recommendations for search engine optimization (SEO) such as Google's webmaster guidelines. Not only did these guidelines make sense for virtually all websites in the first place, but it was an opportunity for learning about SEO that I didn't want to pass up. Combined with a small amount of 'marketing' such as providing information on the WordPress forums pointing to my post on Running WordPress under IIS, I achieved a Google page rank of 4 across my site, and a page rank of 5 for the WordPress article. Over the three months I have received a decent amount of search engine traffic, most of it going to this article. I found the statistics on search engine usage interesting: visitors to my site from a search engine results page used Google 80% of the time, Yahoo 15% and MSN 5%. The results follow a typical distribution found in many industries: there is a market leader with the majority of the customers (Google), a secondary player with a significant minority (Yahoo), and the remaining players which barely show up (MSN). I should point out that these statistics are for an extremely small sample of searches on a very limited set of topics, so I wouldn't generalize from them.

Web server logs usually include the user agent from which a user's browser and operating system can be determined. Statistics for operating systems matched my expectations: the majority was Windows (82%, of which 68% was Windows XP and 10% Windows 2000). The various flavors of Linux and Unix, including Mac OS X, accounted for the remainder (various distributions of Linux added up to 6% and Mac OS X had 5%). For 7% of the hits the operating system was unknown. I found the low numbers for Linux interesting. Despite all the hype surrounding Linux on the desktop, Linux usage was quite low. Considering the computer-savvy audience for my website, I would have expected this number to be higher.

Statistics for browsers were more surprising. Initially Internet Explorer had the lead as I had expected, but as traffic to my site picked up, Firefox became the leader with 50% of the hits (40% use Firefox version 1.5 or later and 10% use earlier versions). Internet Explorer received 34% of the hits, almost all of which were MSIE 6. Other browsers that had more than 1% of the hits included Mozilla at 6%, Safari at 3% and Opera at 3%. For 2% of the hits the browser was unknown. I found it interesting that despite the majority of users being on Windows, less than half of them are using Internet Explorer. At least among the technically-minded users coming to my website, more than half of Windows users have switched to Firefox. These results are quite different from more general website statistics, where I've heard that Internet Explorer is still used by roughly 80% of visitors.

From the statistics I was able to determine which articles are the most popular. (Actually, for technical reasons these statistics indicate the number of times articles are viewed after they no longer appear on the home page, which given my publishing schedule is one week after they are posted.) The most popular articles (excluding the WordPress one) are listed below. If you've missed one or more of them, I suggest giving them a read.

1. Working Smarter, Not Harder
2. Overtime Considered Harmful
3. Local Variable Declarations
4. What is Professional Software Development

There are several different reasons why these articles are the most popular. The last article is linked from my About page, so newcomers to my site who look at the About page may navigate to the article. These articles were all published in January, and the general trend I've observed is that the longer the article has been available, the more hits it receives. For the first two articles, I'd like to think that it is their intriguing titles that have attracted more viewers. If so, then this confirms the advice I've read multiple times: the title is one of the most important elements to an article. (The introduction being the other important element.)

The process of writing articles for my website taught me a few other lessons. Originally, when I established my website and set a goal of publishing one article per week, I was uncertain whether I would be able to achieve this goal, both in terms of finding the time to write the articles, and in terms of finding a topic to write about. In order to help ensure I achieved my goal, I followed the recommendations for goal-setting taught in personal management courses. I wrote the goal down (making it concrete). I published the goal as one of a list of goals for my website and told my friends about it (thus introducing the risk of public shame if I fail to achieve the goal). After a few weeks of running the site, I also set a specific day & time for publishing each article (Thursday morning), so that it is always clear each week whether I have met my goal or not. I believe these steps have helped me achieve my goal so far.

What about my concern about being able to come up with ideas for articles? I no longer worry about this. In fact, I have the opposite problem: too many ideas. I've had to set up a document to capture all my ideas, and sometimes have troubles deciding which one to use. Scarcely a week goes by that I don't generate two or three ideas for every one I turn into an article. In fact, the act of writing an article often spawns new ideas. And there is nothing special about me in this regard. I have recently read books such as The Joy of Writing by Pierre Berton and articles that indicate the same experience happens to professional writers and entrepreneurs. To quote Pierre Berton, "... ideas are a dime a dozen in this business. It is not ideas that count, it is the execution of these ideas." (page 313). I'd suggest the same is true for software development, whether one has ideas for new features of an existing application, or for a brand new application: the idea is easy to have, but to turn it into a working, usable feature or application that users will actually use is much harder, and is the essence of our craft.

On that note, I'll bring this article to a close. I hope you have enjoyed the website so far and continue to read the articles I post. I'd appreciate any feedback you have: feel free to leave a comment and let me know what you think.

All examples use my website, in which I have WordPress running under a subdirectory of the domain (www.basilv.com/psd) instead of directly under the root. So WordPress itself is installed in directory /psd under my root website directory. Take this into account when using my examples.

First, a little about how WordPress works. WordPress serves all normal content via the index.php file. Given a URL such as http://www.basilv.com/psd/index.php/blog/category/miscellaneous/, the WordPress code called by index.php parses out the path after index.php (/blog/category/miscellaneous) and displays the content associated with that path.

The first problem running under IIS is that the above URL is interpreted to be pointing to a directory - index.php is considered a directory instead of a PHP file to be invoked. To change this behavior, a php.ini file must be created and placed in the website root directory with the following contents:

cgi.fix_pathinfo = 1
cgi.force_redirect = 0

The second problem I encountered is that the .htaccess file provided by WordPress is considered invalid by IIS - it serves a HTTP ERROR 500 whenver trying to access anything in a directory containing an invalid .htaccess file. The solution is simply to delete the file.

WordPress may somewhat work at this point, but with 'ugly' URLs containing index.php in the middle. I wanted clean URLs, so had configured WordPress to use nice permalinks. My permalink structure is /blog/%year%/%postname%. The .htaccess file provided by WordPress uses the Apache mod_rewrite module to convert (rewrite) 'clean' URLs to include 'index.php'. (By the way, this is a big improvement over WordPress 1.5, which required quite a complex .htaccess file which WordPress had to update every time a page was added.)

To use clean URLs, we therefore need URL rewriting capabilities in IIS. The solution is to have the ISAPI_rewrite module installed on the IIS server. With this module running, a httpd.ini file can be added to the root website directory (not under /psd, where the .htaccess was located) with the rewrite instructions.

Unfortunately, the ISAPI_rewrite module is not 100% compatible with the Apache rewrite module, and in particular is missing some (many?) of the capabilities found in the Apache module. Therefore, the conversion from .htaccess to httpd.ini is non-trivial. Let's look at the .htaccess file found in the /psd directory:

RewriteEngine On
RewriteBase /psd/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /psd/index.php

The main lines are the two lines starting with RewriteCond plus the RewriteRule line. What these 3 lines are saying is that for any URL that is not a file (!-f) or a directory (!-d), replace the first character of the URL with /psd/index.php. In conjunction with the RewriteBase line, this essentially converts a URL of the form www.basilv.com/psd/foo/bar to www.basilv.com/psd/index.php/foo/bar.

Directly converting this to ISAPI_rewrite is not possible, because ISAPI_rewrite's RewriteCond directive doesn't support the is-a-file (-f) or is-a-directory (-d) tests, and the RewriteBase directive isn't supported at all. So I wrote rules to convert all URLs starting with /psd to add in the index.php:

RewriteRule ^/psd/$ /psd/index.php [L]
RewriteRule /psd/(.*) /psd/index.php/$1 [L]

This worked, partially. The problem is that images and style sheets associated with the theme were not being loaded, because their URLs were also having the index.php added. I also had some images and files outside of wordpress, but under the /psd directory, that were also incorrectly being rewritten. So I had to add rules for each of these cases before the above rules to map such URLs to themselves and then terminate (the last rule option [L]) before reaching the above rules to add in 'index.php'. Essentially, this is a manual implementation of the RewriteCond rules used in .htaccess to ensure that files & directories do not have their URL mapped. The relevant portion of my final httpd.ini file is:

[ISAPI_Rewrite]

# Rules to ensure that normal content gets through
RewriteRule /psd/software-files/(.*) /psd/software-files/$1 [L]
RewriteRule /psd/images/(.*) /psd/images/$1 [L]
RewriteRule /psd/favicon.ico /psd/favicon.ico [L]

# For file-based wordpress content (i.e. theme), admin, etc.
RewriteRule /psd/wp-(.*) /psd/wp-$1 [L]

# For normal wordpress content, via index.php
RewriteRule ^/psd/$ /psd/index.php [L]
RewriteRule /psd/(.*) /psd/index.php/$1 [L]

When working on the rewrite rules in the httpd.ini file, I ran into problems testing due to the browser cache. I was getting inconsistent / unexpected results due to the browser caching prior results. The solution is to clear the browser cache, which in Firefox can be done via the menu item Tools | Clear Private Data.

Another issue is having WordPress send emails (i.e. when a comment is waiting for moderation). The default approach used by WordPress doesn't appear to work under Windows. The solution I found is to install the wpPHPMailer plugin which allows you to configure WordPress to use any SMTP server to send the emails.

One issue I was unable to resolve is a problem with the post preview feature. Under IIS, post preview doesn't work (due to a 404 error) when the article is in draft status. The workaround is to change the status to private if you want to preview your post. This problem is due to a defect in WordPress that is fixed in WordPress 2.0.1.

To summarize the steps to get WordPress 2.0 working under IIS:

1. Add php.ini file to correctly resolve URLs containing index.php.
2. Remove .htaccess file which IIS can't handle.
3. Install ISAPI_rewrite module on IIS server to provide URL rewriting capabilities.
4. Provide httpd.ini file to rewrite URLs.
5. Install and configure wpPHPMailer plugin for sending emails.