Here are the examples of how WebMatrix can be used to create and publish a PHP web site (using WordPress as a showcase).

Installing a PHP application

After installing and launching WebMatrix select “Site from Web Gallery” option and then pick WordPress:

Follow the installation steps as described in Download and Install a PHP application. As you proceed you will notice that WebMatrix downloads and installs the necessary components for running WordPress – the latest version of PHP 5.2 and MySQL. At the end of the installation process you will get a working instance of WordPress, that you can configure and customize further:

Notice the port number used in the URL. This is not the standard port 80 used by default in IIS. The site is not running on IIS that is included with operating system. Instead WebMatrix installs and uses IIS Developer Express, which is a developer-focused version of IIS that runs on all versions of Windows, starting from Windows XP. This is actually very cool because now it is possible to get the latest and greatest IIS features on Windows XP instead of using the good old IIS 5.1 as development web server . But even if you already have Windows 7, you may still want to use IIS Developer Express, because with that you do not need to enable real IIS Web Server included with OS on your development machine.

Even though IIS Developer Express is a lightweight development server it comes with everything needed to run PHP applications, including the latest version of FastCGI module and URL Rewrite 2.0. This means that after you install WordPress with WebMatrix you can enable WordPress’ pretty permalinks by following the instructions at IIS URL Rewrite Module support in WordPress.

Note: By default WebMatrix and IIS Developer Express are not configured to run PHP even if PHP is already installed on the machine. To work this around  install any PHP application via WebMatrix UI. This way WebMatrix will configure IIS Developer Express to handle PHP requests. This is something that will be fixed in future releases of WebMatrix.

Modifying a PHP application

After the WordPress is installed there are several things you can do with it from within WebMatrix. For example you can edit the theme files by using the built-in editor:

You can check what kind of HTTP requests are made by Web Browser to load a typical WordPress page:

(Learn more about this feature at Using WebMatrix Beta: Analyze Your WebSite)

Also, you can check the WordPress database content by using the WebMatrix Database Manager:

And, finally, you can run the search engine optimization analysis and fix any SEO violations found within the application:

(Learn more about this feature at Using WebMatrix Beta: Make your Website SEO Friendly)

Publishing a PHP application

The last step is the publishing of the web application on a live web server. WebMatrix can publish the content to a web server by using various protocols: FTP, FTP/SSL and WebDeploy (note that FTP protocols cannot be used to publish MySQL database). You can pick a hosting provider from the list offered by WebMatrix or you if you know the publishing settings from your hosting provider you can manually enter them in WebMatrix.

When you publish the content the WebMatrix will show you the list of files and the database that will be uploaded to the server. Note also that during publishing the WebMatrix will replace the current database connection settings in wp-config.phpfile with the connection settings used on a hosting web server. WebMatrix will extract that information from the connection string that you specify in publishing settings:

(Learn more about publishng web sites at Using WebMatrix Beta: Publish Your WebSite)

Feedback and suggestions

The WebMatrix is a beta release and the WebMatrix team is open to any constructive feedback on how to improve the product. Do you have any suggestions or have you run into any problems when using WebMatrix? What PHP related features would you like to see in this product? Please let the team know by starting the thread on WebMatrix forum or by leaving a comment here.

To configure WordPress to use WinCache user cache API’s copy the following code and put it in the file named object-cache.php located at the /wp-content/ directory of your WordPress site. Note that this code was copied from here and the only change was to replace all the APC cache function with corresponding WinCache functions.

<?php

/*
Name: WinCache Cache
Description: WinCache backend for the WP Object Cache.
Version: 0.1
URI: http://ruslany.net/
Author: Ruslan Yakushev

Install this file to wp-content/object-cache.php

Big thanks to Mark Jaquith (http://markjaquith.wordpress.com/)
whose apc-object-cache.php was used as a basis for this code.
*/

