The current Atom feed generator uses a single item from the configuration file (@config[:base_url]) for three different, logically separate functions:
The feed's xml:base attribute,
The feed's <id>,
The feed's <link rel="alternate"/>.
Only the first of these uses, which specifies the base from which links within content should be interpreted as relative to, can legitimately be regarded as a per-site configuration:
The <id> must be different for different feeds coming from the same site. It would be more sensible for this to default to something related to the @item being compiled; it should also be possible to configure this on a per-feed basis.
The <link rel="alternate"/> should be a link to the thing for which this is a feed. It only makes sense for this to be the site's base URL if the whole site is a blog. If the blog is a subsite (and if there are more than one, then at least one of them must not be equivalent to the whole site) then the link should be to that subsite. This should be configurable; the base URL should probably be a prefix for the configured value, allowing no configured value to have the same effect as today.
*
This is one where (because I have two blogs on my site, and they are both subsites) my need for this is fairly sharp, and the code looks simple enough that I might be able to propose a PR if you don't think you would have the time to look into it. Let me know if that's the case.
Another note on this: the W3C validator flags a link like <link rel="alternate" href="https://iay.org.uk/"/> with a compatibility recommendation that it should be a same-document reference (see this).
I think that means that the existing implementation would be improved if it just used / here, but perhaps that's a separate issue. Certainly, any new parameter should not be appended to base URL by this reading.
Migrated from nanoc/nanoc#1300.
@iay said:
The current Atom feed generator uses a single item from the configuration file (
@config[:base_url]
) for three different, logically separate functions:xml:base
attribute,<id>
,<link rel="alternate"/>
.Only the first of these uses, which specifies the base from which links within content should be interpreted as relative to, can legitimately be regarded as a per-site configuration:
The
<id>
must be different for different feeds coming from the same site. It would be more sensible for this to default to something related to the@item
being compiled; it should also be possible to configure this on a per-feed basis.The
<link rel="alternate"/>
should be a link to the thing for which this is a feed. It only makes sense for this to be the site's base URL if the whole site is a blog. If the blog is a subsite (and if there are more than one, then at least one of them must not be equivalent to the whole site) then the link should be to that subsite. This should be configurable; the base URL should probably be a prefix for the configured value, allowing no configured value to have the same effect as today.This is one where (because I have two blogs on my site, and they are both subsites) my need for this is fairly sharp, and the code looks simple enough that I might be able to propose a PR if you don't think you would have the time to look into it. Let me know if that's the case.
Another note on this: the W3C validator flags a link like
<link rel="alternate" href="https://iay.org.uk/"/>
with a compatibility recommendation that it should be a same-document reference (see this).I think that means that the existing implementation would be improved if it just used
/
here, but perhaps that's a separate issue. Certainly, any new parameter should not be appended to base URL by this reading.