rvirtue

Great! Glad to hear your problem is solved.

Actually, based on the above-mentioned bug ticket, it looks like WP 3.1.1 will be turning off canonical redirects for IIS entirely. But that interim solution should handle the issue okay until then.

I’m not sure what you mean by “missing a few $is_IIS’s”. The only file edits needed to correct the infinite redirect issue on a Windows/IIS platform are the two I mentioned. In fact, you could actually remove the $is_iis7 variable from the global declaration (line 38) but it does no harm to leave it there so long as $is_IIS is included.

Did you notice some other errors in that canonical.php file?

@shock976: There is an alternative to the “patch” plugin. As reported by “daniel6683” in another thread on the same subject, this particular issue is actually due to a fairly straightforward logic error that crept into the redirect_canonical() function in the wp-includes/canonical.php file’s v3.1 revision.

First of all, the $is_IIS variable needs to be added to the global declaration on line 38 of that file as follows:
global $wp_rewrite, $is_IIS, $is_iis7, $wp_query, $wpdb;

Secondly, on line 40, it needs to test for $is_IIS and, if so, whether it supports permalinks as follows:
if ( is_trackback() || is_search() || is_comments_popup() || is_admin() || !empty($_POST) || is_preview() || is_robots() || ( $is_IIS && !iis7_supports_permalinks() ) )

In other words, on line 40 of canonical.php, “$is_iis7” needs to be be replaced with “$is_IIS”.

If we had more testers who had their sites running the betas on Windows platforms, maybe the problem wouldn’t be in there.

Possibly not and I can certainly understand that we all screw up now and then, certainly including yours truly. On the other hand, when a version update modifies a wp_redirect() function that involves a specific “if($is_IIS)” exception, wouldn’t you expect testing the results on the platform involved to be a normal part of the developer’s own revision process? Sure seems like there’s been a significant oversight this time around.

Anyhow, all I’m really saying, now that the issue has been clearly identified, is that some up-front acknowledgement and workaround posting might be a good idea to avoid more problems until a proper fix can be worked out.

You seem to regard Windows usage as some kind of an exotic departure from “normal” expectations. For many potential WP users it’s anything but that.

If the end product’s usage on Windows/IIS platforms is intended and supported, a default installation test on one or two such platforms would hardly seem to be an “unreasonable” expectation of its developers, or anything like testing on “every conceivable platform.” I do it myself and I’m just a “core team” of one single person.

On the other hand, if such usage is not intended and supported, you should say so clearly up front. That’s all. Pretty simple really.

In that case, if your product is untested on any Windows/IIS platforms and/or not intended for use thereon, that should be made clear up front.

Extensive beta testing?! Are you serious? The infinite loop redirect issue occurs even with a brand new fresh default installation on a Windows/IIS server. And I have THREE (3) Windows server set-ups to prove it!

In any case, pending a proper fix, now that the problem has been made abudantly clear, A PRIOR WARNING IS DEFINITELY IN ORDER — preferably right on the download page.