WordPress 3.5 on IIS 8.0 is unable to save a web.config file

This website Saotn.org is hosted on Windows Server 2012 with IIS 8.0 with WordPress for a few months now, and everything is running very smooth. And I would never hit this bug because I don't need to change my permalinks structure, or save any other plugin setting which would want write to a web.config file. One of my colleagues on the other hand, just moved his website to one of our IIS 8.0 web servers and he noticed he couldn't save his Permalinks structure in the IIS web.config file. This can be pretty annoying ;-) Quick fix attached...

With a few other colleagues we went to investigate. Because of recent issues we encountered with Helicon Ape and the .NET Framework (more on that in a later post), that was our fist point of investigation. Maybe a recent update of Helicon Ape, or the .NET Framework (Patch Tuesday security updates), broke some permission structure? Well, we were wrong...

During investigation one colleague looked at the file wp-include/vars.php, and he noticed a hard check on IIS versions 7.(*). The result was that WordPress 3.5 on IIS 8.0 is unable to write a web.config file, due to insufficient server version checking. Did the WordPress developers never think of IIS 8.0? Are we the first hosting company hosting WordPress websites on IIS 8.0? ;)

Want to see? Open up your wp-include/vars.php file and look at lines 95 - 99:

/**
 * Whether the server software is IIS 7.X
 * @global bool $is_iis7
 */

$is_iis7 = $is_IIS && (strpos($_SERVER['SERVER_SOFTWARE'], 'Microsoft-IIS/7.') !== false);

Quick fix for WordPress 3.5+ and IIS 8.0

The quickest fix is to change this line to:

$is_iis7 = $is_IIS && (strpos($_SERVER['SERVER_SOFTWARE'], 'Microsoft-IIS/7.')
 || strpos($_SERVER['SERVER_SOFTWARE'], 'Microsoft-IIS/8.') !== false);

This extends the check to IIS "7.*" or "8.*", but I can imagine a more elegant fix would exist.

WordPress 3.5 on IIS 8.0 bug reported

We filed this as a bug in ticket #23533 on core.trac.wordpress.org. We're confident a proper fix will be released soon. According to the WordPress devs, the bug was introduced in WordPress 3.4.

WordPress' patch

Updated: 9-7-2013:
You can find the approved patch for the reported bug in WordPress Changeset 24594.

Thank you very much! <3 ❤️