Hi,

After having searched for an answer to this, I can't seem to find one, so I'll post.

I'm on mojoPortal 2.3.5.4 MSSQL.

I'm working on integrating our blogs and the feed manager with Google Feedburner.

According to Google's documentation, as well as other articles I've read on the web, the proper way to set up feedburner is to inform it of your feed(s) and then put a redirect in place on your rss address(es) so that when a client requests your feed, they are still using your url (thus maintaining your control over the client's subscription) but they are then soft redirected (302) to the feedburner url (providing you traffic offloading and analytics).

The Google document describing this setup is here.  In it, they provide an example of an Apache redirect using mod_rewrite and the [R] option, which the Apache docs describe as a 302 redirect.

When I use the Feedburner functionality in mojoPortal, however, that's not what it does.  It instead changes the RSS feed link to point directly at Feedburner's url.  This means that my users are no longer directly subscribed to my feed and I am stuck with Feedburner unless I want to lose those subscriptions should I want to migrate off of Feedburner.

Am I missing something?  How hard would it be for me to modify the setup to provide the original RSS link and a 302 redirect to FB instead?

Thanks Jamie.

I should also note that the Google documentation includes an exception for the feedburner client itself in the mod_rewrite rule, so that feedburner is not redirected when it tries to fetch your content!

I don't see a facility in mojoPortal to do 302 redirects (if there were, there wouldn't even need to be any special feedburner support in the blog module necessarily), and especially not with such an exception capability.

I would try to do the redirect with IIS 6 itself if the blog and feed manager links were physical files that could have their properties set, but alas since this is dynamic ASP.NET magic, I don't see how I could do that either.

So I guess I'll forgo feedburner support until we can figure this out.  That way at least our users will have the right url and will automatically start using the feedburner service once the redirects are in place.

Hi Joe,

Let me first genuflect a bit, since I'm going to be in some cases disagreeing with you here and I want to do so respectfully. Bear in mind, I'm new to all of this and so I'm simply trying to follow directions as opposed to trying to know it all. I just want to follow the roadmap.

I'm trying to do what is dictated by the Wise Ones(TM), who in the case of Feedburner are their docs and in the case of mojoPortal is you.

Unfortunately, I'm receiving conflicting directions here. I'm hesitant to disagree with either of you naturally, but given that FB are the experts on FB, I'm slightly more hesitant to disagree with them on this topic than with you, so forgive me for questioning your reasoning here. As a sidebar I must say that you seem pretty dismissive of their guidance, which I find surprising.

Once again, you have more experience in this than I do. At the same time, I'm not burdened by any preconceived notions, so I set out to investigate the situation given your additional guidance.

To see this in it's full process, I subscribed to new feedburner account and added a feed. It took me through the standard set of options and encouraged me to promote my new feedburner-located url. One vote for the FB url.

However, the last step tells me that I now need to have my site integrate with FB as well. As an example, I chose the Blogger directions. I happen to have a Blogger site which had not been using FB, so I set it up according to the directions.

You go into the blog settings and tell it to redirect the blog feed to FB. So far so good.

Right after that, FB has this to say:

> Blogger will now redirect all feed traffic for your blog to your FeedBurner feed.
>
> Note: If you are using the redirection feature within Blogger to send all of your feed traffic to your FeedBurner feed, you may want to modify the code we provide in order to keep your subscribers with you, even if you leave FeedBurner.

Hmm. So they definitely have something to say about the matter. Following the link, you see the following explanation:

> If I redirect my Blogger feed to FeedBurner, should I change my blog's feed chicklet links, too? Share Comment Print
If you are a Blogger publisher and you've decided to use its new redirection feature to tightly connect your Blogger blog and your FeedBurner feed, you may want to change the link to the FeedBurner feed you provide on your site when using features like Chicklet Chooser and FeedCount. Why? Portability. Let us explain:
>
> Once you redirect 100% of your feed traffic to your FeedBurner feed, you get a very complete picture of your feed-consuming audience, including where it's coming from and what content it's finding most popular in your feed. That's great. But if this audience is almost entirely subscribing to feeds.feedburner.com/myexcellentcontent, they will be stranded if, for some reason, you should choose to leave FeedBurner and revert back to your original feed address or some other service.

It goes on to say that your "Add to Google" and other reader-related "chicklets" should use the original feed url, not the feedburner one. This is very clear direction in my book. Not only this, by implication they are saying that this model works, contrary to your assertion, Joe. This is where there bears some further exposition.

Going back to the blog, the feed link still shows as the blogger address, not FB. When you click the link, it takes you to the FB url via a 302 redirect, which I verified through InternetOfficer's Redirect Checker.

At that point, there are two relevant observations. The first is that the address bar indeed shows the new feedburner address. So here is an example where you are correct Joe, if someone clicks the link directly and *then* copies the address into their reader subscription, they will have defeated the intention of keeping them subscribed to the original url.

The second observation, which I will just note here and revisit later, is that this landing page allows the owner to present a custom message to the user at this point.

So, what's going on here? Your assertion that it's possible for the user to circumvent this model is correct.

However, from having gone through the process, I would have to disagree with your assessment that this is what would happen to the vast majority of users, based on the subscription opportunities provided to the user:

1. Direct click on the feed link: This is the only way to circumvent, and requires the user to click the link. It is arguable as to what proportion of users would do this. More in a moment.

2. Right-click and copy address from the feed link: Any browser-savvy user figures this trick out pretty quickly, saving them a page-load and a copy. This does not circumvent, instead relying on the redirect.

3. Browser feed detection: All the major browsers (with the exception of Chrome, which requires an extension) support a "light up" feed indicator that detects the page feed. This is arguably the most user-friendly subscription option due to the fact that it doesn't rely on the user to even *read* the page. I always use this option, personally.

4. Reader-related chicklets: These are also a strong option since they simplify the subscription process for, by way of example, Google Reader. If my RSS detector didn't automatically add to Google Reader I might rely on these chicklets as my go-to subscription method. As the FB documentation indicates, they recommend explicitly changing from the FB url to your original one on these chicklets. This doesn't get circumvented.

Those are all of the methods I can divine. Of them, only one circumvents subscription to the original url.

While there will probably be an appreciable number of people who use it due to the fact that it is the most naive method, I would argue that it is by no means the most popular method when there are so many other options that offer concrete advantages to the user. Add to this the fact that my particular audience tends to be the savvy of the savvy (professional IT admins). Finally, for those users that *do* happen to use the "click the feed link" method, FB provides me the opportunity to inform them via the custom message that this is not the correct url and to go back and right-click for the proper address.  I intend to use this.

So I see a very real use for the redirect, as directed by FB.

As for the other assertion that using such a model would prevent FB from tracking the users, they directly contradict this in that answer which is linked above.  You still get all of the stats, which makes sense because the users are still retrieving all of the content from them, giving them all of the visibility they need.

You also raised a point about there being a performance penalty for redirecting versus sending directly to FB. I'm willing to pay the penalty for redirects (I would guess this is tiny) for the benefit of maintaining control of my users. And it's surely a smaller penalty than the re-aggregation model you proposed, which I don't find appealing.  Thanks for trying to provide an alternative though, it's appreciated.

I don't mean to sound like a jerk! Please take this feedback in the spirit of genuine inquisitiveness and constructive feedback that is intended. I love what mojo is doing for us and think it's great.

For anyone interested in making this work, I can say that it does work with the proper configuration.  It can be done without mojoPortal support, although a few tweaks to the blog module would make it easier.

I've posted directions on my blog here.

Happy mojoing.