Podcast feature - Please Add Slideshow Embed Code to RSS Feed

The Podcasting feature is great, and there's just one thing holding us back from using it: workflow. As it is, we would have to manually copy/paste the embed codes into new posts on our website. That's really clunky for a rotation of volunteers who have enough to think about, so we really need to automate it.

The RSS feed is the obvious way. Unfortunately, it doesn't include the slideshow iframe embed code, so no luck there.

Fortunately, I know exactly the slight change (on your side) that would make it usable for us:
The RSS feed currently uses the RSS <enclosure> element for the MP3. That's fine, but of limited use.
The feed is NOT using the standard RSS <content> element, which is where the slideshow embed code should go.
--> Please add the regular iframe embed code in the RSS feed's <content> element.

That minor addition (combined with IFTTT.com or Zapier.com) would could easily automate our website and Facebook publishing systems. Thanks!
-Rob Eberhardt

(cross-posted to https://faithlife.com/comments/417475)

Find more posts tagged with

Comments

Scott Alexander

Thanks for the feedback Rob. We're looking into this.

Daniel Ma

https://community.logos.com/discussion/comment/813007#Comment_813007

The embed code should be included in the RSS feed now in the content field. Let us know if you have any troubles with it.

Northminster Production

https://community.logos.com/discussion/comment/813124#Comment_813124

Great to see the quick response!

Unfortunately, something's wrong with how you're encoding text in the new <content> nodes. The old <title> nodes handle it fine.
BTW, you can't see this problem unless you view source on the RSS feed. Here's ours:
view-source:https://soundfaith.com/api/channels/5295885/feed

Here's a good node you've been encoding just fine:
<title><![CDATA[March 27, 2016 - "Unleashed"]]></title>

Here's the new badly-encoded node:
<content:encoded><![CDATA[<iframe frameborder="0" scrolling="no" allowfullscreen src="https://soundfaith.com/embed/sermons/133833" width="600" height="337"></iframe>]]></content:encoded>

So, two problems:
1) The CDATA directive shouldn't be escaped.
2) The CDATA section's contents should ALSO not be escaped (that's why CDATA exists).

If you pattern it after your <title> nodes, I believe it will work. That should look like this:
<content:encoded><![CDATA[<iframe frameborder="0" scrolling="no" allowfullscreen src="https://soundfaith.com/embed/sermons/133833" width="600" height="337"></iframe>]]</content:encoded>

(Just a reminder again: you have to view-source on the RSS to see what I'm talking about. You won't see this problem if you just view the RSS feed directly in a browser.)

Thanks!
-Rob Eberhardt
Northminster Presbyterian Church

Daniel Ma

https://community.logos.com/discussion/comment/814832#Comment_814832

Sorry about that. The encoding issue should be fixed now.

Northminster Production

https://community.logos.com/discussion/comment/814849#Comment_814849

Thanks, Daniel. Progress!

I tried it 3 feed readers with <content:encoded>. One worked (some WP plugin), but Zapier and Feedly don't. Can you just set it as a regular <content> node? I've tested this with a modified feed and it works.

Also, can we get our own Image (as set in the Proclaim publish dialog) into the RSS feed?
Right now you're inserting your own mic icon with this:
<itunes:image href="https://files.logoscdn.com/v1/files/2702182/content.jpg?signature=NmM3dNsLgDbBm1KuSg7Q-luok-Y"/>
I'd like our own image there instead.
<itunes:image href="https://files.logoscdn.com/v1/files/3448798/content.png?download=true&signature=TbdfwV3dnw0ewAsLd9q3MzcRpgA" />

Thanks!
-Rob Eberhardt
Northminster Presbyterian Church

Daniel Ma

https://community.logos.com/discussion/comment/814896#Comment_814896

As far as I can tell, we are conforming to the RSS Content Module specifications by including the ":encoded" portion of the tag. Do you have an example of a feed (other than your modified SoundFaith feed) that uses the content tag and works with WP, Zapier, and Feedly?

Also, not being able to set your own RSS feed image is a known issue and is already on our backlog.

Northminster Production

https://community.logos.com/discussion/comment/815190#Comment_815190

Hi Daniel. I'm taking this off the back burner again. You were right about content:encoded, but it seems there are a lot of tools out there that don't recognize that. I've got that worked around now.

Any luck on the image issue yet? You're loading it fine on the channel page (e.g. https://files.logoscdn.com/v1/files/xxx/content.png?signature=xxx). If we can get that same image in our RSS feed I think we'll be set.

Thanks!
-Rob

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/862162#Comment_862162

Any luck on the image issue yet?

