First – The Problem 

I can’t get my hands around this problem with WordPress (3.0.1) on Windows 2008 Server.  I need to solve this, because it keeps me from registering with Google AdSense.  They are saying that “Site Navigation is Broken”.  And this is only a problem on Windows 2008 Server and IIS 7.  The exact same site with exact same data works properly on Win XP and IIS 5.1.

If I select posts by category (or by month), pagination links at the bottom of the page do not have category loaded in their HREF(s).  So, if user tries to go to next pages, he gets to page 2, or 3, or 4 of all posts, but not to the next page just for this category.

For example, if user selects category “Places”, browser loads link /?cat=15 in the browser, and user sees first page for posts in this category.  However, at the bottom of the page, instead of next page links /?cat=15&paged=2 and /?cat=15&paged=3 and so on, user sees page links loaded simply as /?paged=2 and /?paged=3.  Category filter is lost.

The problem is actually a bit more common than just category pagination. The problem is that query string is not being read properly by site code.  Query string is not being recognized properly.

I am really struggling to find a solution. There is nothing about this problem on the Web.  It is not a code problem that I need to fix – if I move this site to an XP IIS server the problem goes away.  It is not a theme problem, because it persists on all other themes.

Here are some troubleshooting steps I took so far:

I updated WordPress to the latest and greatest 3.0.1 version – problem persisted.

I reapplied the latest version of the theme – problem persisted.  I tried switching to bunch of different themes, and the problem remains the same.  Category pagination works on XP and doesn’t on 2008 Server.

I’ve tried to examine and compare php.ini file on 2008 server and on XP machine.  No immediate differences found.

I’ve tried to compare IIS 7 and IIS 5.1 site settings.  There is a significant difference here.  On XP and IIS 5.1 the site is just a virtual directory underneath a root directory.  On Windows Server and IIS 7, the WordPress side is an independent site similar to Default Web Site.  It has its own bindings and site ID.

What can I compare next?

Second – Long Awaited “Latest” Update

  [2010-10-03  SUN 22:09]

It is late Sunday evening. I think I just fixed it!  In WordPress file wp_includes/load.php I added one more OR condition.

Code Before Modification:

if ( empty( $_SERVER[‘REQUEST_URI’] ) || ( php_sapi_name() != ‘cgi-fcgi’ && preg_match( ‘/^Microsoft-IIS\//’, $_SERVER[‘SERVER_SOFTWARE’] ) ) ) { 

Code After Modification:

if ( empty( $_SERVER[‘REQUEST_URI’] ) || ( !empty($_SERVER[‘QUERY_STRING’]) && !strpos($_SERVER[‘REQUEST_URI’], ‘?’, 0)) || ( php_sapi_name() != ‘cgi-fcgi’ && preg_match( ‘/^Microsoft-IIS\//’, $_SERVER[‘SERVER_SOFTWARE’] ) ) ) {

This additional condition checks if ‘QUERY_STRING’ is not empty and ‘REQUEST_URI’ doesn’t contain a question mark (meaning doesn’t contain a query string).

And it is working!  Now category search on W2K8 Server populates pagination links properly. Hurray!

Third – How did I solve it?

I am writing this already on Monday morning. Here is a brief description of events leading to the solution. 

First step was to find a good lead, to find some plausible reason that could cause this problem.

Around 17:58 yesterday I had a breakthrough, but it was another 4 hours before I knew exactly what to do.  The idea was to compare some key system values for PHP on XP and PHP on 2008 Server.  A one-line info.php file ( <?php phpinfo(); ?> ) shows you many pages of system info and server variables in a well-organized blue and gray table in a browser window:

 

 

I noticed that _SERVER[“REQUEST_URI”] on XP has value path plus query string, but on 2008 Server only has a path.  That was something.  If  some piece of code in WordPress relies on this server variable to extract query string parameters, it will a very likely cause of the problem.

Second step, was to check this idea against reality.  Using search “A word of phrase in the file”, I located 1 WordPress and several theme files that use this variable.   wp_includes/load.php was the only WP file that was loading all these different system values for further use by WordPress.  But it looked like they were already checking all possible conditions.  Why no one reported this problem on the Internet?  Why there is no fix for this already?  Where do I put some kind of a fix in a maze of IF conditions in function wp_fix_server_vars()?

The third step was the final push.  Now I knew that the possible culprit could be this server variable [“REQUEST_URI”].  So, I just search for it and WordPress together and found an old and lonely link (see below) describing a fix for version 2.6 in file wp-settings.php.  That gave me a missing ingredient.  By this time I knew, where I need to apply the fix [wp_includes/load.php].  Now I learned what additional condition needs to be checked.

With scary trembling fingers I made the change, and saw “500 – Internal Server Error” message.  And this is on a live system!   What to do? Luckily I just forgot to add second set of OR (||) operator.  Finally, I pressed all the right buttons and wrote on a small piece of paper:  “22:08  FIXED!”

References:

Here are two links that helped me a great deal in solving this problem.

---

Date	August 29, 2007
Title	Fixing IIS & PHP Variables – Set $_SERVER[‘REQUEST_URI’] Yourself
Link	http://davidwalsh.name/iis-php-server-request_uri
WP Version	N/A
Main Point	IIS does not support PHP’s $_SERVER[‘REQUEST_URI’]
Contribution	It made me check, how various server variables behave under IIS 7 and IIS 5.1

---

Date	N/A
Title	HOWTO: fix problems associated with IIS 7 REQUEST_URI variable
Link	http://wordpress.org/support/topic/howto-fix-problems-associated-with-iis-7-request_uri-variable
WP Version	WordPress version: 2.6
Main Point	REQUEST_URI variable doesn’t have the query parameters Fix your WordPress file wp-settings.php
Contribution	Although file name and file location changed since Ver 2.6, but the code suggested was absolutely right.  Right on the money!

---