Add parameter to feed_meta for selecting a feed

[Ben Companjen]

As a developer of a website that has multiple feeds, I would like to call {% feed_meta %} with an argument so that I can select which of the defined feeds is linked from which pages. For example, on my events overview page I would like to link the feed of events (built from the events collection) and not include the default feed of posts.

I made this suggestion in a comment on #334 and do know of workarounds, so this is not high priority for me. I would have tried to help with a solution, but I do not understand enough about Ruby at this point. Thanks for your consideration.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll 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, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[Parker Moore]

This seems like a nice idea, though I'm not sure about implementation details either.

{% feed_meta %} => same as today
{% feed_meta all %} => unified feed
{% feed_meta events %} => feed for events collection only 

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll 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, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[Ashwin Maroli]

WIP Design draft
Community is free to leave feedback in subsequent comments.

---

Usage examples

{% feed_meta %}                                             // default; current behavior; backwards-compat;
{% feed_meta collection = <label> %}                        // meta tag for /feed/<label>.xml or config override
{% feed_meta collection = <label> category = <category> %}  // meta tag for /feed/<label>/<category>.xml
{% feed_meta category = <category> %}                       // meta tag for /feed/<post-category>.xml
{% feed_meta tag = <tag> %}                                 // meta tag for /feed/by_tag/<tag>.xml or config override

{% feed_meta path = <path> %}                               // future param for custom path e.g. /feed/categories.xml

{% feed_meta category = <category> tag = <tag> %}           // COMBO NOT ALLOWED; render default meta tag
{% feed_meta collection = <label> tag = <tag> %}            // COMBO NOT ALLOWED; render default meta tag

Notes

The plugin has not stabilized with a v1.0 release. So technically, backwards incompatibility is permissible.
On that note, the primary step forwards would be to streamline how feeds for tags and categories are generated even though the attribute genesis at Jekyll Core is similar for both site.tags and site.categories.

[jekyllbot]

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll 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, please consider whether it can be accomplished in another way. If it cannot, please elaborate on why it is core to this project and why you feel more than 80% of users would find this beneficial.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

[Parker Moore]

In other plugins, we do key:value Not key = value, is that right? For highlight for example.

The plugin has not stabilized with a v1.0 release. So technically, backwards incompatibility is permissible.

This plugin is used on GitHub Pages and other platforms so it would be fantastic to maintain compatibility with the current behavior wherever possible.