Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feed enumeration, alt support #16

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

eigengrau
Copy link
Contributor

This adds support for a Jinja function/filter, “atom_feeds”, which can be used
to enumerate all feeds defined in the project (“atom_feeds()”), or those
relevant to the page being generated (“atom_feeds(for_page=this)”).

This is convenient, e.g., to define a generic site header which automatically
displays a “subscribe” link on those pages which generate feeds.

return feeds

def atom_feeds(self, for_page=None):
if not for_page:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to be explicit and use if page is None ?

@eigengrau eigengrau changed the title Support feed discovery and enumeration Pull for nixjdm Aug 8, 2018
@eigengrau eigengrau changed the title Pull for nixjdm Pull for nixjdm (feed enumeration, alt support) Aug 8, 2018
@eigengrau eigengrau changed the title Pull for nixjdm (feed enumeration, alt support) Feed enumeration, alt support Aug 8, 2018
@eigengrau
Copy link
Contributor Author

For a project I needed “real” support for feed alternatives, so I came up with 6c3241d. This replaces field names by template expressions, so that we can localize things we otherwise can’t. For convenience, we also support alt-specific config values, so there’s no need to copy-paste feed settings.

@eigengrau eigengrau force-pushed the feed-discovery branch 3 times, most recently from cfe1101 to c40f134 Compare August 9, 2018 10:27
This adds support for a Jinja function/filter, “atom_feeds”, which can be used
to enumerate all feeds defined in the project (“atom_feeds()”), or those
relevant to the page being generated (“atom_feeds(for_page=this)”).

This is convenient, e.g., to define a generic site header which automatically
displays a “subscribe” link on those pages which generate feeds.
While lektor-atom currently supports creating feed variants by relying on
specially-crafted item query expressions, this is only useful for item model
fields that contain natural language strings. When creating feeds based on
structured data, this is not helpful, since field values are identical across
two alts.

E.g., when we would like to publish a feed based on PDF attachments that have a
`volume_number` set, we are currently unable to have the English feed display
item titles as »Volume 1« in the English feed resp. »Ausgabe 1« in the German
alternative.

This commit adds support for such use-cases by adding two new mechanisms:

1. Instead of supplying field names to map records to Atom entries, the user
   supplies a Jinja template. These expressions are evaluated with `this` bound
   to the blog resp. the item record.

2. For a feed named `feed`, configuration values are first looked-up in the
   config file section `[feed.ALT]`, where `ALT` is the alternative currently
   being generated. This allows settings defaults in `[feed]`, and overriding
   only those settings that are locale-specific by adding them to `[feed.ALT]`.

As a side-effect, this also benefits users that don’t use alternatives, since it
enables them to compose item titles, bodies, etc. using multiple fields at the
same time.

Fixes lektor#3, lektor#13.
Lektor sometimes yields invalid URLs for attachment records that have ‘alt’ set.
We work around this by forcing the primary alt when linking to attachments.
@goanpeca
Copy link
Member

:-p @nixjdm ?

@jcharaoui
Copy link

jcharaoui commented Oct 25, 2021

I've rebased and submitted a PR to the author of this feature. If you're still interested in merging this and would like a new PR with the rebased code, let me know!

eigengrau#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants