Using a template for rendering the body #3
Comments
|
I needed this too, so I made a fork: I also made some fixes for bugs I ran into. Just set the body_template field in atom.ini to the filename of your template. You can access the item body in your template with the body variable. |
|
@kwellman could you open a PR to port this into this plugin? |
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 8, 2018
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.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
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.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
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.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
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.
eigengrau
added a commit
to eigengrau/lektor-atom
that referenced
this issue
Aug 9, 2018
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.
|
This is still an issue for me. Any way to get the PR merged? I'd be happy to help work on it if necessary. |
jcharaoui
pushed a commit
to jcharaoui/lektor-atom
that referenced
this issue
Oct 20, 2021
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I need the full body in the RSS feed - but it's rendered somewhat elaborately in a template.
Is there any way to render a complete template into the body?
The text was updated successfully, but these errors were encountered: