Utah Web Design Blog » PHP

How to fix UTF-8 charset problem with IIS 7.5 and PHP FastCGI

Matthew Moeller — Mon, 18 Oct 2010 16:12:52 +0000

The performance gains from using the FastCGI version of PHP 5 are obvious and the preferred method. If you build apps that require encoding the page in UTF-8 character set you may have noticed that IIS7.5 overrides your settings. You may have tried explicitly stating it in your php/IIS config or even on the page with "" to no avail. The problem resides in the implementation of the fastcgi module.

By default FastCGI uses ASCII encoding for server variables and there was no way to modify this behavior with the initial release. While just a mild annoyance with a content manager this quickly turns into a problem if you are using server variables that your web application requires to function when IIS7.5 forces the charset on you. Up until last week there was no resolution for IIS7.5, Microsoft finally posted a hotfix that resolves this issue here. We have tested this and it does resolve the issue.

IIS 7.5 FastCGI charset fix: http://support.microsoft.com/kb/2277918/
IIS 7.0 FastCGI charset fix: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c17a72bd-7009-4830-85e0-06290f3b8367

Ok, I installed the patch, now what? Instructions on how to deploy the charset fix?

Using Includes and Active Pages

Merrick — Sun, 02 Mar 2008 02:44:16 +0000

Alright there is no debate includes are the best way to code a nav right? Well, what if someone wants to indicate to the use what page they're on? Or as I will call it the active page. Just include a script to the top of each page comparing strings with the window location, and if its true; make it look like the active page. I'm horrible with words but hopefully this is making sense. Now I'll let the code speak:�
var contact = RegExp("contact"); if(contact.test(window.location) == true) { $('home').addClass('active'); }

Nothing to complex- Just comparing our variable string of contact and comparing it with the window location. If there is a match then you attach an ".active" class to it. I know its nothing big; but a simple trick helps every now and again.

WordPress 2.x Spell checker Error “could not execute AJAXcall, server didn’t return valid a xml” How to fix

Matthew Moeller — Mon, 06 Aug 2007 05:09:57 +0000

I was having a hell of a time getting the spellchecker in WordPress 2.2.2 to work properly and could not find a solution online anywhere so I decided to post what worked for me. Two hours of searching online resulted in nothing so when all else fails you are left to your own devices. To preface this post I am using IIS6 and PHP5. Everytime you click the spell check icon you get the error "could not execute AJAXcall, server didn't return valid a xml" .

How to fix this error on a win32 box:

Crack open your php.ini file and uncomment extension = php_pspell.dll, and make sure it actually exists in your ext/ dir.
Download the aspell installer from aspell.net (win32 version) and the dictionary installer (en)
Now the funny thing is the win32 installer files appear to have inccorrect linefeeds so when you run the spell checker after install it still blows up but with a new error like "iso8859-1 is not in the proper format". I downloaded the source files via ftp and manually replaced them in the aspell directory. FTP link , (version aspell-w32-0.50.3)
If your php path is in system32/ you need to copy the .dll files there from the aspell/bin/ dir.
Finally you need to actually configure your spellchecker within WordPress 2.2.x, open the file "wordpress\wp-includes\js\tinymce\plugins\spellchecker\config.php" and comment out the Google spell checker that appears not to work at all, and those who have it working have a sweet delayed response time. Next uncomment this line: "require_once("classes/TinyPspell.class.php"); // Internal PHP version"
Don't forget to turn on the spell check in the first place in config.php "$spellCheckerConfig['enabled'] = true;"
Restart IIS
Enjoy tested and it is now working in IE7 and Firefox 2.X

Between the incorrect format of the aspell install files and the weak online support for this Ajax error, it was a solution found through trial and error. Not bagging WordPress, free is free, and it is a killer app which is worth the debug time. Hope this helps other frustrated hosting providers, not that it isn't a good use of 3hours on a sunday. For more web site design and hosting tips visit Red Olive Creative.