So, I have a podcast feed in the RSS 2.0 format and it works fine.
What I would like to be able to do is rearrange the items in the feed, or even add data to items. The problem is that these items have already been downloaded into my podcast app.
Is there anything I can do to the xml file to trigger the client to refresh the feed and bust out of what has already been cached, besides deleting and re-subscribing?
There isn't an element or flag you can send to tell feed readers or podcatchers to remove or delete an already downloaded (or cached) item.
You can send an updated item if you change the <guid> field, which will cause readers to see it as a new item to download or fetch.
You can also update the entire contents of the item and readers may or may not (depending on their settings) replace it on the user's side, essentially "deleting" it in a sense with the newer or corrected version.
Alternatively, if you switch to sending out with an Atom feed format, there is the <updated> element, which tells readers when the item was last updated, but again, whether or not the reader downloads a fresh copy is up to its build/settings.
Related
In Sitefinity, almost everything is able to be revisioned. In the backend interface at a page for a content item you can click on Revision History and see revisions.
We're in a situation where we're manually uploading documents in to the Documents & Files library through a custom form. We're able to do this using the Content Lifecycle which has pretty good documentation: http://www.sitefinity.com/documentation/gettingstarted/developers-guide/sitefinity-essentials/modules/content-lifecycle .
What doesn't have any documentation is how to modify a document so that it updates the revision of that document programmatically, not replace it. Right now, we're only able to replace it and the revision history stays empty.
I think you cannot keep the previous version of the document in Sitefinity.
The revision history for the documents keeps track for the metadata only, e.g. Title, Author, etc.
If you replace the file, there is no way to revert it back through the Revision History.
Disclaimer: I haven't tested this in the 7+ versions.
When I make a substantial update (not just correcting a typo) to an article in my blog, I want to ensure that readers see the updated article again in their news feed. From what I have read, here are some of the options I see:
Create an entirely new article (largely a duplicate of the original). Apparently a bad idea -- duplicate content would be bad for SEO.
Change the published and/or updated timestamp of the article. It seems that, in most readers, this will not make the article show up as unread.
Change the RSS item GUID or Atom entry id. This is a big NO-NO according to the Atom specs, but I'm not sure about RSS.
So, there doesn't seem to be a good option, unless I'm missing something.
What are the ramifications of changing RSS item GUID or Atom entry id? Are the Feed Police going to show up at my door for changing an article ID?
updating the "updated" field for that entry should be correct. Do not forget to also update "updated" field for feed itself, any Etags/last-modified HTTP headers (if existing but not auto-generated), and wait/force reader to actually do the refresh.
if you still have the problems with some of the readers you should check with feed reading software authors to see if that is intentional.
As for the second part, changing id won't get Feed Police on your door, but if it happens often enough, such articles which would show as duplicate could annoy your followers to just ignore/drop the feed.
see this and this answers too
The RSS <guid> or Atom <id> is an element used to uniquely identify its parent item. Feed readers and aggregators use this field to determine if the item has already been downloaded or fetched.
If you change an RSS <guid> or Atom <id>, then readers and aggregators may use this as a signal or flag that the item is to be downloaded again because the GUID or ID held previously no longer matches what it has in its database or lookup.
Changing the GUID or ID is not a way to force an update in place. It's a way to say, "I have something brand new for you to download/fetch".
In RSS, if you add ?fake=parameter to the GUID that can be a substitute way to force a new download. But the old fetched item will still remain because it doesn't share the GUID.
You can't reliably force a download via RSS or Atom using the publish or updated date.
Best you can do is to change the contents of the item and allow readers or aggregators to update as they wish, as not all work the same in what they do when they see a change in content like this for an item it already has.
As both answers at this point state: there is no perfect way. Changing the guid will make everyone believe that the content is brand new, hence probably creating duplicate content, and chaging just the element will probably not always trigger a full refresh.
Using PubSubHubbub may help as it is fat pings. Wich means that the subscriber will get the updated data right away and can store it under the same key/unique id that the previous version.
I need to get number of downloads per document in Media Library. I am using Sitecore 6.4.1 and Sitecore OMS 1.1.1. Is there a Sitecore built-in way or API that allow me to retrieve such information?
Well you cannot make sure that the download has completed, but a hit is registered so you can go to the media item, click the analyze tab and then reports. As far as I remember you should now be able to select a report of hits.
The first thing that you need to make sure that the download is captured by OMS. You have to associate the download event with the item that is downloaded. Once you do that, you can go to the download report and see the number of times it's been downloaded. If you don't associate the download event with the item, however, it will not trigger the page event and therefore will not be trackable in OMS.
Got an established libsyn rss feed, got a new drupal website for the podcast. Libsyn provides a player but not correct aesthetic. I can upload and play mp3 files with audio module and mp3player module, and like the mp3 player's output, a simple flash player, but I don't want to be manually moving the podcast audio files (mp3) over every week. Looked at importing automatically with Feeds, but it's not working and besides that's creating extra files unnecessarily on the drupal site.
Just want to use the mp3player modulee's flash player in a drupal page, which feeds the latest mp3 file from a libsyn rss feed. Don't really need to store or play multiple episodes, just the latest episode.
How would you do it?
Create a content type for my podcasts with a title and a field for the URL of the MP3
Use FeedAPI and map the title to the title of the node
Map the file URL to the URL field
Use Contemplate to set the URL field to display as [swf file="token_for_URL_field"], which will use the SWF Tools module and whatever player I've selected to play the file
So you need these modules CCK, Contemplate, FeedAPI, and SWF Tools, and that should do the trick.
Why don't you have your own site be the master and libsyn get it from you? Do they not allow an import feature, with which you'd keep your existing RSS through them. Then you can have total control over your site and push the content to all kinds of other great podcasting networks.
Realize I may have no idea about libsyn works.
When you say feeds didn't work, how did it fail? Are you using feed mapper? You may need to write a custom plug-in for feed mapper to get it to do the right thing with the video files. Feed api supports expiring imported feed items so you should be able to get it to automatically delete old ones. I'm not sure whether the video files will be automatically deleted when the nodes are. If not, you should be able to make this happen by implementing nodeapi's delete op for the content type you are using to store your imported rss items.
Alternatively, maybe you could just harvest the video's url on libsyn, and have the player use that. I don't know whether there's a good player which supports using a field's data for the location of the source it should play.
Also, if you haven't already, I'd encourage you to post your question on groups.drupal.org since that's read by lots of drupal experts.
I'm working on an RSS feed for a custom tasking system we use, and I'm still wrapping my head around how things should work. What I want to have is a feed for each user that shows tasks assigned to them, and additionally a feed for each task that shows updates for the task.
What I want to know right now concerns the user feed. When a case assigned to a user is updated, I currently have code to change the pubDate entry for that item and the lastBuildDate for the channel. I was hoping this would make the item appear as unread in readers so that the user would know to look at the item again, but this seems not to be the case. Should I be changing the guid, even though it's really the same items? What would the side-effects of that be?
Is there anything I'm missing? How can I solve this?
Changing the <pubDate> does indicate that the entry changed, but there is no requirement that a given RSS reader do anything about it. (Strictly speaking, there is no requirement than an RSS reader do anything, but let's remain reasonable.) Some reader do mark updated entries as changed. For example Bloglines.com can optionally detect changes in the <description> and mark entries as new again if that case.
Depending on your reader, changing the <title>, <description>, or <pubDate> might give you the behavior you want. But as GateKiller mentions above, your safest option is to make it an entirely new entry with a new <guid>. While you're at it, you might want to use it as an opportunity to add a direct link or details about the update.
Of course, if you're writing both the producer and consumer of the RSS, and your goal is that the feed always contains the full set of assigned tasks, just updating the <pubDate> will work just fine.
The solution is to also change the GUID which means including the updated time in it. The GUID provides the uniqueness for each item in the feed and will be marked as unread if you put the date updated in it.