// gracefully revert to default cache if WinCache is not installed
if ( !extension_loaded('wincache') ||
      !function_exists('wincache_ucache_get') ||
      strcmp(ini_get('wincache.ucenabled'), "1") )  {
 include_once(ABSPATH . WPINC . '/cache.php');
} else {

function wp_cache_add($key, $data, $flag = '', $expire = 0) {
  global $wp_object_cache;
  return $wp_object_cache->add($key, $data, $flag, $expire);
}

function wp_cache_close() {
  return true;
}

function wp_cache_delete($id, $flag = '') {
  global $wp_object_cache;
  return $wp_object_cache->delete($id, $flag);
}

function wp_cache_flush() {
  global $wp_object_cache;

  return $wp_object_cache->flush();
}

function wp_cache_get($id, $flag = '') {
  global $wp_object_cache;
  return $wp_object_cache->get($id, $flag);
}

function wp_cache_init() {
  global $wp_object_cache;
  $wp_object_cache = new WP_Object_Cache();
}

function wp_cache_replace($key, $data, $flag = '', $expire = 0) {
  global $wp_object_cache;
  return $wp_object_cache->replace($key, $data, $flag, $expire);
}

function wp_cache_set($key, $data, $flag = '', $expire = 0) {
  global $wp_object_cache;
  return $wp_object_cache->set($key, $data, $flag, $expire);
}

class WP_Object_Cache {
  var $global_groups = array ('users', 'userlogins', 'usermeta');
  var $cache = array ();

  function add($id, $data, $group = 'default', $expire = 0) {
    return $this->set($id, $data, $group, $expire);
  }

  function delete($id, $group = 'default') {
    $key = $this->key($id, $group);
    $result = wincache_ucache_delete($key);
    if ( false !== $result )
      unset($this->cache[$key]);
    return $result;
  }

  function flush() {
    wincache_ucache_clear();
    return true;
  }

  function get($id, $group = 'default') {
    $key = $this->key($id, $group);
     if ( isset($this->cache[$key]) )
      $value = $this->cache[$key];
    else
      $value = wincache_ucache_get($key);
    /* echo "Cache key: $key<br/>";
    echo 'Cache value:<br/>';
    var_dump($value);
    echo '<br/>'; */
    if ( NULL === $value )
      $value = false;
    $this->cache[$key] = $value;
    return $value;
  }

  function key($key, $group) {
    global $blog_id;
    if ( empty($group) )
      $group = 'default';
    if (false !== array_search($group, $this->global_groups))
      $prefix = '';
    else
      $prefix = $blog_id . ':';
    return md5(ABSPATH . "$prefix$group:$key");
  }

  function replace($id, $data, $group = 'default', $expire = 0) {
    return $this->set($id, $data, $group, $expire);
  }

  function set($id, $data, $group = 'default', $expire = 0) {
    $key = $this->key($id, $group);
    $result = wincache_ucache_set($key, $data, $expire);
    if ( false !== $result )
      $this->cache[$key] = $data;
    return $result;
  }

  function stats() {
    $wincache_info = wincache_ucache_info();
    echo "<p>\n";
    echo "<strong>Cache Hits:</strong> {$wincache_info['total_hit_count']}<br/>\n";
    echo "<strong>Cache Misses:</strong> {$wincache_info['total_miss_count']}<br/>\n";
    echo "</p>\n";
    if ( ! empty($this->cache) ) {
      echo "<pre>\n";
      print_r($this->cache);
      echo "</pre>\n";
    }
  }

  function WP_Object_Cache() {
   // Nothing here
  }
 }
}
?>

You can also download the code by using the link below:

Object Cache for WordPress

Make sure that the code is saved in a file called object-cache.php inside of the /wp-content/ directory.

That should be all you need to do. To verify that the WordPress is actually using the object cache use the WinCache Statistics Script and check the “User and Session Cache” page:

Once you install or upgrade to this version of the plugin you should see a new menu group in the WordPress Dashboard:

From that menu you can get to the Statistics page where you can see how many times your site visitors watched your video files:

The implementation idea for the statistics page was re-used from the WP-Postratings, which is a very popular plugin written by Lester ‘GaMerZ’ Chan.

Other improvements in this version include:

• Minified JavaScript files for the player, which will help reduce the download time;
• Fixed incompatibility bug with NextGen Gallery plugin;
• Complete localization support and translation into Russian (ru_RU).

