I have a Wordpress website installed in IIS and it is working fine. On a subfolder I have and ASP.NET application which also works allright.

Wordpress URL rewriting causes a series of problems on the application living in the subfolder. The solution for that is simple: my root web.config file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
    <customErrors mode="Off"/>
  <location path="." inheritInChildApplications="false">
          <rule name="wordpress" enabled="true" patternSyntax="Wildcard">
            <match url="*" negate="false"/>
            <conditions logicalGrouping="MatchAll">
              <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
              <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
            <action type="Rewrite" url="index.php"/>

The key thing is here: inheritInChildApplications="false" inside the <location> tag. This will prevent the rewrite rules from being propagated to the child ASP.NET application, which causes harm, as I have explained before.

So far, so good.

But imagine that I simply enter the Permalinks configuration page which lives in this path: wp-admin/options-permalink.php.

In that case, something terrible happens: Wordpress automatically reads my web-config file, probably searching for tag <system.webServer> under the <configuration> tag. But it is not there because I have wrapped <system.webServer> under the <location> tag.

Since it doesn't find the rewrite rules there, Wordpress simply adds the <system.webServer> block all over again, causing it to duplicate and it saves the web.config file.

Having two <system.webServer> blocks on the web.config file causes the website to break miserably with a 500 error message. The server log will tell me that Config section 'system.webServer/rewrite/rules' already defined. Sections must only appear once per config file.

Please, not that I don't have to hit 'save changes' on the Permalinks config page for this tragedy to happen, all I have to do is enter the page. Wordpress will then do all the checks and resave the web.config file on its own.

Although I don't plan to enter that configuration page, I consider it a risk that entering that page by accident one year from now when the website is in production will trigger these horrid 500 errors.

So after all this long post, my question is: do you know of any methods or any configurations that will stop Wordpress from automatically saving the web.config file again when I enter the Permalinks configuration page? Thank you.

  • 2
    I haven't tested it, but I think the flush_rewrite_rules_hard filter may be your answer.
    – Milo
    Commented Feb 17, 2016 at 19:46
  • Hi, Milo, thank you. I have read the documentation you have pointed out and this surely seems to be the path to follow. Question from a Wordpress newbie: where should I place the new piece of code? I have tried using apply_filters ('flush_rewrite_rules_hard', false); both in wp-config.php and my theme's functions.php with no success. Thank you. Commented Feb 18, 2016 at 10:59
  • 1
    your code should use add_filter, so your filter is applied to the value when core uses apply_filters to run your filter.
    – Milo
    Commented Feb 18, 2016 at 18:13
  • oh, ok, I see, thank you, I will try that later on today. Commented Feb 18, 2016 at 18:39
  • Hey, Milo, it did work! Thanks a Million. Feel free to post it as a regular answer and I will mark it as resolved. Commented Feb 18, 2016 at 20:43

1 Answer 1


You can prevent a “hard” flush, which updates .htaccess (Apache) or web.config (IIS), with the flush_rewrite_rules_hard filter.

We can also use the __return_false helper function here.

add_filter( 'flush_rewrite_rules_hard', '__return_false' );

This code can be placed in your own plugin or a theme's functions.php file.

  • Milo, thank you for sharing your solution. I added the add_filter directive into wp-config.php, though, because I don't see it as a theme-related solution. If by any chance I decide to create a new theme tomorrow, that important instruction would be gone. Since it should be kept, the best place to put it seems like the base website config file. Commented Feb 19, 2016 at 3:42
  • 1
    I agree, it's not theme-related. The config file seems like a good choice, since it is server-related. It's an unorthodox location for a filter though. Another option would be a Must Use Plugin.
    – Milo
    Commented Feb 19, 2016 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.