Guard against type error in absolute url

[benbalter]

If a user sets an image hash in a post's YAML front matter, and that hash does not contain a path key, this line in Jekyll Feed will pass the full image hash to the absolute_url filter.

Via #6185 and #6253 we normalize the baseurl and site.url inputs, but we don't normalize the argument passed to the absolute_url filter (we normalize the input passed to relative_url), meaning if you pass anything other than a string, it method will raise a TypeError when it tries to determine if the non-url is absolute.

This PR calls an explicit to_s on the input, seeking to return a malformed URL, rathering than breaking the build (which is often opaque due to a single post missing a post.image.path field raising an error in generating feed.xml).

[parkr]

Code looks solid. 👍

This kind of error is nice; it provides the user with the information that the url they provided is complete bogus – "whoops, gotta fix that!" It calls them to action in a way that suppressing this might not. Do you agree that we're losing value there?

[benbalter]

it provides the user with the information that the url they provided is complete bogus... It calls them to action

@parkr see the bug report in jekyll/jekyll-feed#178. Given that it took some of Jekyll's top contributors 3+ weeks to determine the root cause of the opaque Can't convert Hash into String. in feed.xml error (with no way of knowing which post caused it), I'm not sure how much value raising the error provides.

An alternative approach would be a more descriptive error with page/post-level backtrace, but that's beyond what I'm able to invest right now.

[parkr]

@jekyllbot: merge +fix

[parkr]

Backporting to 3.5 targeting a 3.5.2.