Download the latest version of the plugin from the plugin page at WordPress plugin directory. To get more information about the plugin refer to the following resources:

• Usage instructions
• How to encode video content for the WP Media Player
• Changelog
• Download statistics

• PHP 5.3 has a number of Windows-specific bug fixes and improvements that address stability and functionality problems which existed before when running PHP on Windows. For detailed list of all the changes and fixes, refer to the news.txt file included within the PHP zip file.
• PHP 5.3 has been compiled with the latest version of C compiler (VC9), which makes it run faster on Windows than any previous versions of PHP (which were compiled with VC6).
• WordPress 2.8 has built-in support for IIS 7 URL Rewrite Module. Refer to IIS 7 URL Rewrite Module support in WordPress 2.8 for more details.

Overall, the upgrade went pretty smoothly and the only thing that was different from the usual process of setting up PHP on Windows was the date.timezone setting in php.ini file. Starting with PHP 5.3, this setting must be explicitly set, e.g.:

date.timezone = America/Los_Angeles

After this successful upgrade I guess it is time now “to reward myself by reading that book or an article that I’ve been putting off, or simply sitting back for a few moments and let the world pass me by”.

Have you tried upgrading to PHP 5.3 on IIS recently? What was your experience?

Here is how the process of updating Permalinks structure will look like in WordPress 2.8 on IIS 7:

1. Go to Settings –> Permalinks page and choose the permalink structure that you prefer:
   
2. After clicking on “Save Changes” button the generated rewrite rule will be displayed with the instructions on how to update the web.config file manually:
   
3. Now you can copy the the given XML and put it into the web.config file inside of /<configuration>/<system.webServer>/<rewrite>/<rules> element and that’s it!
4. Alternatively – instead of manually editing the web.config file you can have WordPress to update it automatically for you. To do that, temporarily grant WordPress write access to web.config file and click on “Save Changes” again. WordPress will add its rewrite rule into the proper location inside of the web.config file. Do not forget to revert the write permission on web.config file after the rule has been saved.

If you want to try this functionality, as well as all the other new features in the upcoming WordPress 2.8 release, you can download the latest nightly build. Also, pretty soon the 2.8 beta will be available.

Thanks to the WordPress development community for adding this functionality! Specifically, big thanks to peaceablewhale, Denis-de-Bernardy, hakre, sivel and ryan for directly working on the patch and contributing to it in many different ways: testing, code reviewing, cleaning up the code and checking it in.

Download the latest version of the plugin from here: WP Media Player.

The biggest improvement in this version of the plugin is the addition of the user interface for uploading video content and for insertion of the media player into blog posts and pages. Here is how it looks like.

Add a media player to a blog post or a page by clicking on the “Silverlight Video” button:

Upload a new video file or specify a URL of the video content:

Or choose a video file from WordPress media library:

After video content has been chosen, modify media player parameters, if necessary, and then insert the media player into the post:

More information about the plugin can be found at the plugin homepage.

Prerequisites

First thing to make sure is to confirm that IIS Forms authentication and URL authorization modules are installed and enabled on your IIS server. To quickly check that, open an elevated command prompt and run the following commands:

C:\Windows\System32\inetsrv>appcmd list modules | find "FormsAuthentication"
MODULE "FormsAuthentication" ( type: System.Web.Security.FormsAuthenticationModule,preCondition: )

C:\Windows\System32\inetsrv>appcmd list modules | find "UrlAuthorization"
MODULE "UrlAuthorization" ( type: System.Web.Security.UrlAuthorizationModule, preCondition: managedHandler )
MODULE "UrlAuthorizationModule" ( native, preCondition: )

If the output from the commands look similar to above then the necessary modules are installed.

Another thing to ensure is that the WordPress site is hosted in an Application Pool with Integrated Managed Pipeline Mode. To check that run the following command from elevated command prompt (replace “DefaultAppPool” with the name of your AppPool if necessary):

C:\Windows\System32\inetsrv>appcmd list apppools | find "DefaultAppPool"
APPPOOL "DefaultAppPool" (MgdVersion: v2.0,MgdMode: Integrated,state: Started)

