hugo
hugo copied to clipboard
gohugoio
Need option to use full content in rss.xml
The default rss.xml template uses .Summary for the content of each item. If you want to use the full content instead you have to override the entire template. It would be nice to have an option one can set int he config.toml to control if .Summary or .Content is used.
Seems like adding whole content to summary does the trick, however it's a shame I have to make post summary-less to have it added to RSS properly (with full content). Here is the line which misbehave.
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
https://github.com/gohugoio/hugo/issues/4242 is an issue proposing a solution to this.
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
I would like to advocate an option to set the RSS-feeds to full-text.
Hugo users want this
A quick websearch for "hugo full text rss" finds up a lot of blogposts of hugo users who manually adjusted their RSS templates. These are all from the first page of results:
- https://www.gideonwolfe.com/posts/sysadmin/hugo/hugorss/#showing-all-your-content
- https://fuzhouch.com/post/2020-06-11-hugo-tips-generate-full-text-rss-atom-feeds/
- https://blog.eternalrecurrence.space/posts/displaying-the-full-content-in-hugo-rss-feed/
- https://discourse.gohugo.io/t/full-text-rss-feed/8368
- https://www.duskborn.com/posts/fixed-up-rss/
I think that this shows, that full-text rss is a feature that many hugo users want.
Other static-site-generators have it.
@obar pointed out that this feature is already present in many other static site generators like:
The hacky solution is insufficient
@nekr0z pointed out that just swapping out Summary and Content could result in "non-conformant" RSS feeds.
I think with the recent introduction of transform.XMLEscape the PR #10589 could finally be merged (but of course adjusted slightly with .Content | transform.XMLEscape | safeHTML instead) 🙏
I think there's consensus that a global (site config) setting would be useful, but then I can't control it on a page-by-page basis.
Simply stuffing the full content into description may not be right approach either:
https://www.rssboard.org/rss-profile#namespace-elements-content-encoded.
Publishers who don't want to employ item summaries in their feeds SHOULD use the description element for an item's full content rather than content:encoded because it has the widest support.
Publishers who employ summaries SHOULD store the summary in description and the full content in content:encoded, ordering description first within the item. On items with no summary, the full content SHOULD be stored in description.
It seems like the right way to do this is to specify both description and content:encoded (when full content option is enabled), but the "has the widest support" condition is troubling.
Given the above, I am inclined to leave the embedded template as-is. Overriding an embedded template is trivial.
Additionally, if your markdown images point to page resources, you will need to enable the embedded image render hook to properly resolve image paths relative to the feed.
Thanks for working on this. Feeds only displaying summaries instead of full content are my number one problem with Hugo websites, and trying to talk to each Hugo website author individually is a PITA. I very much look forward to a simple and native solution. <3
Hi @bep!
I am trying to add this option to services.rss along with the limit setting. Am i looking at the right place?
https://github.com/gohugoio/hugo/blob/0ea796dad11e5d9f5b4c96a8e65f8272c9e4ccb5/config/services/servicesConfig.go#L72
@kskarthik This issue is a proposal. It has not been accepted as a planned enhancement by the project lead. Please don't spend any time on a PR unless this proposal is accepted. If you submit a PR before proposal acceptance it will be closed.
@jmooring What's the process to get a/this proposal accepted? It clearly has quite some support from users and potential contributers.
@ilf My views on this proposal have not changed. I think this is something that site and theme authors should implement as needed/desired.
Putting aside the summary/content ambiguity as I described above, to properly implement this on any site requires link and image render hooks to properly resolve Markdown link and image destinations. This can be addressed by enabling Hugo's embedded link and image render hooks, but some sites and themes use custom render hooks that do not properly handle resolution of Markdown destinations.
Why is this an issue? Unlike a dynamic CMS (e.g., Drupal, WordPress), Hugo does not have a routing system. When site and theme authors blindly render page content in an RSS feed, images and links may be broken because they are relative to the content page, not the feed page.
I've looked at a few Hugo sites that have implemented content in their RSS feeds, and I'd guess at least half are broken.
I think this is better handled with guidance in a tips and tricks article on the forum.
My view on this may be unpopular, but I think it's a fair assessment.
@jmooring: I am confused by your last comment. First, you say every "site and theme author should implement" this themselves. Then, you say "at least half" the sites trying this "are broken".
There are dozens of site authors that want this feature. There are dozens of sites who tried to implement this themselves. Why not just do it right once?
How about taking the latest attempt from two days ago: https://github.com/grml/blog.grml.org/commit/eea4dd7809a1e99bd30e40729296de8a14343afc? What's wrong with this implementation?
What's wrong with this implementation?
See my previous comment, in particular:
When site and theme authors blindly render page content in an RSS feed, images and links may be broken because they are relative to the content page, not the feed page.
The default rss.xml template uses .Summary for the content of each item. If you want to use the full content instead you have to override the entire template. It would be nice to have an option one can set int he config.toml to control if .Summary or .Content is used.
technically, you should not be including the entire content of an article in an RSS feed, as the <description> element should not include any HTML, rather only plain text. (and the <description> should really be, well, just that: a description)
The best solution to this is really just to use an Atom feed, which can include HTML, and is well-suited for including the entire article body. (see: #13565)
technically, you should not be including the entire content of an article in an RSS feed, as the
<description>element should not include any HTML, rather only plain text. (and the<description>should really be, well, just that: a description)
Do you have a source for these claims?
The official RSS specification sais: "entity-encoded HTML is allowed" and has HTML in official examples of <description>.
Also, the official RSS feed of the official RSS Advisory Board includes both entire content and HTML in its <description> elements.
The best solution to this is really just to use an Atom feed, which can include HTML, and is well-suited for including the entire article body. (see: #13565)
Personally, I don't care much about RSS or Atom.
I just want the default feed of Hugo to include full content by default.
technically, you should not be including the entire content of an article in an RSS feed, as the
<description>element should not include any HTML, rather only plain text. (and the<description>should really be, well, just that: a description)Do you have a source for these claims?
The official RSS specification sais: "entity-encoded HTML is allowed" and has HTML in official examples of
<description>.
If you paste a feed which contains HTML into the W3C Feed Validation Service, it will warn you when any of the elements (including the <description>) contain any HTML.
This value appears to contain HTML markup. Be advised that clients will behave unpredictably in the presence of such markup: some will interpret it as HTML, others will strip it, and still others will display the markup itself.
though, from a reading of the spec, it seems like HTML should (hopefully) be fine so long as it's only in the <description>.
See related proposal https://github.com/gohugoio/hugo/issues/13565, and note my comments regarding:
- Inclusion of HTML
- Inclusion of full content