In https://soundfaith.com/api/channels/5295885/feed, I see <itunes:image href="https://files.logoscdn.com:443/v1/files/4101943/content.png?download=true&signature=2FATj6vx9gxqkRfisH16Hur4eSU"/> (your cross logo) instead of the microphone. Is this different from what you're looking for? Are you wanting the cover images for each individual sermon (shown in image below) to appear in the <itunes:image ... /> element?

-Patrick

Northminster Production

https://community.logos.com/discussion/comment/862467#Comment_862467

Yes, that's correct, Patrick. I'd expect each podcast would include the image that was chosen for it, and that shows on that page.

(Or put another way: the RSS feed should match the page that leads to the RSS feed.

-Rob
Northminster

Northminster Production

https://community.logos.com/discussion/comment/863451#Comment_863451

HI Patrick, I see that last Monday's 1.35.0.0221 update includes "Fix default cover image bug when publishing audio recordings to SoundFaith" -- is that this? -Rob for Northminster

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/865468#Comment_865468

Sorry for the delayed reply. Release 1.35 does not. The fix will be on SoundFaith, not in a Proclaim release.

Northminster Production

https://community.logos.com/discussion/comment/866283#Comment_866283

Thanks for getting back to me Patrick. Can you set any expectations on the Soundfaith fix?

(We're in the final stages of using this to syndicate our podcasts back into our own website, and this is the final piece we're eager for.

Thanks again,
-Rob Eberhardt for Northminster

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/867221#Comment_867221

Can you set any expectations on the Soundfaith fix?

Soon. Sorry, we have other bugs and features fighting for priority. I'm excited you want to use the feature and have moved this higher on the priority list.

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/867730#Comment_867730

Rob,

Are you currently using the <content:encoded> element's contents as described before? We've discovered that putting iframe markup here breaks the iOS podcast app by emitting the markup into the UI. Example:

While we'd love to support your use case, I'm afraid the content:encoded solution we've offered you breaks many other users' podcasts and we'd like to remove it.

I know this must be frustrating to hear after you've invested what sounds like quite a bit of time into automating your sermon publishing. I apologize. But removing the <content:encoded> tag will help solve a bug affecting more people.

A couple questions to help us make SoundFaith more useful:

May we remove the content:encoded tag from our podcast RSS feeds?
Why not just use the iframe we offer for publishing sermons to your church website instead of publishing each individual one based on the RSS feed?

Thanks for you patience,

Patrick

Christopher J. Dewar

https://community.logos.com/discussion/comment/868383#Comment_868383

I'm dealing with the broken descriptions in iTunes currently.

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/868652#Comment_868652

Since I've not heard back, we've removed the <content:encoded> element from the podcast.

Northminster Production

https://community.logos.com/discussion/comment/869118#Comment_869118

Patrick,

What were you thinking?!? A few days to respond about removing a 9-month-old feature? This is not enough of a window! The rush is especially galling when I've been asking for the RSS image fix since it came out.

The answer is YES we're actively using it, have been for months, and we depend on it for our website-publishing process.

I understand the desire to make your feed play nice with an app on iOS, but RSS is NOT an iOS app-specific format! It actually pre-dates iOS by about 7 years, is a general web content syndication format intended for embedding full HTML content into other sites, feed readers, etc. That iOS app is just of those readers, with its own quirks.

Please restore the months-old embed codes to the RSS feed ASAP! ...until you can do the appropriate R&D to properly make it play nice across platforms. A couple suggestions to get you started:

Make a separate RSS feed for iTunes. You've already got the perfect place for this in your UI - just restore the original feed at the top, and link the new one under the Subscribe button:
Or if you're stubborn there , you can still throw the non-Apple world a bone and move the embed content with the other content currently in the <description> node. (<description> was originally used for full content in RSSv1, and was superseded by <content> in RSSv2, but v2 still allows full CDATA content in <description> for legacy reasons.)

Meanwhile, I'm pretty upset about your hastiness on a breaking change, and we're scrambling to fix our website and Facebook cross-posts today. Please don't leave us stranded! Thanks,

-Rob for Northminster
513-290-1649
reberhardt@nmpchurch.org

Patrick Nausha (Faithlife)

https://community.logos.com/discussion/comment/870139#Comment_870139

Our apologies. The breaking change to the content:encoded element has been reverted.

Northminster Production

https://community.logos.com/discussion/comment/870334#Comment_870334

Thanks, Patrick! I've just run a test and confirmed our process is working again, so we should be good for tomorrow.

Good luck with iOS' HTML-incapable podcast app -- I think your easiest workaround is to just link an alternate/reduced RSS feed to your "Subscribe in iTunes" button.

Thanks again for listening and for the quick fix!
-Rob for Northminster