The output should contain MgdMode:Integrated.

Configuration steps

Download the zip file below:

IIS Forms Authentication for WordPress (4.1 KB)

Extract the two folders – App_Code and App_Data – into the root folder or your WordPress web site. For example if your WordPress files are located in folder C:\inetpub\wwwroot, then there should be two new files present at the following paths:

C:\inetpub\wwwroot\App_Code\CustomProvider.cs
C:\inetpub\wwwroot\App_Data\Users.xml

The CustomProvider.cs file contains an implementation of membership provider for IIS that uses Users.xml file as a storage for usernames and passwords. To learn more about providers refer to the Membership Providers article. The code for CustomProvider.cs was literally copied from that article.

The Users.xml file is a simple credentials storage. Its content looks like below:

<Users>
  <User>
    <UserName>your_username_here</UserName>
    <Password>your_password_here</Password>
    <EMail>user@ruslany.net</EMail>
  </User>
</Users>

Note that it is important that this file is located in App_Data directory, because this directory, as well as App_Code, is protected by IIS Request Filtering module, which prevents anyone from requesting any files from these folders.

Also it is important to pick a user name and a password different from the ones that are used for the WordPress authentication.

Also extract the Login.aspx file into the root folder of the web site, e.g.:

C:\inetpub\wwwroot\Login.aspx

Now you need to register this custom membership provider and enable Forms authentication. To do that add the following XML configuration element into the <configuration> element inside of the web.config file, located at the root folder of your WordPress site:

<system.web>
  <authentication mode="Forms" />
  <membership defaultProvider="AspNetReadOnlyXmlMembershipProvider">
    <providers>
       <add name="AspNetReadOnlyXmlMembershipProvider"
                type="ReadOnlyXmlMembershipProvider"
                description="Read-only XML membership provider"
                xmlFileName="~/App_Data/Users.xml" />
    </providers>
  </membership>
</system.web>

With the custom provider registered and configured, it is time to configure IIS to protect wp-admin folder with extra authentication that uses this custom provider. To do that add the following XML configuration fragment into the <configuration> element inside of the web.config file, located at the root folder of the WordPress site:

<!-- Deny access to wp-admin for anonymous users -->
<location path="wp-admin">
  <system.webServer>
      <security>
          <authorization>
              <add accessType="Deny" users="?" />
          </authorization>
      </security>
  </system.webServer>
</location>
<!-- Allow access to wp-admin/css folder for anonymous users -->
<!-- this is needed in order for WordPress login page to display correctly -->
<location path="wp-admin/css">
  <system.webServer>
    <security>
      <authorization>
        <remove users="?" roles="" verbs="" />
      </authorization>
    </security>
  </system.webServer>
</location>
<!-- Allow access to wp-admin/images folder for anonymous users -->
<!-- this is needed in order for WordPress login page to display correctly -->
<location path="wp-admin/images">
  <system.webServer>
    <security>
      <authorization>
        <remove users="?" roles="" verbs="" />
      </authorization>
    </security>
  </system.webServer>
</location>

Last thing you will need to do is to configure IIS modules that are used for Forms Authentication and for URL authorization to run for all kinds of requests. Both those modules are Managed modules (that is they are implemented using .NET Framework) and by default they are configured to run only for requests that are made for ASP.NET content. In order for them to work with PHP content then need to be configured to run for all requests. This can be done by using the following configuration section. Add it inside of <configuration>/<system.webServer> element:

<modules>
    <remove name="UrlAuthorization" />
    <remove name="FormsAuthentication" />
    <remove name="DefaultAuthentication" />
    <add name="DefaultAuthentication"
               type="System.Web.Security.DefaultAuthenticationModule" preCondition="" />
    <add name="FormsAuthentication"
               type="System.Web.Security.FormsAuthenticationModule" preCondition="" />
    <add name="UrlAuthorization"
               type="System.Web.Security.UrlAuthorizationModule" preCondition="" />
</modules>

