Feedburner not redirecting to correct urls

by . Originally posted

As I continue to build this site, the latest component I’ve been working on is for people to be able to use their RSS/XML burner to follow any new posts I decide are worthy to publish to the world. So quickly knocking up an RSS feed that tracks the 20 latest posts, I decide to merge the feed with Google’s Feedburner service, a publishing platform and a hub of tools that monitor your feeds and links within them.

Anyway this post is to explain a problem I had with Feedburner and more importantly how I overcame it, especially as I couldnt find any useful material on Google itself regarding the problem.

After telling Feedburner my XML URL and proceeding through all the (very short) configuration stages, my problem was that I tested the output feed and all my URLs it redirected to were incorrect. Below is a sample of my feed to show you the schema of the elements that reflect each article:

<item>
<title>The Walking Dead: Vatos (#1.4)</title>
<description>Yay! Thankfully this episode was better than the last, lots more action and nail biting suspence throughout. As usual, no massive write up, just the important plot points to keep you updated: We find that one of the forest survivors has had a dream of a zombie attack on the forest camp, but the rest of them don't understand and suspect he's suffer...&lt/description>
<link>http://www.PaulJoyceUK.com/blog/the-walking-dead-s1-e4-vatos</link>
<guid>the-walking-dead-s1-e4-vatos</guid>
<pubDate>Wed, 04 May 2011 14:22:00 +0000</pubDate>
</item>

So the URL the Feedburner feed should redirect to in this case should have been http://www.PaulJoyceUK.com/blog/the-walking-dead-s1-e4-vatos but it was actually appearing as http://www.PaulJoyceUK.com/the-walking-dead-s1-e4-vatos without the “/blog/” folder in the middle. To a web browser this is a completely different file, so it wouldn’t work to return the article.

Now to cut a long story short, the problem turns out that Feedburner was trying to visit the property of the GUID element, not the LINK element.

If you reed the RSS spec regarding the GUID it says:

guid stands for globally unique identifier. It's a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new.

However further down the page it says:
If the guid element has an attribute named isPermaLink with a value of true, the reader may assume that it is a permalink to the item, that is, a url that can be opened in a Web browser, that points to the full item described by the element. isPermaLink is optional, its default value is true
Which to me seems to completely change the reason for the element… but hey-ho the spec’ was designed by much smarter chaps, so I’ll just file this one under ‘slightly-misunderstood documentation’.

Now to fix this problem with Feedburner all I need to do was change the GUID element so it read:
<guid isPermaLink=true>the-walking-dead-s1-e4-vatos</guid>

Then ping Feedburner to tell it to refresh the content immediately and voila the links changed to the proper value from within the LINK elements. Perfect!

Hope this saves a few people the hassle of searching for ages and wondering what small mistake they’ve made.

Categories: Computing, Fixes & Solutions

1 Comment

Leave a Reply

Your email address will not be published.

Links and useful footery things…

Copyright © 2018 Paul Joyce. Follow me on Twitter or perhaps Google+