IIRF rules and operation Wordpress MU (99% complete)

Topics: Developer Forum, User Forum
Apr 3, 2010 at 5:17 PM

I noticed a lot of questions concerning using IIRF with Wordpress MU (that's Wordpress Multi-user version).  I've pretty much got the solution cracked and understand what's going on and how to write up a general solution.  However I could use the answers to 2 fairly simple questions.

The first's pretty minor.  Since IIRF doesn't have a RewriteBase equivalent (I saw where it might get added in the future), I'm having to add my desired base to every rule (in my case it's just "/", but that's not always the case of course).  That complicates the directions, is there a more elegant way to address that?

The second's more complex but I'm sure it's common.  I need to use the equivalent of the Apache REQUEST_URI server variable, which IIS doesn't have.  I don't need to rewrite it (I'm using the RewriteRule U flag to account for that), but I need an equivalent value.  I *think* that I can use HTTP_URL or UNENCODED_URL instead, but I'm not sure (and to be honest, I'm not even sure what the *difference* between HTTP_URL and UNENCODED_URL is).  The general solution *in* PHP is to append a "?" and QUERY_STRING to SCRIPT_NAME if QUERY_STRING is present, otherwise just use SCRIPT_NAME, i.e.

$HTTP_SERVER_VARS['REQUEST_URI'] = ( isset($HTTP_SERVER_VARS['REQUEST_URI']) ? $HTTP_SERVER_VARS['REQUEST_URI'] : $HTTP_SERVER_VARS['SCRIPT_NAME'] . (( isset($HTTP_SERVER_VARS['QUERY_STRING']) ? '?' . $HTTP_SERVER_VARS['QUERY_STRING'] : '')));

However this approach is too complex to use in a rule, I think.  Are the server variables HTTP_URL or UNENCODED_URL functionally equivalent to that?

Lastly, I'm using the [U] flag quite a bit, which I understand turns off kernal caching.  Is that a per VHOST (application) state or is it server-wide?  If I get the above sorted out, it may be worth trying to find a solution that avoids using the [U] flag so caching can be enabled, but I'll start another thread for that at that point.

Apr 3, 2010 at 5:21 PM

BTW, once I figure these items out, I will post the general setup instructions for Wordpress Mu in a separate discussion.  I think IIRF is a great solution for using Wordpress MU on IIS as it's free, powerful, and offers everything the other IIS rewrite solutions do.  I didn't want to use the "lite" versions of the others because they don't offer *per site* settings, which is critical.  Hopefully a general solution for Wordpress MU will be helpful.

 

Coordinator
Apr 4, 2010 at 3:51 AM

I put the RewriteBase directive in, but it doesn't work exactly the same as Apache's , so you'll need to modify the ini file anyway.  You may not need to modify each rule, though.  Check the documentation on RewriteBase for more information.   You need v2.1.1.2 to get this directive.

For the REQUEST_URI, you can set a request header in IIRF using the RewriteHeader directive.  The solution for you would look like this:

RewriteCond %{HTTP_X_REQUEST_URI}  ^HTTP_X_REQUEST_URI$
RewriteHeader X-REQUEST-URI:  .*    %{PATH_INFO}  [QSA]

You need IIRF v2.1.1.2 to get the [QSA] modifier to work with RewriteHeader.

About the U flag - it turns off Kernel caching on a per-install basis.  If you've installed IIRF site-wide, then caching is turned off for that site. If you've installed IIRF at the server level, then the use of the U flag in IIRF turns off kernel caching for the server.  If you are using the U flag only as a workaround for the lack of REQUEST_URI, then the above ini file statements will solve your problem without the effect of disabling the kernel cache.

Apr 4, 2010 at 12:17 PM