At this point the WordPress wp-admin directory is protected by IIS Forms Authentication in addition to the standard WordPress authentication. Update the users.xml file with the username and password of your choice and then try to request http://localhost/wp-admin/. The IIS Forms Authentication logon page will be shown first:

Once you provided the user name and password as specified in users.xml file, the standard WordPress login page will be shown next. In that page you can provide your WordPress logon credentials:

Now the entire content of the wp-admin directory is protected by two different authentication mechanisms, which makes it harder for anyone to hack into it. And the nice thing about this configuration is that it can be done even if your site is hosted on a shared server. All that is necessary is to have ASP.NET and IIS URL authorization enabled on a shared server by a shared hosting provider.

Download all the necessary files as well as an example of web.config file from the link below.

IIS Forms Authentication for WordPress (4.1 KB)

Also check out how this protection actually works by trying to navigate to http://ruslany.net/wp-admin/.

Description and Features

The plugin has the following features:

• Default player configuration settings, such as size, thumbnail, auto load and auto play.
• Per-instance player configuration settings that can be used to customize each individual player within or across blog posts.
• Unlimited number of players within the same blog post or page.
• Option to not load players on the home page of the blog. This helps to reduce the amount of content to download for visitors who do not want to watch a video.
• 6 player styles

Here is an example of how the media player plugin works:

Play Video

(the video may play with interruptions – my server’s internet connection is pretty slow)

Download and Install

Download the plugin from here:

WP Media Player

The plugin has been tested on WordPress versions from 2.5 up to 2.7.  Once you downloaded the plugin files follow these steps to install and configure it:

Step 1: Upload wp-media-player directory (including all files and directories withing) to the /wp-content/plugins/ directory. Make sure that the path to the main plugin php file is /wp-content/plugins/wp-media-player/wp-media-player.php. If path does not look like this then plugin may not show up in the WordPress plugins page.

Step 2: Activate the plugin through the ‘Plugins’ menu in WordPress.

Step 3: Visit the plugin settings options (Options – WP Media Player) for WordPress 2.3.x, (Settings – WP Media Player) for WordPress 2.5.x-2.7

Usage walkthrough

To add a player to a blog post or a page, follow these steps:

Step 1: Encode the video to a Windows Media Video (WMV) format by using Microsoft Expression Encoder or Windows Media Encoder. If you use Windows Media Encoder then follow these instructions to properly encode the video content for Silverlight.

Step 2: Upload the video to WordPress either via FTP or by clicking on “Add Video” in the post editing page:

When uploading the video, take a note of the absolute URL path where the video file has been placed to. Do not click on “Insert into Post” button!

Step 3: Place the following tag inside of the blog post content where you want the video player to appear:

[mediaplayer src=”/absolute/url/path/to/video/file.wmv”]

Usage examples

To use a custom placeholder image instead of the default one use the “thumb” parameter, e.g.:

[mediaplayer src=”/absolute/url/path/to/video/file.wmv”
thumb=”/absolute/url/path/to/thumb/file.jpg”]

To specify player’s width and height, use the “width” and “height” parameters, e.g.:

[mediaplayer src=”/absolute/url/path/to/video/file.wmv” width=320 height=240]

To change auto load and auto play settings use “autoLoad” and “autoPlay” parameters, e.g.:

[mediaplayer src=”/absolute/url/path/to/video/file.wmv” autoLoad=1 autoPlay=0]

Please try it out on your WordPress installation and let me know if you find any bugs or if you have any suggestions.

WP Media Player

This post has been updated to ensure that instructions are correct for the latest versions of the WP Super Cache plugin and IIS URL Rewrite  Module.

The performance of WordPress may be sufficient for an average blog that gets a few page hits per minute. However, if your blog post suddenly shows up on digg.com or any other social networking site, it may become challenging for server to handle such huge spike in traffic. A few options exist to help server to cope with flood of requests:

• IIS Output Caching
• WP Cache plugin for WordPress
• WP Super Cache plugin for WordPress

In this post I will explain the benefits and drawbacks of each option and walk through the steps for configuring IIS and WordPress to use those options.

Prerequisites

