IIS

Hi,

I realise the specification for aMember is Apache, however, is it possible to use IIS7? I would prefer to not have a second web server install and if it just a matter of URL rewrites or similar I do have the rewrite module installed on IIS. Our Wordpress website is using PHP and MySQL with IIS too.

Cheers,
Rob.

Hi Alexander,

That's great to hear, thanks.

I am using IIS7 URL rewrite. Do you have rewrite rules for web.config e.g.

<rewrite>
<rules>
<rule name="wordpress" patternSyntax="Wildcard">
<match url="wp-content/uploads/*" negate="true" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>

Hi Alexander,

Sorry don't worry. I used the import rules feature in IIS7 to import rules from mod_rewrite. All seems working now.

FYI Rules are -

<rule name="Imported Rule 1" stopProcessing="true">
<match url="^public" ignoreCase="false" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="public.php" />
</rule>
<rule name="Imported Rule 2" stopProcessing="true">
<match url="^js.php" ignoreCase="false" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="js.php" />
</rule>
<rule name="Imported Rule 3">
<match url="\.(js|ico|gif|jpg|png|css|swf|csv)$" ignoreCase="false" negate="true" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="index.php" />
</rule>

Cheers,

Rob.

I'm also using IIS7 URL Rewrite (version 2.0) and I've imported aMember's .htaccess file as well. I got the exact same output as you did, Rob.

I've applied to rules, but unfortunately they do not work for me.

When I go to aMember's home page and click the link to configure, it goes to /setup/ and then still shows me the page telling me I have to click the link to configure.

Everything works fine when I install it on Apache, naturally. But I don't understand how aMember's URL rewriting works.

The .htaccess file in the root is very simple. I do not see how these 3 simple rewrite rules help rewriting urls such as /admin/ and /setup/. I do not see any 'admin' or 'setup' references in the rewrite rules.

Are there more rewrite rules defined outside of the .htaccess? If so, where?

I've tried logging URL rewrites in Apache and couldn't get it to work in less than 60 minutes. So that didn't help either.

It would be helpful if I understood how aMember handles url rewriting. That way I could learn which pretty url goes to which real url and I could compare Apache's rewrites to IIS' rewrites.

I'm stuck in the mud and would like some feedback so I can get aMember working.

Alright, I managed to get it to work. Here's how I did it:

The /setup/ directory doesn't work if you've already got the .htaccess rules imported. So I've:

• imported the rules
• disabled the rules
• let aMember set itself up (ignoring the mod_rewrite not supported message)
• enabled the rules
• started using aMember on IIS

The reason it didn't work, is because rule number 3 rewrites to index.php when all those extensions aren't matched.

The /setup/ dir doesn't match any of the extensions. So it gets rewritten to index.php.

So on IIS, the rewrite rules work as expected. It's on Apache that I don't understand why the /setup/ directory does work.

Does Apache ignore rewrite rules when a directory in a url exists as a physical directory within the site root directory?

I'm glad to have it working, but I still need to know up front whether aMember's normal, every day usage will ever lead me to another one of aMember's physical directories:

• application
• data
• library
• setup

Because if the setup directory doesn't work with rewrite rules enabled, then the others won't either.

The core problem here is that the very same set of rewrite rules behave differently on Apache and IIS.

Who can explain to me where this behavioral difference comes from?

I need to learn more about why it works the way it works. I can't afford to run into unexpected rewrite errors in the near future, when my software goes live.

(I just noticed I'm posting this in a thread in the aMember 3 forum, but I'm using aMember 4 and had the same problem)