Scribz.net™ Blog

… or Windows Live Writer 2011 & WordPress

I was frustrated.  I was completely disappointed and ready to give up trying to set up Windows Live Writer to work with my  freshly established Scribz.net™ WordPress Blog.  I kept receiving the following error from my newly installed Windows Live Writer upon sign-up to my WordPress:

The response to blogger.getUsersBlogs method received from the blog server was invalid, something-something XmlRpc something-fail-something…

And the following error appeared in the Windows Live Writer log:

Invalid response document returned from XmlRpc server —> System.Xml.XmlException: Unexpected end of file while parsing Name has occurred.

My native WordPress online user interface worked just fine.  It seemed that there was a problem just with Windows Live Writer 2011 and its connection to the XmlRpc interface.  I spent countless hours trying to figure out what was wrong almost until the point of no return.  Just as I was going to give up on the issue, however, the sleepless night paid off and I managed to find the unlikely culprit.  Now that I wiped the floor with it, I am writing this post from Windows Live Writer.

The Cause

So I set up a fresh new subdomain on a Microsoft IIS 7.0 server at my hosting company.  I downloaded the latest version of WordPress, unzipped it and copied it verbatim to my FTP server.  I was excited because this was going to be my first real attempt at blogging.

I managed to get myself a MySQL database and hook it up with the WordPress application.  This was relatively easy, mostly thanks to this handy guide on installing WordPress.  The most important step here is setting up your wp_config.php with your database access information.  So I made a backup copy of my wp_config.php and edited the file with Windows Notepad.  I didn’t realize this at the time, but this was a grave mistake.  I have a handy habit of saving everything I ever edit in Notepad with the UTF-8 encoding.  This is really useful, especially if you live outside of North America and often use non-English characters…

What I should have realized is that Notepad marks every file it saves in Unicode (including UTF-8 and UTF-16) with a Byte Order Mark (BOM).  This is a sort of a flag or a hint at the very beginning of the file which tells Notepad and other text editors that they should look our for Unicode characters.

A PHP newbie as I was, I did not realize that this was going to be an issue.  It turns out that PHP files are very strict about their structure and that they must absolutely always start with the PHP header "<?php" and end with the "?>" tag.  No whitespace or any other byte, for that matter, is allowed before this specification (or after the closing tag).  Whereas to those of us who develop in other programming languages this may seem a little overboard, we must nonetheless accept and obey this rule in PHP.  And sure enough, my BOM was preventing the WordPress XmlRpc interface scripts from performing adequately.

Please skip to the Solution if you just want to get done with this.

The Search

Whenever I launched my (freshly installed) Windows Live Writer 2011 (build 15.4.3508.1109) and attempted to connect it with my WordPress 3.0.3 application through XmlRpc, I got an error as stated at the very beginning of this post.

I tried to search the Internet for the solution to this problem.  I will now list the steps I tried in case you haven’t known about either of them (who knows, might still be helpful):

1. I made sure my XmlRpc was enabled in the blog settings.  You do this by logging into an administrator account, going to Settings and clicking Writing.  On this settings page, there should be a section on Remote Publishing, which is quite literally what we want to do.  You normally have several options (two?) and one of those is "XML-RPC Enable the WordPress, Movable Type, MetaWeblog and Blogger XML-RPC publishing protocols."  Make sure you have this selected (and saved) before you try to make a connection.
2. Through setting this option on and off and occasionally deleting the xmlrpc.php (should be all lowercase!) from the application’s root folder, I was able to figure out that Windows Live Writer was indeed able to see this file and access it.  However, there was still an error somewhere.
3. Older troubleshooting advice on WordPress states that "a bug in PHP 5.2.2 causes POST data to be dropped".  They suggest that a line be added to the xmlrpc.php file.  Although I really didn’t know much about PHP, I figured that my version of xmlrpc.php already had this line added, complete with a nice comment.
4. Then there was .htaccess advice suggesting adding some tweaks to the header files, etc.  I am sorry I don’t remember where this was, but it was applicable to Apache servers only.  Since I am running on Microsoft-powered machines and I don’t really have any access to them, I had no choice but to skip this advice anyway.
5. I tried editing and tweaking every file I could think of – to no avail.  I tried to check whether all the includes are present in the correct folders, tried logging in as different users – nothing helped.
6. I tried to figure out what was going on in the Windows Live Writer log, which is located here: %USERPROFILE%\Local Settings\Application Data\Windows Live Writer\
7. When nothing of the above helped me in any way and I was just about to give up completely, I stumbled upon this wonderful post on Solving the connection problems of Windows Live Writer (WLW) by Sylvain Lafontaine.

The Solution

The reason for the issue I was getting was, again, a Byte Order Mark at the beginning of my wp_config.php.  For some reason, the PHP compiler on my server had no issues with this setup when running the blog, despite the fact that everything important is stored in wp_config.php.  However, the compiler apparently kept sending malformed XML to Windows Live Writer whenever the Writer contacted XmlRpc.

As I mentioned before, the BOM was prepended to my wp_config.php by Notepad, which I  had used to edit the blog-wide variables.  The solution was simple – to remove the Byte Order Mark from the beginning of my wp_config.php (which at this point was the only affected file).

In order to remove the BOM, Lafontaine suggests using the freeware utility XVI32, a free hexadecimal editor.  The editor doesn’t install, you can just run the EXE file right from the ZIP.  The process is simple – just drag your "affected" PHP file (in my case wp_config.php) into XVI32 and it will open in a neat byte-grid.  Then, you should see that the very first three bytes in the file are "" followed by "<?php".  If this is indeed the case, you should select each character in turn and just delete it (press the Del key).  When you then save (Ctrl+S) the file, it will be completely the same as it used to be, only without the leading BOM.

After I had done that, I copied my "clean" wp_config.php to the server and everything worked like magic.  Well, magic with a lot of low-level human help anyway.  Nevertheless, my Windows Live Writer suddenly recognized the service and – five early-morning hours later – I could start blogging away on my brand new blog.

So much for my first-ever encounter with PHP, huh?  Please let me know in the comments if you have any suggestions or additional information which I could include so that everyone can benefit and save their hair from going gray!

Credit

Again, for the solution I must give the credit to this very detailed and knowledgeable blog: Solving the connection problems of Windows Live Writer (WLW).  The post is fun to read even if you never plan on using Windows Live Writer; it contains thorough explanations of some smart techniques which may well come in handy one day.

Thank you-thank you-thank you, Sylvain Lafontaine, and may all your code just work!

Cheers.