Before performing the configuration steps described in this post, it is necessary to complete the following prerequisites:

1. Install WordPress (Follow the instructions in this article or use the instructions from the official WordPress site).
2. Install Microsoft URL Rewrite Module 1.1 for IIS 7
3. Enable “Pretty Permalinks” in WordPress by following steps described in this article.

IIS Output Caching

IIS 7.0 has a very powerful output caching infrastructure, which can cache response data in kernel-mode (http.sys) and in user-mode memory space (IIS worker process). The Output Caching can be used with static web resources as well as with semi-dynamic web applications, where the content is generated dynamically, but is not likely to change from request to request. A blog engine is a perfect example of semi-dynamic web application.

To enable IIS Output Caching for WordPress you can use IIS Manager UI:

Or add this configuration section into the web.config file located at the root folder of the WordPress site:

<caching>
  <profiles>
    <add extension="*" policy="CacheForTimePeriod"
      kernelCachePolicy="CacheForTimePeriod"
      duration="00:00:30" />
  </profiles>
</caching>

With this configuration IIS will cache the response generated by WordPress in memory for 30 seconds, thus avoiding heavy script processing and database I/O for all subsequent requests. This would increase the throughput significantly – for example on my Virtual PC the WordPress throughput grew from 10 requests per seconds to more than 2500 requests per seconds after enabling Output Caching.

However, there are certain drawbacks from using Output Caching. Some of the dynamic blog features are lost when cached page is served instead of a page generated by WordPress. For example, when a visitor submits a comment for a blog post there will be no confirmation message shown to indicate that the comment has been submitted. This is because the page shown to the user after comment submission is served from cache. This may cause visitor to submit same comment several times. This problem can be somewhat mitigated by reducing the cache timeout, but there is still a chance that stale page may be served to a visitor after comment submission. To reliable prevent this from happening a more customized solution for WordPress is necessary, which is a WP Super Cache plugin.

WP Cache and WP Super Cache

WP Super Cache is a very popular plugin that generates temporary static html pages from dynamic WordPress blog. After a html file is generated the server will serve that file instead of processing the comparatively heavier and more expensive WordPress PHP script. Since this is a WordPress-customized solution, it is able to smartly handle such situations such submission of comments or serving pages to logged on users. Specifically, the plug in will serve static html pages only to:

1. Users who are not logged in
2. Users who have not left a comment
3. Or users who have not viewed a password protected post.

Typically 99% of the visitors do not do any of the above actions, so the static html pages will be served most of the time, thus increasing server throughput significantly.

WP Super Cache plugin has two modes of operation: WP-Cache and WP-SuperCache. With WP-Cache the static files are still generated but every request will require loading of PHP engine to serve those files. WP-SuperCache relies on URL rewriting to bypass PHP altogether when serving cached static files.

To configure WP Super Cache on IIS 7.0 follow these steps:

Step 0: Make sure that wp-content folder is writable by web server

Step 1: Download the WP Super Cache plugin and unpack it into the WordPress plugins folder “wp-content\plugins”. This will create “wp-content\plugins\wp-super-cache” folder.

Step 2: Copy the file “wp-content\plugins\wp-super-cache\wp-cache-phase1.php” to “wp-content\advanced-cache.php”

Step 3: Add the following rewrite rule to the web.config file located at the root folder of WordPress site. Make sure that the “WP Super Cache” rule is before the WordPress rule for pretty permalinks. Typically the <rewrite> section will look as below

<rewrite>
<rules>
  <rule name="wp super cache" stopProcessing="true">
    <match url="(.*)" />
      <conditions logicalGrouping="MatchAll">
        <add input="{REQUEST_METHOD}" pattern="^POST$" negate="true" />
        <add input="{QUERY_STRING}" pattern=".*=.*" negate="true" />
        <add input="{QUERY_STRING}" pattern=".*attachment_id=.*" negate="true" />
        <add input="{HTTP_COOKIE}" pattern="^.*(comment_author_|wordpress|wp-postpass_).*$" negate="true" />
        <add input="{HTTP_USER_AGENT}" pattern="^.*(2.0\ MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800).*" negate="true" />
         <add input="{DOCUMENT_ROOT}/wp-content/cache/supercache/{HTTP_HOST}/{R:1}index.html"
                                    matchType="IsFile" />
      </conditions>
      <action type="Rewrite" url="wp-content/cache/supercache/{HTTP_HOST}/{R:1}index.html" />
  </rule>

  <rule name="WordPress Pretty Permalinks" patternSyntax="Wildcard">
    <match url="*" />
    <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>