Ok, your implementation of RewriteBase (I hadn't realized it was already included in the new version), makes sense and will work perfectly.  The only suggestion I can think of is to *allow* a URL base argument for RewriteBase and just treat it like "ON".  This way it would be completely compatible with the mod_rewrite Apache module.  If that's not desirable (or not desirable enough), than there's no need for it.

I like the RewriteHeader approach for REQUEST_URI.  It's not quite as simple as I could wish since IIS automatically prepends "HTTP_" to all custom headers, right?  I believe Wordpress MU is looking for "REQUEST_URI" so "HTTP_REQUEST_URI" or "HTTP_X_REQUEST_URI" won't work without some modification of Wordpress.  Fortunately the workaround is just to modify wordpress to look at "HTTP_X_REQUEST_URI" instead of "REQUEST_URI", which is a single line change.  It's just that Wordpress users will have to reapply that fix whenever they re-install or upgrade (which is what I was trying to avoid).

That should let me avoid turning off Kernel caching, as I was only using the U flag to preserve the original URI.  If I store it in the header before the rest of the rules, than I don't need it.

Now I just have to deal with the how Wordpress MU tries to deal with IIS itself.  I think it may interfere with what I'm doing with IIRF (which is actually more correct!).  I may need to disable it.  Here's the code (notice the explicit references to other IIS URL rewriters "IIS Mod-Rewrite" and "Isapi_Rewrite"):

// Fix for IIS when running with PHP ISAPI
if ( empty( $_SERVER['REQUEST_URI'] ) || ( php_sapi_name() != 'cgi-fcgi' && preg_match( '/^Microsoft-IIS\//', $_SERVER['SERVER_SOFTWARE'] ) ) ) {

	// IIS Mod-Rewrite
	if (isset($_SERVER['HTTP_X_ORIGINAL_URL'])) {
		$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_ORIGINAL_URL'];
	}
	// IIS Isapi_Rewrite
	else if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
		$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];
	}
	else
	{
		// Use ORIG_PATH_INFO if there is no PATH_INFO
		if ( !isset($_SERVER['PATH_INFO']) && isset($_SERVER['ORIG_PATH_INFO']) )
			$_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];

		// Some IIS + PHP configurations puts the script-name in the path-info (No need to append it twice)
		if ( isset($_SERVER['PATH_INFO']) ) {
			if ( $_SERVER['PATH_INFO'] == $_SERVER['SCRIPT_NAME'] )
				$_SERVER['REQUEST_URI'] = $_SERVER['PATH_INFO'];
			else
				$_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME'] . $_SERVER['PATH_INFO'];
		}

		// Append the query string if it exists and isn't null
		if (isset($_SERVER['QUERY_STRING']) && !empty($_SERVER['QUERY_STRING'])) {
			$_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING'];
		}
	}
}

 

Apr 4, 2010 at 12:20 PM

Actually now that I look at it, we should be able to leverage the same code that is setup for ISAPI_Rewrite as long as we use the same header "HTTP_X_REWRITE_URL"

 

Coordinator
Apr 4, 2010 at 1:22 PM
rswitt wrote:

