This project is read-only.

Override theme that Windows Live Writer uses

Topics: Themes
Mar 6, 2010 at 3:23 AM

Hi all

I've just put on my black turtleneck and spun up a theme for our internal blog here. I'm chuffed with the results, it renders in modern browsers and everybody wins. Except Windows Live Writer. Because of some of the fancy stuff I've done with the headings, editing a post in WLW after refreshing the theme is... ugly.

Is there a way to trick/override/lie to WLW when it's retrieving it's theme?

We're serving from IIS7, so I poked through the logs to find out what WLW sends when it's refreshing the theme. It looks like it sends a nice user agent, so I put in an url rewrite in IIS to redirect requests to ^$ (an empty request) when the {HTTP_USER_AGENT} matches "Windows[\+|\s]Live[\+|\s]Writer" (my regexp fu is low!) to redirect to "?theme=Standard". This has tricked it into not downloading my theme, but the theme it's getting is almost like it's an unstyled page. I'd rather it get the standard theme.


Mar 6, 2010 at 8:14 AM

I'm not an expert on WLW, but I think the CSS styles that WLW finds in the theme and applies to the WLW editing window doesn't always match up to how things look in a browser.  I think this is proven by how WLW interpreted your custom theme -- it showed it as much uglier than what it really looks like.

While testing WLW in the past (not testing for themes in particular), when the Standard theme is the selected theme, I believe what you see in WLW is a very plain theme.  So you're hack is probably working.  As a test, you could try switching the theme on the internal blog to the Standard theme (just for a couple of minutes), and then add your blog again as a new account within WLW.  If you see the same thing, then you'll know that that's how WLW interprets the Standard theme.

There's probably some tips out there on what types of CSS styles and/or how to best create markup for a page so WLW can best interpret it.  Probably it's difficult for WLW, because it needs to look at your entire site markup, and also the CSS file for your entire site, and then it needs to try and extract the correct markup, or CSS styles that are used just for an individual post.  My guess is that the difficult part of this is for it to correctly detect the cascading styles.  For example, it can find the CSS styles being applied to a DIV containing the post.  But within that DIV, there are paragraphs and anchors, etc. where the CSS styling for these elements is often defined at a more global level.  And then you've got styles that override styles, etc.  Trying to calculate what the net result is for exactly what styles ultimately get applied to the elements within a post is where WLW is probably failing.

But, between the ugliness you saw before, and the plainness you're seeing now, I would imagine the plainness is the lesser of two evils.