Step 4: Add the following line into the wp-config.php file above the “require_once(ABSPATH.’wp-settings.php’);” line:

define( 'WP_CACHE', true );

Step 5: Login to WordPress and activate the plugin by going to “Plugins” tab. Then go to “Settings” tab and click on “WP Super Cache”. If everything was configured correctly you should see the plugin’s configuration page.

Step 6: Go to “wp-content\cache” folder, which should have been created when plugin was activated. Create a new web.config file there, open it and paste the following content inside:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Cache-Control" value="max-age=300, must-revalidate" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

This configures IIS to send Cache-Control response header for any of the cached html pages. That header will force the browser to expire the locally cached response after 5 minutes.

To check that the WP Super Cache actually works, set its status to ON in the plugin configuration page, then clear all the browser cookies and make a request to the blog page. Alternatively you can use WFetch to make a request. If WP Super Cache works then when you make a request to http://wordpress/2008/04/hello-world/, the response will be cached as a static file in \wp-content\cache\supercache\wordpress\2008\04\hello-world\index.html. When next time you request the same page, the rewrite rule “WP Super Cache” will rewrite the URL to the “wp-content\cache\supercache” folder, thus IIS will serve static html file without even invoking PHP engine.

Conclusion

Here is the comparison of server throughput in requests per second with three output caching solutions for WordPress when requesting http://wordpress/2008/04/hello-world:

The performance of WP Super Cache is comparable with performance of IIS Output Caching because with WP Super Cache IIS is just serving static files, which is what IIS is very good at.

So, when to use which option? Here are the pros and cons of each caching solution:

The information in this post is not applicable anymore because the update that fixes the custom errors problem in IIS 7.0 FastCGI module has been made available . Read the release announcement to get more details about the update.

Recently, I found out that my WordPress powered blog did not correctly handle 404 – File Not Found errors. When a request was made to a non-existent page, then instead of getting nice WordPress based error page, visitors used to get a generic IIS 7.0 404 error page. Somehow, I have missed that part of the configuration when I set up WordPress initially. The fix for that turned out to be very simple, but since it seems to be a very common configuration task when hosting WordPress on IIS 7.0, I decided to explain the necessary configuration steps.

By default IIS is configured to return detailed error messages for local requests and custom error messages for remote requests. So when request is made to http://ruslany.net/boguspage, the server returns this:

This is a custom IIS error page. Typically, this is not the kind of response you would want your blog visitors to see. Instead, it would be nice to return an error page generated by WordPress. Almost all WordPress themes have a template for the 404 error called 404.php. This template tells WordPress how to generate an error page, that should be returned when URL is not found on the server. To return that page instead of the generic IIS page do the following:

1. In IIS Manager open the “Error Pages” feature UI for your web site
2. Select the status code 404 from the list view and click “Edit” action
3. In the “Edit Custom Error Page’ dialog choose an option “Execute a URL on this site”
4. Enter the URL as “/index.php?error=404“

Here is how the IIS Manager UI will look like:

Alternatively, you can add the following configuration section into the <system.webServer> section of web.config file located at the root folder of your web site:

<httpErrors>
  <remove statusCode="404" subStatusCode="-1" />
  <error statusCode="404" prefixLanguageFilePath=""
path="/index.php?error=404"
responseMode="ExecuteURL" />
</httpErrors>

Note, that by default the IIS “Error Pages” feature is not delegated for being configured via web.config file. This means that if you use shared hosting, you can add <httpErrors> section to web.config file only if hosting provider has delegated the “Error Pages” feature.

Once the configuration change has been made, any request to a non-existent URL will result in the standard WordPress error response: