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

Relative links in RSS feed #141

Closed
palant opened this issue May 14, 2020 · 8 comments
Closed

Relative links in RSS feed #141

palant opened this issue May 14, 2020 · 8 comments
Labels
enhancement New feature or request upstream
Milestone

Comments

@palant
Copy link
Collaborator

palant commented May 14, 2020

W3C feed validator objects to the RSS feeds containing relative links: https://validator.w3.org/feed/docs/warning/ContainsRelRef.html. In fact, not all RSS feed readers will be able to correctly resolve those, which is why feed should always use absolute links. I investigated this issue a few weeks ago and it seems that Hugo will only apply the "make links absolute" logic to its own RSS feeds and there is no way to make it do the same for custom output formats.

Here is what my current work-around looks like:

<description>{{ replaceRE ` (href|src)="#` (printf ` $1="%s#` .Permalink) (replaceRE ` (href|src)="/` (printf ` $1="%s` .Site.BaseURL) .Content) | html }}</description>
@reuixiy reuixiy added the enhancement New feature or request label May 14, 2020
@reuixiy
Copy link
Owner

reuixiy commented May 14, 2020

This is correct, but I'm not sure if it's worth it, considering the build time that may increase.

I investigated this issue a few weeks ago and it seems that Hugo will only apply the "make links absolute" logic to its own RSS feeds and there is no way to make it do the same for custom output formats.

This is weird, maybe we should consider it as an upstream issue and submit an issue in Hugo?

@palant
Copy link
Collaborator Author

palant commented May 14, 2020

There we go: gohugoio/hugo#7272

@palant
Copy link
Collaborator Author

palant commented May 16, 2020

This is correct, but I'm not sure if it's worth it, considering the build time that may increase.

That argument should be moot given that build time appears to have dropped by ~25% due to recent changes. 😉

@reuixiy
Copy link
Owner

reuixiy commented May 16, 2020

Wow, then we can fix this issue now! Could you create a PR for this?

@palant
Copy link
Collaborator Author

palant commented May 20, 2020

Never mind. I measured this properly for my site now - master vs. v.4.3.1 (the latter required converting the config to TOML and adding utils/icon.html partial). The build times didn't change noticeably, so I guess what I saw was due to changes in my site rather than MemE. In fact, even building a search index on the lunr-search branch only increases the build times by ~2%.

@palant
Copy link
Collaborator Author

palant commented May 20, 2020

On the other hand, removing these two regular expressions didn't change build times either - their impact is too small for me to measure (two RSS files, limit is 10 for both).

@reuixiy
Copy link
Owner

reuixiy commented May 20, 2020

Yes, I just tested it with my site (one RSS file, 132 posts, no limits), and the impact is still very small.

So it's time to solve this issue now!

@reuixiy reuixiy added this to the v4.4.0 milestone May 21, 2020
@palant
Copy link
Collaborator Author

palant commented May 21, 2020

Pull request is #170.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request upstream
Projects
None yet
Development

No branches or pull requests

2 participants