Ok, your implementation of RewriteBase (I hadn't realized it was already included in the new version), makes sense and will work perfectly.  The only suggestion I can think of is to *allow* a URL base argument for RewriteBase and just treat it like "ON".  This way it would be completely compatible with the mod_rewrite Apache module.  If that's not desirable (or not desirable enough), than there's no need for it.

The reason you hadn't realized it was included is because I've just implemented it!   I'll consider allowing a base argument to RewriteBase.  I'll have to think about whether I can implement it in a way that is easy to explain and use. 

I like the RewriteHeader approach for REQUEST_URI.  It's not quite as simple as I could wish since IIS automatically prepends "HTTP_" to all custom headers, right?  I believe Wordpress MU is looking for "REQUEST_URI" so "HTTP_REQUEST_URI" or "HTTP_X_REQUEST_URI" won't work without some modification of Wordpress. 

Yes.   The HTTP_ prefix is used when making available a custom headers as a server variable.  If you retrieve the header, you'll see the header you set (X-Whatever).  If you retrieve the server variable, you need to use HTTP_X_WHATEVER. 

 

Apr 4, 2010 at 6:20 PM
Edited Apr 4, 2010 at 6:23 PM

Well, unfortunately IIRF version 1.2.1.1 is faulting on me (I started a different thread on that.

Ignoring that for now (I'm testing with 1.2.0.16), your example above fails because PATH_INFO seems to be empty.  I'm not sure why that happens.  I tried to do the equivalent by using:

 

RewriteCond %{HTTP_X_REWRITE_URL}  ^HTTP_X_REWRITE_URL$
RewriteHeader X-REWRITE-URL:  .*    %{SCRIPT_NAME}?%{QUERY_STRING}  [QSA]

 

Which pretty much works (should I have dropped the [QSA]?), but always puts a "?" after the URL whether there's a query string or not. I don't think that actually hurts anything, but it's not pretty. Is there a simple method that I'm missing to get rid of that extra "?" if the Query string is empty?  Maybe:

RewriteCond %{HTTP_X_REWRITE_URL}  ^HTTP_X_REWRITE_URL$
RewriteHeader X-REWRITE-URL: .* %{SCRIPT_NAME}?%{QUERY_STRING} [QSA]
RewriteHeader X-REWRITE-URL: ^(.+)\?$ $1
Apr 5, 2010 at 3:36 AM

Ok, almost done.  Here are the remaining things to be clarified:

  1. SCRIPT_NAME turned out to be the wrong choice to use for the X-REWRITE-URL header.  Instead I'm using HTTP_URL which is working, or UNENCODED_URL.  What is the technical difference between these 2 server variables, and should I be using one over the other (the IIS online docs don't seem to provide any meaningful answer)?  Both seem to be giving me the same, correct, answer.  The side benefit is that they both provide the query string (if present) as well, so I don't have to deal with adding a "?" if needed.
  2. I'm still stuck with a bad 2.1.0.16 msi scripted install, what's the best way for me to uninstall it (attempting to uninstall from Add/Remove throws a "missing script" error).
  3. I noticed when using the QSA modifier with RewriteHeader (which I no longer am), that the query string was always prepended the first variable with . I.E. "/index.php?p=1" became "/index.php?&p=1".  To be honest, I'm not sure this would cause any problems, but RewriteRule doesn't seem to behave the same way with the QSA modifier.  This is just a heads up on that.
  4. I may check with you on my final ruleset.  Everything seems to be working fine, but right now I'm using the QSA modifier with most of my RewriteRule directives, and I'm 99% sure I shouldn't have them.  Of course it's probably academic, since the whole point of Wordpress MU permalinks (i.e. "pretty URLs") is to get *rid* of query strings, and therefore it probably never uses any.  Instead it parses the untranslated URL (hence the importance of setting the X-REWRITE-URL header).

That's all I can think of right now, thanks!  Feel free to break these into separate topics if you want.

Coordinator
Apr 5, 2010 at 4:11 AM

I don't know the difference between all the IIS server variables.  Best bet is to check the IIS documentation, I think there's a link in the v2.1.1.2 IIRF documentation to the microsoft page that explains all the server variables in IIS.

To uninstall you may have to use msizap.  It;s a tool provided bby Microsoft.

For that QSA thing - I'll have to look into it.  It shouldn't behave that way, it's intended to do the right thing. 

 

Apr 5, 2010 at 4:52 PM

The documentation for the IIS server vars HTTP_URL and UNENCODED_URL unfortunately sucks.  The only explanation is that one is encoded and one is unencoded (gee, really? ;-) ).  The example for both is exactly the same and gives exactly the same result, which certainly doesn't help.  I'm getting an error related directly to this, but I'm starting to think it's a bug in wordpress itself.  Images uploaded with html coding in the name (e.g. %20) fail to load.  Ironically, those with an actual space in the name work fine :-(.

I'll give msizap a try, thanks!

 

Apr 6, 2010 at 9:24 PM

Ok, just a follow-up, it looks like the %20 file upload errors were Wordpress related, so my ruleset and IIRF are working perfectly.  Tough to test these things when you're not sure what errors were caused by you, and what errors were already there ;-).  I'll be submitting a bug notice to Wordpress on this one.

Coordinator
Apr 7, 2010 at 12:02 AM

great, thanks for the feedback. . .

 

Apr 28, 2010 at 5:34 PM
So we are trying to get Wordpress MU installed on IIS. Are there final instructions for getting this filter to work with Wordpress MU yet by chance?
Coordinator
Apr 28, 2010 at 6:02 PM
Edited Apr 29, 2010 at 6:57 AM

> Are there final instructions for getting this filter to work with Wordpress MU yet by chance?

I'm not a wordpress guy.  I'm happy to help though. 
If any wordpress users out there have questions, I will answer them. 
If someone provides me with clear instructions for how to do this in Wordpress, and asserts that they're correct and comprehensive, I'll insert that as a page into the IIRF documentation.

But I don't know of anyone who has committed to writing the "final instructions" you seek.  I personally haven't committed to providing them. 

Apr 28, 2010 at 6:09 PM
Edited Apr 29, 2010 at 3:25 PM

I've been holding off as Cheeso's been updating IIRF with modifications that make installing it simpler, but I'm happy to show my IIRF.ini file:

 

StatusInquiry ON
RewriteLog C:\windows\system32\LogFiles\iirf\iirf
RewriteLogLevel 1
RewriteBase ON

#store original URL in custom header (substitute for missing REQUEST_URI header in IIS)
RewriteHeader X-REWRITE-URL:  ^$    %{UNENCODED_URL}

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{HTTP_X_REWRITE_URL} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{HTTP_X_REWRITE_URL} ^.*/wp-admin$
RedirectRule ^(.+)$ $1/ [R=301]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

 

This has been working fine for me, as far as I can tell.  With the newest version, you should be able to modify it slightly to:

StatusInquiry ON
RewriteLog C:\windows\system32\LogFiles\iirf\iirf
RewriteLogLevel 1
RewriteBase ON

#store original URL in custom header (substitute for missing REQUEST_URI header in IIS)
RewriteHeader X-REWRITE-URL: ^$ %{REQUEST_URI}

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$RedirectRule ^(.+)$ $1/ [R=301]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Tell me how that works out for you!

Apr 29, 2010 at 2:18 AM
Thanks rswitt, So you are running WordPress MU on IIS 6 and got the individual blog paths working with the code above? What version of the IIRF should I be running?
Apr 29, 2010 at 3:24 PM
Edited Apr 29, 2010 at 3:27 PM

Yes, I have the individual blog paths working.  I'm using Wordpress Mu in the subdirectory model as opposed to the subdomain model (because I'm using Shibboleth authentication which would be complicated with multiple domains), but the rules should still be valid for both.

You can use any version of IIRF after  or including 2.1.1.4 for the first ruleset I listed, as it requires the RewriteBase directive.  The second ruleset (which I've edited slightly due to a misunderstanding of Cheeso's implementation of REQUEST_URI) would require version 2.1.1.12 or later.  The second set isn't really any better, it just uses some of Cheeso's newer features.

If you want some explanation of what I've done in the rules to make it work with IIRF and IIS, feel free to ask.

Coordinator
Apr 29, 2010 at 5:01 PM

Randy, if you write this up, I can put it into the IIRF doc. 
Another alternative is for me to post it as a separate page in the wiki for IIRF, available through the documentation tab.
Actually, I like that idea better.

what do you think?

 

Apr 29, 2010 at 5:04 PM

I like the second option better as well, as it really isn't integral to IIRF itself.

I'll try to write it up soon, today is allocated to integrated my Shibboleth service provider into Wordpress ;-).

 

May 7, 2010 at 11:16 PM
Hi rswitt So how would I amend your post of Apr 28 at 2:09 PM if I install iirf.ini in the root of my site but have WordPress MU installed in a sub-directory e.g /your-wordpress? Am I learning a lot from these posts, thanks so much! Shane
Coordinator
May 8, 2010 at 12:50 AM

Almasty, you're gonna need to be more specific, if you have a specific question.

Don't be afraid to start a new thread.  There's no ned to piggy-back on existing threads.
It makes it easier to follow for future readers, if you introduce a new question, in a new thread.

May 8, 2010 at 1:08 AM
Edited May 8, 2010 at 1:11 AM

That's a very good question, and is the reason I have been discussing fine-tuning the behavior of RewriteBase with Cheeso.

The first question is whether or not you have the /your-wordpress directory set as an application?  It's possible to do it without doing that, but setting your wordpress install as an application will make things far simpler, and is probably a better practice anyway.  If you're not familiar, setting a subdirectory as an application is *really* simple.

Assuming you set it as an application, the solution is simple, Applications can have their own iirf.ini files (right Dino?).  So just place the iirf.ini file in the root of your wordpress install directory, and just update the rewritebase to include the subdirectory.

I should note that the latest version of IIRF requires a small change as well to the above rules. So I believe it should be like (statusInquiry, log location and level should be set to whatever is appropriate for you):

StatusInquiry ON
RewriteLog C:\windows\system32\LogFiles\iirf\iirf
RewriteLogLevel 1
RewriteBase /your-wordpress/

#store original URL in custom header (substitute for missing REQUEST_URI header in IIS)
RewriteHeader X-REWRITE-URL: ^$ %{REQUEST_URI}

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RedirectRule ^(.+)$ $1/ [R=301]


RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

The only change is to the RewriteBase line.  I could have used "RewriteBase ON" but it would have required a lot more modifications from the original wordpress MU URL rewriting rules, so this is cleaner.

I personally had to add another rule because I'm using a Shibboleth authentication plug-in, I'd be glad to share that as well if there's any interest.



        
    
Coordinator
May 8, 2010 at 1:21 AM

Ah , rswitt, you can use either a virtual directory, or an IIS application.  In either case you can use an Iirf.ini specific to that vdir.

 

May 8, 2010 at 3:40 PM
Edited May 8, 2010 at 4:01 PM

That hit the spot. Thanks so much rswitt & I also take on board your suggestion about starting a new thread Cheeso. Sound advice too!

I do have another question though. If I go to

http://example.com/your-wordpress/wp-admin

The rule should re-write it to

http://example.com/your-wordpress/wp-admin/ i.e trailing slash, but it doesn't at the moment. How do I debug this? What would you suggest? Am I not understanding the rule:

RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RedirectRule ^(.+)$ $1/ [R=301]

Almasty

 

PS I did make the your-wordpress dir an application as suggested and placed the iirf.ini listed above in my application root. :)

