Feature request: support shortcode output format for RSS feeds

[max-arnold]

Background

There are multiple cases where people try to render the .Content slightly differently for RSS feeds:

• https://discourse.gohugo.io/t/filename-for-shortcodes-when-using-custom-rss-output-format/8830
• https://discourse.gohugo.io/t/use-scratch-or-other-params-in-a-shortcode/1662
• https://discourse.gohugo.io/t/access-page-meta-data-while-building-the-rss-feed/8512
• https://discourse.gohugo.io/t/go-template-programming-partials-pipe-use-as-functions-recursive/11444/4
• https://discourse.gohugo.io/t/how-to-alter-the-shortcode-rendering-for-rss-output-format/14085

This is possible to do after #3220 was implemented, by setting page = ["HTML", "RSS"] and adding SHORTCODE.rss.xml template variant. Unfortunately, this setting produces per-page RSS feeds which is suboptimal and can mislead some RSS readers (wrong RSS link).

Also there is slightly adjacent request to allow page context in shortcodes: https://discourse.gohugo.io/t/page-context-in-shortcodes/284

Feature proposal

1. Allow shortcode output format to be selected based on home/section output format.
2. Maybe also use page Kind in the shortcode template lookup order. This would allow to solve the adjacent use case https://discourse.gohugo.io/t/page-context-in-shortcodes/284

Plus it makes sense to document format- and language-dependent shortcode lookup order here https://gohugo.io/templates/shortcode-templates/#shortcode-template-lookup-order

[kizu]

Yes, this is something I'd really like to see as well! Basically, it would be nice to have not only for RSS, but just for any output format.

And, maybe, I'd call the current behaviour a bug? I'd say that if there is an output for at least one type of pages (home for RSS, for example), the shortcode substitute should still work, without the need to enable the RSS output format for page type.

[bep]

And, maybe, I'd call the current behaviour a bug?

You can if you want, but int this particle case I suspect you will get faster attention on this if you label it an enhancement. "Fixing stuff" is not as motivational as "building stuff".

[kizu]

Oh, sorry, I didn't think about that it could be read like that, oops, didn't intend it like this. It was just that I tried using this without adding RSS to page a week ago and couldn't make it work even while I had it for home, so finding that adding it for page impacts the rendering of the home was strange.

This would totally be an enhancement, and I know a bunch of other people who would be happy to use this kind of feature — as I said, not only for RSS, but, for example, for .json, which can be used in the same way basically (for example, for search index json).

I would try to think more about how the wording of comments can motivate or demotivate maintainers and developers, sorry about that again!

[bep]

I would try to think more about how the wording of comments can motivate or demotivate maintainers and developers, sorry about that again!

No problem, but I find that it is often more effective in the world of Open Source (where people spend their free time on stuff) to have a "glass half full" mindset. I don't mind adding the "bug label" on obvious misbehavior, but when in doubt, use the enhancement. This particular issue was implemented as intended and it works fine, but it has it's obvious limitations -- hence the "enhancement".

[bep]

This will be fixed as part of #5583 -- sorry that this has taken so long, but I really had to look at this in a bigger picture.

[max-arnold]

I added the *.rss.html shortcode variants to the same folder and can confirm that this feature works perfectly! Multiple ugly replaceRE in my RSS template are gone.

Thanks a lot, @bep!

[bep]

@max-arnold glad to hear that!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.