No absolute url via post_url?

The docs say:

Since Jekyll 4.0 , you don’t need to prepend link and post_url tags with site.baseurl .

But when I add links in markdown with {% post_url 2010-07-21-name-of-post %} or {% link news/index.html %}, the output is a relative URL. This is a problem in my RSS feeds, where the links should have absolute URLs.

Is there some config setting I’ve missed?

There is no need to prepend site.baseurl but if you need absolute URLs, you may prepend site.url:

{{ site.url }}{% post_url 2010-07-21-name-of-post %}

Now I’m confused! The behavior pre Jekyll 4.0 was that post_url returned a relative URL. The callout in the docs specifically mentions, 4.0 implying that this has changed. I looked at the issues on Github and happened to see that a user with your nick says:

The post_url and link tags prefixes site.baseurl from Jekyll 4.0 onward.

I’ll look into this further to find out if it’s somehow caused by my config.

How are you generating your feed? With the Jekyll-feed plugin?

I don’t believe it converts relative urls to absolute at least from what I gathered from the closed issues asking for such a feature.

So to get links and assets with relative urls resolving correctly in feeds you’ll need to make them absolute in your content. Unless there’s a clever way around that by modifying the feed plug-in or Atom layout it uses.

I made my own template for the RSS feed.

I could search <a href="/"> and replace it with <a href="[my site url]/". But that’s clunky, prone to mistakes and, as I understand it, superfluous with the expected behavior or post_url.

post_url produces relative links. It doesn’t perpend your site url before links which is needed to make them absolute and work in feeds. The only way to make them absolute is to add site.url before the link, which all your domain to the path.

You might be confusing site.url and site.baseurl too, they’re two different things.

I just tried with a fresh Jekyll 4.2.2 and there I also only get relative URLs. Thanks for checking everyone! IMO this is either a bug or an issue with the docs.

OOHHH gotcha! Damn that’s an unfortunate choice for a variable name. Thanks for the blog post!