Coordinator
May 8, 2010 at 4:08 PM

start a new thread?

 

May 10, 2010 at 3:00 PM

http://iirf.codeplex.com/Thread/View.aspx?ThreadId=212155

Jun 1, 2010 at 4:45 PM

rswitt - I have seen other postings where the wp-settings.php file should be updated with the following line -

$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];

Is this required with the IIRF.ini solutions you have provided below?

Thanks,

Paul

 

rswitt wrote:

I've been holding off as Cheeso's been updating IIRF with modifications that make installing it simpler, but I'm happy to show my IIRF.ini file:

 

StatusInquiry ON
RewriteLog C:\windows\system32\LogFiles\iirf\iirf
RewriteLogLevel 1
RewriteBase ON

#store original URL in custom header (substitute for missing REQUEST_URI header in IIS)
RewriteHeader X-REWRITE-URL:  ^$    %{UNENCODED_URL}

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{HTTP_X_REWRITE_URL} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{HTTP_X_REWRITE_URL} ^.*/wp-admin$
RedirectRule ^(.+)$ $1/ [R=301]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

 

This has been working fine for me, as far as I can tell.  With the newest version, you should be able to modify it slightly to:

StatusInquiry ON
RewriteLog C:\windows\system32\LogFiles\iirf\iirf
RewriteLogLevel 1
RewriteBase ON

#store original URL in custom header (substitute for missing REQUEST_URI header in IIS)
RewriteHeader X-REWRITE-URL: ^$ %{REQUEST_URI}

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$RedirectRule ^(.+)$ $1/ [R=301]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Tell me how that works out for you!

 

Jun 2, 2010 at 3:11 PM

 

I have seen other postings where the wp-settings.php file should be updated with the following line -
$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_REWRITE_URL'];
Is this required with the IIRF.ini solutions you have provided below?

 

In a word, no, though I suppose that depends.  It probably was required in older versions of Wordpress, but at least in 2.9.2 there's already code in wp-settings.php that attempts to detect IIS and one of the other major URL rewriter solutions and does that mapping already.  My solution is actually making use of that pre-existing code by using the same header name.  I figured it was easier to do that than modify the wordpress code unnecessarily.

Aug 1, 2010 at 8:15 PM
Edited Aug 1, 2010 at 8:52 PM
Are there any updates for these rules. I'm trying to setup a wordpress 3.0 with multiple website. Using the 2.1 but not getting it to work. It reads the redirects but i have problems with css files. does anyone have an idea thanks
Aug 1, 2010 at 9:00 PM
Edited Aug 1, 2010 at 9:02 PM
germaike wrote:
Are there any updates for these rules. I'm trying to setup a wordpress 3.0 with multiple website. Using the 2.1 but not getting it to work. It reads the redirects but i have problems with css files. does anyone have an idea thanks

Hi guys,
I found my own solution. I use this now for wordpress3.0 multiple websites with windows 2003 iis6.0 and iirf
This is my iirf.ini file:

StatusUrl /iirfStatus RemoteOk StatusInquiry ON RewriteLog C:\windows\system32\LogFiles\iirf\iirf RewriteLogLevel 1 RewriteBase / RewriteRule ^index\.php$ - [L] #store original URL in custom header (substitute for missing REQUEST_URI header in IIS) RewriteHeader X-REWRITE-URL: ^$ %{REQUEST_URI} #uploaded files RewriteRule ^(.*/)?files/$ index.php [L] RewriteCond %{REQUEST_URI} !.*wp-content/plugins.* RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L] # add a trailing slash to /wp-admin RewriteCond %{REQUEST_URI} ^.*/wp-admin$RedirectRule ^(.+)$ $1/ [R=301] RedirectRule ^/index\.php/(.*)$ /$1 [I,R=301] RewriteRule ^/(?!index\.php|wp-|xmlrpc)(.*)$ /index.php/$1 [I,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule . - [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

I hope my code helps others. grtz

Nov 18, 2011 at 9:26 AM
Edited Nov 18, 2011 at 2:41 PM

I know this thread is old but I wanted to say thank you to germaike for the above which is working for my main install however the sub sites (sub folder multi site install) aren't working fully - any ideas?

Working URLS:

http://www.mysite.com/index.php

http://www.mysite.com/wp-admin/

http://www.mysite.com/anotherSite/index.php

http://www.mysite.com/anotherSite/wp-admin/

Not Working:

http://www.mysite.com/postname/

http://www.mysite.com/categoryname/postname/

http://www.mysite.com/anotherSite/

http://www.mysite.com/anotherSite/categoryname/postname/