note: this page is something I’m writing and which is unfinished..
On this page I want to do two things. First, I’m going to give folks my own take on the problems associated with running WordPress from IIS (I absolutely don’t think that it’s the kind of huge pain in the butt that some would have you believe). Second, and largely for my own reference, I wanted to document some of the issues, and, the tweaks required to get WordPress humming along on IIS. Some of the materials contained on this page are “borrowed” (copied almost completely) from other web sites. So, this is just some opinion and a little “fix it” library of sorts…
Linux makes more sense, BUT…….
Powered by MySQL and PHP, the WordPress platform is obviously much more at home on some variant of Unix (Linux, BSD, etc.). That’s because while a Windows Server can run MySql and PHP (with little or no problems, in my experience) IIS is really designed for the .ASP.net web application framework and Microsoft’s SQL database system. It’s fair to say that WordPress – like most open source packages – is designed, from the ground up, to run best on a LAMP stack (Linux, Apache, Mysql and, PHP). So, it’s easier to run WordPress on a Linux machine – but it’s also not very difficult to run it from a Windows machine with IIS (obviously, PHP and MySQL must be integrated into the server set up). For what it’s worth, this site is currently running from Server 2008 RC2 and IIS 7. By the way, I used to run this from Server 2003 and IIS 6 and it ran equally well.
So choosing the Linux platform to host WordPress may arguably be the best, or, the most logical choice. On the other hand, in my opinion, the difficulties (and limitations) associated with running WordPress from IIS are wildly exaggerated and misrepresented around the web.
A big consideration: who’s hosting your site?
A lot of the grousing you hear about IIS and WordPress, I believe, comes from folks who wanted to build a web site using WordPress and who – for one reason or another – opted to purchase a Windows hosting plan. In my opinion, of course, when you have a choice you should probably buy a Linux hosting plan if you’re planning on running WordPress. Still, If you’ve got a first class web host, running WordPress on IIS isn’t necessarily a problem. Because there are some oddball issues running WordPress on IIS – particularly with permissions – I think that most of the people who really run into problems with this set up are using smaller, “economy” web hosting outfits who simply don’t know what they’re doing. Plain and simple, while running WordPress from IIS is not that big of a problem, you do need to tweak a few things to get everything running smoothly. In my case I’m running IIS from a local server, and, getting around things like permissions problems (and other issues) is pretty simple. If you’re going to run WordPress and you’re buying hosting, do some research and make certain that your hosting company is experienced with this sort of thing. Otherwise, run the darned thing yourself! It’s really not very difficult, and, this will give you the opportunity to adjust things as required. If you’re hosting WordPress on a local server, using IIS, you should have very few problems that are of any real consequence – nothing you can’t work out in a quick minute. What if you’re not technically inclined and don’t wish to run a server yourself? You should have just about zero problems with a Windows hosting plan, and WordPress, if you have a top notch hosting provider. Again, before paying for a hosting plan do some research to see if your provider is knowledgeable regarding hosting WordPress on their Windows servers – or, just run it yourself.
Common Issues with WordPress on IIS
So, what are some of the biggest problems trying to run WordPress from IIS? I’ve already mentioned permissions, but, off the top of my head here’s a quick list:
- Permissions (particularly as they relate to uploads and plugins)
- Permalinks/SEO
- Plugins
- Mime types
Let’s talk about these various, pesky problems…
- Permissions: WordPress, like all open source packages, comes bundled with instructions for “chmodding” files – the Nix command/method for setting file permissions. Well, the chmod command is something which doesn’t exist on Windows…so some of the directions that are bundled with WordPress aren’t a lot help on IIS. On the other hand, you can set permissions which are functionally identical on a Windows server – but they’re set from a graphical user interface (and, again, don’t have anything to do with “chmodding”). Obviously your web host will have to set these permissions correctly, or, you’ll have to set them yourself if your hosting your own site. But the important thing is this: if the permissions are set correctly on IIS, WordPress – in the vast majority of scenarios – will run and function just fine….just like Linux. IIS requires that you set grant liberal permissions for the “IIS_IUSR”, or, simply the “IUSR” for most things to work. On a Windows server, for instance, the “C:\WINDOWS\Temp” folder must include read/write permissions granted to one of the aforementionded users or updates and uploads won’t work. Big deal (?). Simply set these permissions, and, everything works!
- Permalinks/SEO: In a default installation of WordPress adding a new page, or post, produces a page with a URL that looks something like this:
http://www.webputzer.com/wp-admin/post.php?post=9122
Let’s say that the new post you just made was an article called “Why I Love My Dog”. In the WordPress administrative area you can choose to use custom permalinks that will alter the above example to look like the following – and, thereby, be more SEO friendly:
http://www.webputzer.com/wp-admin/why-I-love-my-dog/
The issue of producing SEO friendly post/page titles (often referred to as “pretty permalinks”) on IIS is, in my opinion, the strongest argument for using Linux versus IIS for WordPress. In a nutshell, while there are some workarounds to produce pretty permalinks on IIS 6 they are extremely involved and a lot of people – including myself – simply resign themselves to using the default style WordPress post and page titles (on IIS 6).
From the web – various tweaks and fixes
There are a lot of reasons why you should avoid hosting WordPress on a Windows/IIS server, but sometimes you have no choice. One of the most common issues when getting a WordPress site up and running on IIS is that the image uploader tends to be broken out of the box.
The cause and solution for this problem can vary greatly, but generally it has to do with file system permissions on the Windows box. If you are completely unable to upload an image through WordPress and are greeted with an error along the lines of:
The uploaded file could not be moved to C:\Some\Directory
There is a strong chance that the following steps will correct the issue for you.
- wp-content permissions
The first step is to adjust the folder permissions on the wp-content folder of your WordPress installation.
To do that, navigate to your blog installation directory and right click on the wp-content folder and choose “Properties”.Next, click the Security tab.
On the wp-content properties dialog, click the Edit button to change the file permissions. On the following screen, look for an account labeled IUSR. Note that this is not the same as IIS_IUSRS. If IUSR exists, select it and grant it “Modify” permissions if it does not have them already. If the account does not exist, click the “Add” button to add it, then grant it “Modify” permissions. When you’re finished hit OK.
- PHP Temp folder permissions
The second step is to adjust the folder permissions on the Temp directory that PHP uses when uploading images. By default, this directory is C:\Windows\Temp but if your php.ini file was edited to modify that folder, use the modified directory. Navigate to C:\Windows and right click the “Temp” folder then choose “Properties”.
Next click the Security tab.
On the Temp properties dialog, click the Edit button to change the file permissions. On the following screen, look for an account labeled IIS_IUSRS. Note that this is different than the steps above. If IIS_IUSRS exists, select it and grant it “Read” permissions. If the account does not exist, click the “Add” button to add it, then grant it “Read” permissions. When you’re finished hit OK.
- All Set!
That should take care of the problem in most cases. That said, there are many different circumstances that can produce this issue but hopefully this was the answer for you as it was for me.
