Configuring mojoPortal to work with Feedburner's URL redirection feature
Note: as of version 2.3.6.1 of mojoPortal this configuration is no longer required as there is a better, supported mojoPortal configuration for it. See the mojoPortal release notes for the details. It even solves the auto-detection issue with IE and Firefox! Thanks Joe!
This article is about configuring the excellent open-source ASP.NET content management system, mojoPortal, for use with Feedburner. More specifically, it deals with how to get mojoPortal to agree with Feedburner's url redirection option.Why would anyone be interested in doing this? Well, Feedburner is a great service for gathering statistics on your RSS subscribers and how they read your feed. Feedburner actually caches your feed contents, and users get the content from Feedburner, while your site is still the original source of the content.In our case, there is an added benefit that by directing your users to read from Feedburner, their polling doesn't actually put load on your server, but Feedburner instead takes the load. For a bandwidth constrained site, this can be great.However, the downside is that, unless you use a specific Feedburner feature, your users end up subscribing to their url. This means your audience is captive to Feedburner. Should you decide to stop using Feedburner for whatever reason (a better, free competitor, for example), you are stuck with the unappealing options of shepherding your readers to the new service manually, maintaining the old and new service simultaneously or abandoning your readers entirely. Perhaps they have a 301 redirect option which will work at that point, but an ounce of prevention, yada yada.Fortunately, Feedburner offers a solution, although one not without it's problems. Still, it's better than the choices above. This is their url redirection feature. Or rather, yours, with some support from them.In fact, this feature is recommended by them and others precisely because it mitigates the reader migration problem.So where does mojoPortal fit in this? Well, the feature takes some support from your site. Many of the major blogs support this feature, and some CMSs do as well. In fact, mojoPortal's blog feature already supports publishing your feed via Feedburner's url in its Feed settings. Note, however that this doesn't support Feedburner's url redirection feature, so it still faces the reader migration issue.Since using the url redirection feature makes good sense to me, I was surprised to learn that mojoPortal's implementation doesn't have it. I searched the mojoPortal forums, and since I didn't find anything on the subject, I posted my issue. While it didn't get much traction at first, there is some interest there so we'll see what happens with it. In any case, after having to figure this out on my own, I can say it is indeed useful and if you'd like to implement it yourself, well, you don't have to wait for mojoPortal support, that's what this post is for. Note that it's not perfect and YMMV.You can probably get away with less than this, especially if you have only one feed, but here's what it took in my case:
While it doesn't sound like a whole lot, the configuration did take me quite some time, so if you're not really needing this, I actually don't recommend taking the time to do it. Support from mojoPortal would have put it within easier reach however, so I'd still like to see that in the future perhaps.If you only have one feed, I would skip the feed list page and instead link the RSS chicklet to your local feed url. Browsers should handle this correctly. When there's more than one, however, offering the user an explanation of the choices makes sense, although I could also see tying it directly to an aggregate feed for the site using the feed manager module.So the basic idea is that the user subscribes to a url on your server, which is polled by their RSS reader application to fetch your content. In the meantime, your site is set up to redirect all traffic from that url to feedburner's burn of that feed.As a quick sidebar, what happens to your users that have already subscribed before you implement this? They're out of luck and you're already stuck with the migration issue. Sorry.The reader app initially hits your site each time it tries to read but is always directed to feedburner in the end. The type of redirect is a 302 (not a 301), which is a temporary redirect. This means that the reader app should continue using the local url and not try to replace its configuration to go straight to feedburner in the future.There are a couple methods for accomplishing this result, shown by the feedburner docs here. The reason there is any complication at all is that when feedburner tries to fetch the original content, you don't want it to be redirected to itself like all the rest of the clients. The easiest way to do this with IIS is to use a separate url from the original blog url to perform the redirect. Fortunately, mojoPortal's feedburner configuration is just the tool to enable us to use this model, as we will see.What does feedburner's url redirection "feature" actually give you, since it's actually your site doing the redirection? While feedburner doesn't explicitly do any of the redirection, it needs to support your url as the canonical one whenever a user lands on your feed's page at feedburner.If a user does end up clicking on your feed url, they'll be redirected to the feed at feedburner. This does two things. First, rather than showing them the raw xml for your feed, it detects that it's being read by a browser and instead shows a nicely formatted html landing page. This is desirable. Second, the browser detects the redirection and changes the address bar url to the feedburner url. This is undesirable, but can't be changed.So, when the user gets to the landing page (a feature feedburner calls "BrowserFriendly"), they see a couple other things along with the feed articles. They see a wide range reader application subscription chicklets, supplied by feedburner. They also see a custom message from you, the feed owner. When you use redirection, it's those subscription chicklets that you're concerned about. By offering the redirection feature, feedburner allows you to tell it your local feed url, which it then puts in those chicklets. That way, it all works correctly should the user use one of those buttons.We can also make use of that customized message, even though it's not necessarily part of url redirection feature. When the user lands on the feedburner page, they may instinctively go to copy the url from the address bar to paste in their reader. While we can't stop this, we at least have the chance to put up a message that says, "Hey, don't do that...copy this url instead."So what does the user go through to subscribe? Unfortunately, the answer depends on which of the myriad RSS subscription options they prefer. And there's the rub, since a some of them end up subscribing the user to the feedburner url, which is what this is all trying to avoid. Luckily, this can almost but all be avoided, with the minor inconvenience that we need to avoid the browser's "feed auto-detection" wherever possible.If the user prefers browser feed detection, Firefox and IE screw it up. Rather than land them on feedburner's landing page, they go straight to the feedburner url and offer to subscribe the user to that. Boo. We can't fix the browsers, so we want to avoid the auto-detection feature. Unfortunately, mojoPortal triggers auto-detection automatically and doesn't have a option to disable that. Feature request. It can be done, it just requires a new option.It should be noted that at least some of Chrome's auto-detectors work properly (there are several auto-detect extensions, and mine works) and that Firefox 4 does away with auto-detect entirely from the conventional UI, so things are moving in the right direction. Perhaps IE 9 will come into line in some fashion as well.If the user uses one of the mojoPortal blog's "add to reader x" buttons, everything works. As well, if they go to the feedburner url directly (and this does work in all browsers, it's just auto-detect that's borked), then they receive the landing page which informs them to copy and paste the correct url, or to use one of the subscription buttons for their reader (also correct).wFinally, if the user right-clicks the blog's feed link and copies that into their reader, it works. Only the
Now choose a "front-door" url for your feed. I've adopted "pagename-rss.aspx" where "pagename" is the name of the page which the blog module inhabits. Since it will be in the root of your mojoPortal install, the url will be "http://www.yoursitename.com/pagename-rss.aspx". We'll configure IIS with this page after Feedburner.
These directions are for IIS 6. To use IIS 7, you'll need to google the directions for setting up redirects as well as make sure you are configuring 302 redirects. IIS 6 uses 302s by default.
If you choose to list your feeds, I suggest changing the title attribute of the image to say something like "Click to view the feeds offered on this site", rather than my layout's default "Click to subscribe". This may give the user a heads-up to not attempt to subscribe directly to that link.
I made a page with the intro:
I followed this with a table with the columns: page, feed url, description and subscribe. "Page" with page title and linked to the site page, "Feed url" with just the text of the link but not a live link (so they can only copy the correct url), and "Subscribe" with my own html version of the application subscription chicklets. The subscription urls I copied from the feedburner landing page (I used these instead of mojoPortal's since they were different). I would have linked to the same images as well but they didn't always show so I copied them from the web and saved locally. I used "myAOL", "Windows Live", "My Yahoo!", "Google" and "newsgator".That's it. Test by visiting the pages and using the various subscription methods. With the noted exceptions (auto-detection, various reader accounts I couldn't test), they all worked for me.
While I'm not holding my breath, the following features would be nice for supporting this setup:
This article is about configuring the excellent open-source ASP.NET content management system, mojoPortal, for use with Feedburner. More specifically, it deals with how to get mojoPortal to agree with Feedburner's url redirection option.Why would anyone be interested in doing this? Well, Feedburner is a great service for gathering statistics on your RSS subscribers and how they read your feed. Feedburner actually caches your feed contents, and users get the content from Feedburner, while your site is still the original source of the content.In our case, there is an added benefit that by directing your users to read from Feedburner, their polling doesn't actually put load on your server, but Feedburner instead takes the load. For a bandwidth constrained site, this can be great.However, the downside is that, unless you use a specific Feedburner feature, your users end up subscribing to their url. This means your audience is captive to Feedburner. Should you decide to stop using Feedburner for whatever reason (a better, free competitor, for example), you are stuck with the unappealing options of shepherding your readers to the new service manually, maintaining the old and new service simultaneously or abandoning your readers entirely. Perhaps they have a 301 redirect option which will work at that point, but an ounce of prevention, yada yada.Fortunately, Feedburner offers a solution, although one not without it's problems. Still, it's better than the choices above. This is their url redirection feature. Or rather, yours, with some support from them.In fact, this feature is recommended by them and others precisely because it mitigates the reader migration problem.So where does mojoPortal fit in this? Well, the feature takes some support from your site. Many of the major blogs support this feature, and some CMSs do as well. In fact, mojoPortal's blog feature already supports publishing your feed via Feedburner's url in its Feed settings. Note, however that this doesn't support Feedburner's url redirection feature, so it still faces the reader migration issue.Since using the url redirection feature makes good sense to me, I was surprised to learn that mojoPortal's implementation doesn't have it. I searched the mojoPortal forums, and since I didn't find anything on the subject, I posted my issue. While it didn't get much traction at first, there is some interest there so we'll see what happens with it. In any case, after having to figure this out on my own, I can say it is indeed useful and if you'd like to implement it yourself, well, you don't have to wait for mojoPortal support, that's what this post is for. Note that it's not perfect and YMMV.You can probably get away with less than this, especially if you have only one feed, but here's what it took in my case:
- A blog module instance (I also used the feed manager feature)
- A Feedburner account configured to "burn" the blog feed (one burn for each feed, actually)
- Enabling the url redirection feature within Feedburner's BrowserFriendly settings and configuration of a custom message
- A new file in the root of the mojoPortal installation directory (not the site), configured with an IIS 6 redirect (one of these for each feed, actually)
- A page in the site to list the site feeds
- An RSS "chicklet" in the sites
layout.masterfile pointing to the feed list page
While it doesn't sound like a whole lot, the configuration did take me quite some time, so if you're not really needing this, I actually don't recommend taking the time to do it. Support from mojoPortal would have put it within easier reach however, so I'd still like to see that in the future perhaps.If you only have one feed, I would skip the feed list page and instead link the RSS chicklet to your local feed url. Browsers should handle this correctly. When there's more than one, however, offering the user an explanation of the choices makes sense, although I could also see tying it directly to an aggregate feed for the site using the feed manager module.So the basic idea is that the user subscribes to a url on your server, which is polled by their RSS reader application to fetch your content. In the meantime, your site is set up to redirect all traffic from that url to feedburner's burn of that feed.As a quick sidebar, what happens to your users that have already subscribed before you implement this? They're out of luck and you're already stuck with the migration issue. Sorry.The reader app initially hits your site each time it tries to read but is always directed to feedburner in the end. The type of redirect is a 302 (not a 301), which is a temporary redirect. This means that the reader app should continue using the local url and not try to replace its configuration to go straight to feedburner in the future.There are a couple methods for accomplishing this result, shown by the feedburner docs here. The reason there is any complication at all is that when feedburner tries to fetch the original content, you don't want it to be redirected to itself like all the rest of the clients. The easiest way to do this with IIS is to use a separate url from the original blog url to perform the redirect. Fortunately, mojoPortal's feedburner configuration is just the tool to enable us to use this model, as we will see.What does feedburner's url redirection "feature" actually give you, since it's actually your site doing the redirection? While feedburner doesn't explicitly do any of the redirection, it needs to support your url as the canonical one whenever a user lands on your feed's page at feedburner.If a user does end up clicking on your feed url, they'll be redirected to the feed at feedburner. This does two things. First, rather than showing them the raw xml for your feed, it detects that it's being read by a browser and instead shows a nicely formatted html landing page. This is desirable. Second, the browser detects the redirection and changes the address bar url to the feedburner url. This is undesirable, but can't be changed.So, when the user gets to the landing page (a feature feedburner calls "BrowserFriendly"), they see a couple other things along with the feed articles. They see a wide range reader application subscription chicklets, supplied by feedburner. They also see a custom message from you, the feed owner. When you use redirection, it's those subscription chicklets that you're concerned about. By offering the redirection feature, feedburner allows you to tell it your local feed url, which it then puts in those chicklets. That way, it all works correctly should the user use one of those buttons.We can also make use of that customized message, even though it's not necessarily part of url redirection feature. When the user lands on the feedburner page, they may instinctively go to copy the url from the address bar to paste in their reader. While we can't stop this, we at least have the chance to put up a message that says, "Hey, don't do that...copy this url instead."So what does the user go through to subscribe? Unfortunately, the answer depends on which of the myriad RSS subscription options they prefer. And there's the rub, since a some of them end up subscribing the user to the feedburner url, which is what this is all trying to avoid. Luckily, this can almost but all be avoided, with the minor inconvenience that we need to avoid the browser's "feed auto-detection" wherever possible.If the user prefers browser feed detection, Firefox and IE screw it up. Rather than land them on feedburner's landing page, they go straight to the feedburner url and offer to subscribe the user to that. Boo. We can't fix the browsers, so we want to avoid the auto-detection feature. Unfortunately, mojoPortal triggers auto-detection automatically and doesn't have a option to disable that. Feature request. It can be done, it just requires a new option.It should be noted that at least some of Chrome's auto-detectors work properly (there are several auto-detect extensions, and mine works) and that Firefox 4 does away with auto-detect entirely from the conventional UI, so things are moving in the right direction. Perhaps IE 9 will come into line in some fashion as well.If the user uses one of the mojoPortal blog's "add to reader x" buttons, everything works. As well, if they go to the feedburner url directly (and this does work in all browsers, it's just auto-detect that's borked), then they receive the landing page which informs them to copy and paste the correct url, or to use one of the subscription buttons for their reader (also correct).wFinally, if the user right-clicks the blog's feed link and copies that into their reader, it works. Only the
layout.master RSS chicklet link won't work, and that's just because I have it configured to point to a page which lists the feeds. If you configure this to be the feed url instead, it will also work.So the only other way for the user to subscribe to the wrong url, other than the broken auto-detect feature (which is significant), is if after they click on the feed link, they skim over the message dictating the correct url and instead copy it from the address bar. While I can't say this won't happen, we've given the user more attractive options for subscribing as well as telling them what not to do.Here are the detailed implementation steps:Blog
- Create a blog instance. I recommend enabling the "Add feed links" option, even though I'm not quite sure all of them work since I don't have accounts on all of them.
- View it
- Right-click the RSS feed chicklet and copy the link address. This is your "back-door" url that only feedburner will use.
q
We'll come back to the blog settings later, save for now.
Now choose a "front-door" url for your feed. I've adopted "pagename-rss.aspx" where "pagename" is the name of the page which the blog module inhabits. Since it will be in the root of your mojoPortal install, the url will be "http://www.yoursitename.com/pagename-rss.aspx". We'll configure IIS with this page after Feedburner.
Feedburner
- Create an account if you don't have one
- Paste in the back-door url for the blog and "burn it now". I used the default settings, but go back later and check out the options.
- When you get your feed url, copy it
- Open your feed settings and go to "Optimize"
- Click "BrowserFriendly" on the left
- Enable personal message and put in something like this along with your front-door url:
- Click the "Use your redirected feed URL on your BrowserFriendly landing page" dropdown and put in your front-door url.
- Click "Save"
To subscribe to this feed, do not use the feedburner url in the address bar above. Instead use one of the buttons to the right or copy this url into your feed reader. This will make sure you continue to receive our feed should we stop using the feedburner service: http://www.yoursitename.com/pagename-rss.aspx
IIS
These directions are for IIS 6. To use IIS 7, you'll need to google the directions for setting up redirects as well as make sure you are configuring 302 redirects. IIS 6 uses 302s by default.
- Using Windows Explorer, visit the mojoPortal installation root directory and create the file "pagename-rss.aspx"
- Open IIS manager, find the newly created file and right-click, selecting "Properties"
- Select "redirect to a url" and paste the feedburner url
- Click "Apply" and close
Blog (again)
- Go into your blog settings, to feed settings
- Under "Feedburner URL" enter your front-door url not the feedburner url
- Update
Layout.master (optional)
- If you don't have one, add an RSS chicklet to your layout and tie the url to either your front-door url or, if you want to offer users a choice of the feeds on your site, the url of a page on which you list your feeds
If you choose to list your feeds, I suggest changing the title attribute of the image to say something like "Click to view the feeds offered on this site", rather than my layout's default "Click to subscribe". This may give the user a heads-up to not attempt to subscribe directly to that link.
Feeds page (optional)
I made a page with the intro:
The following feeds are available from this site. Choose your desired feed and copy and paste the feed URL into your reader, or use one of the application-specific subscription buttons. (Note: the links on the left take you to the associated web page, not the RSS version)
I followed this with a table with the columns: page, feed url, description and subscribe. "Page" with page title and linked to the site page, "Feed url" with just the text of the link but not a live link (so they can only copy the correct url), and "Subscribe" with my own html version of the application subscription chicklets. The subscription urls I copied from the feedburner landing page (I used these instead of mojoPortal's since they were different). I would have linked to the same images as well but they didn't always show so I copied them from the web and saved locally. I used "myAOL", "Windows Live", "My Yahoo!", "Google" and "newsgator".That's it. Test by visiting the pages and using the various subscription methods. With the noted exceptions (auto-detection, various reader accounts I couldn't test), they all worked for me.
mojoPortal Support Wishlist
While I'm not holding my breath, the following features would be nice for supporting this setup:
- Option to disable rss auto-detection for blogs (feed manager? forums?)
- Option to enable 302 redirects in feed settings from a front-door url to a back-door url without the need to use IIS and make a file
- A module to create a list of site feeds automatically (just a nice to have). Perhaps feed manager can already be configured to work somewhat like the page I made, but application chicklets per-feed are useful.