Support for media:content was added in #3049802: Add support for Media RSS.
The text content (media:description) is not included however. I propose adding Media description as a new mapping source. This would be particularly useful for mapping image media alt text.
Initial patch forthcoming.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | add_media_description-3258997-7.patch | 4.23 KB | jastraat |
| #6 | add_media_description-3258997-6.patch | 2.04 KB | jastraat |
| #2 | add_media_description-3258997-2.patch | 2.04 KB | jastraat |
Comments
Comment #2
jastraat commentedThis patch adds the textContent of the media item from the feed as a mapping source. Technically this could be added for the media thumbnail as well. Alternatively, the code could load the media:description element directly and pull the textContent from that.
The tests for MediaRSS should probably be altered to include a media:description element within the media:content element as well.
e.g.
Comment #3
kristen polThanks for the issue and patch. Here is some feedback when reviewing the code:
Right now the
descriptionformediarss_descriptionis the same as thedescriptionformediarss_contentbut it should be unique for the field, e.g.1) Where is
textContentcoming from? I see agetDescriptionfor theMediaTypeentity but not inMediaentity.2) I'm not sure the description should be cleaned up here. Shouldn't it be import as-is? If so, I propose simplifying this as:
Now I'm wondering if there is a description in media by default... have to go check :)
Comment #4
kristen polOkay, I see my confusion... was thinking about the media entity but this is the media RSS:
https://www.rssboard.org/media-rss#media-description
but still not sure where the
textContentis coming from.Comment #5
kristen polAlso, this does need tests to be updated as mentioned before, so tagging.
Comment #6
jastraat commentedThis is a great suggestion. I was focused on getting a working patch, but agree that a more specific description would be better. Part of the reason I debated what to say is that in the code I am not technically pulling media:description. Instead I'm getting the textContent of the media:content node.
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent
This is why I was doing the cleanup; the textContent is not just the text of the description but is essentially everything nested within the media:content entity. In the case of the feeds we are pulling, this is typically media:description and media:credit.
Another approach would be to call getMediaElement a second time on media:description specifically, and perhaps that is a cleaner approach.
Attaching a new version of the patch with an updated description as suggested along with the alternative approach.
This does still need the updated tests -
Comment #7
jastraat commentedOk, attaching a version with an attempt to adjust the tests to account for the new element.
Comment #9
megachrizThanks for the patch! I fixed the code style issues. Because I was curious what happens if a RSS feed contains a
<media:description>element but not a<media:content>element, I added a sixth entry to media-rss.rss2. It turns out that in that case "mediarss_description" is not set. Not sure if that should be the expected behavior, so I left out an assertion for that.Should "mediarss_description" be able to exist without "mediarss_content"? Or would that be considered an "error" in the RSS feed? Having a
<media:description>without<media:content>in a RSS feed item makes no sense?Anyway, committed #7 with my few additions. Feel free to reopen if there is a case where "mediarss_description" should be able to exist without "mediarss_content".
Thanks @Kristen Pol too for doing the code review.
Comment #10
jastraat commentedMy assumption was that media:description would not make sense without media:content, so that was how I wrote the patch initially.
Thanks!