Update sitemap to use relative links instead of localhost when missing site URL #1479
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Abstract
This PR makes so that when a site URL is null, or for localhost, we use relative links instead of absolute links using the fallback URL of
http://localhost
.This change was especially complicated as there are many conflicting factors to consider here. Most noted in #1469.
I eventually landed on this as I think it's the least bad decision. Relative URLs are technically not allowed by the sitemap spec, but considering that the alternative (and current implementation) is to use localhost which will never resolve, I think it's more reasonable to use relative links that will hopefully resolve.
While localhost URLs are valid when building locally, this is one of the drawbacks of this route, as Hyde does not know if a build is for testing or production as that would add a lot of complexity without much value (an early design decision that it makes little sense to have different static site versions for local/prod)
Impact
Due to this change, when a site URL is not set to a custom value, instead of the following XML which is syntactically valid according to the spec, but which will never resolve when deployed:
Instead, the output will now be as follows, which is technically not adhering to the spec, but crawlers should still be able to figure it out.
Considerations
I, for now, decided against adding a build warning, for now, as that would likely spam the console and not be relevant and could overwhelm the console for new users making their first build.
Since the docs currently just specify that a site URL is needed to be specified to use sitemaps, they don't need to be updated.