jump to navigation

Got "Temporary Post Used For Style Detection"? August 16, 2006

Posted by spikew in WindowsLiveWriter.
comments closed

As the dust is settling from our launch of Windows Live Writer this week, I’m starting to see a lot of these Writer temporary posts falling out of the blogosphere.

Marc Orchant recently posted a funny (but sadly true) comment about Writer being a litter bug, and Anil Dash commented that it provides a fun way to see evidence of users trying out Writer. Rick Segal is more annoyed and less delicately refers to them as “turds”.

If you don’t know what I’m talking about, take a look:

So what exactly is this temporary post?

One of the really cool features about Windows Live Writer is its ability to edit your blog posts in the same styles that are used on your blog.  In general, this provides a much better WYSIWYG authoring experience since you get a more realistic presentation of what your post will actually look like when it is published.  This makes dealing with the laying out of text and images much easier.

As part of the process of configuring Writer to connect to your blog, Writer creates this temporary post so that it can detect the style-related HTML and CSS associated with your blog posts.  After the style detection is completed, Writer attempts to delete the temporary blog post.  If the blog server responds with a success message, then Writer assumes the post was deleted, and continues with setting up the blog.  If Writer receives a failure message from the blog server, then Writer assumes that the deletion operation was unsuccessful and pops up a warning dialog to let the user know that the temporary post is still on the blog and needs to be manually deleted.

So what’s going wrong?

When designing this style-detection feature, we expected there would be some cases where the deletion of the temporary post would fail and wanted to make sure users were clearly warned about the fact that the temporary post was still on their blog.  We also figured there would be some isolated cases where a blog server would respond with a message acknowledging the post had been successfully deleted, but then fail to actually perform the deletion correctly. Unfortunately, the rate of failure for this latter case is higher than we expected to encounter based on testing we did before Writer was released.

We have identified a few ideas about what is causing the problem:

The delayed file-generation effect

Any user who has used Blogger or MovableType is very familiar with the process of regenerating their site when a new post is added.  This is necessary because these blog servers actually update/generate a set of static files for each page of the blog.  Whenever a change is made to the blog (adding/modifying/deleting an entry, changing the blog’s theme, etc), the blog server needs to execute an update of the files that are affected by this change.  In working with customers on this temporary post issue, we have encountered numerous cases where the temporary post was successfully deleted from the blog server’s internal list of entries, but the cached set of static files had not been regenerated.  In those cases, the temporary post will stay on the site until another operation occurs that forces the server to regenerate the site (like publishing a new entry).

This particular manifestation of the problem has been very confusing for users because they see the temporary post on their blog’s main page, but when they go to delete the entry using their blog admin interface (or using the Writer open post dialog), they don’t see the temporary post listed.  To resolve this issue, you just need to login to your blog admin, and regenerate your site.  Since the temporary post is no longer in the list of posts known to the server, it will not be included in the regenerated site.

The ping effect

Ping servers provide a nice mechanism for telling search engines (and other interested services) that a blog has been updated.  When a blog is updated, some blog servers have support for automatically sending a ping notification to these ping servers so they can examine the updated blog content.  Search engines like Technorati will use the ping broadcast as a hint that they should update their search indexes to include the new content that has been posted to your blog.  If your blog is hosted on blog server that has any kind of delay between the temporary post being deleted from the main site (like the “delayed file generation effect” described above), the ping effect will increase the changes that your temporary post will get indexed by a search engine. 

The FeedBurner effect

FeedBurner is a very cool service that will act as a proxy for your blog’s RSS feed so that it can gather and report statistics about the usage patterns of your feed.  I don’t have exact insights into the way FeedBurner works, but in trying to simulate some of the temporary post scenarios, it seems like FeedBurner will cache your RSS feed until it detects that a new entry has appeared in your feed.  In my ad-hoc experimentation, I found that if a request was made for my FeedBurner feed while Writer was processing my blog styles (meaning the temporary post was still present), FeedBurner actually managed to detect and cache the RSS entry about my temporary post in its RSS feed.  Unfortunately, after the temporary post was then deleted, the FeedBurner RSS feed still contained the entry for the temporary post.  The bummer here is that this creates a window of time where the temporary post can then appear in the RSS feed even though it no longer exists on the weblog.  Again, my ad-hoc experimentation seemed to indicate that this temporary post would remain in my feed until the next new post was made to my blog.  FeedBurner is just one example of a service taking advantage of a blog’s RSS feed that might cache feed data and inadvertently propagate these temporary posts after they have been deleted. This caching behavior is generally not a problem for normal blog usage, however it creates an unfortunate amplification effect for these temporary posts the Writer is using for style detection.

So what’s the plan going forward?

We have been following up with users who have expressed concerns about these temporary posts, but unfortunately, we don’t have a better approach up our sleeves for automatic style detection at this time. 

For the next beta, we plan to continue improving the robustness of our detection of orphaned temporary posts so that we can more accurately notify users if the posts are still visible on their blogs after a successful deletion. We are also planning to include a prompt in the blog setup wizard before performing the style detection to allow users to opt-out of style detection (and therefore avoid the temporary post). Finally, we will continue digging into the most common environments where this problem is occurring to see what we can do reduce the occurrence.

Given the wide range of hosted and custom-installed blogging engines in use these days, it’s unrealistic to expect that this will ever be completely resolved as long as it is necessary for Writer to make a temporary post in order to accurately detect the styles of a blog.  It would be great if, over time, we could help with new initiatives for evolving the discovery and publishing hooks exposed in blogging engines for tools like Writer and BlogJet to use to improve end-user authoring experiences and reduce these types of unfortunate annoyances.

That concludes this detailed lesson in the mysterious temporary posts. Anyone with further insights, suggestions, or questions, please feel free to let me know here or on the Writer blog.

 Other blogs commenting on Writer temporary posts