Closed meiqimichelle closed 2 years ago
Huh, curiouser and curiouser. In further testing, I believe the issue is that Hugo's alias magic doesn't work on the ipfs-served (<--this is probs not the right way to say this, but hopefully you get the idea) version of our site. Actually, none of the forwarding is working on that version (neither are are any of the fonts for that matter, but that's a separate concern).
So, https://cluster.ipfs.io/documenation/download/
resolves to
https://cluster.ipfs.io/download/
, no problem.
https://ipfs.io/ipfs/QmUCvkZJRXxJrroziKm5RgGUgzEQzG8YDPnEVD7aZyRzb7/documentation/download/
does NOT resolve to
https://ipfs.io/ipfs/QmUCvkZJRXxJrroziKm5RgGUgzEQzG8YDPnEVD7aZyRzb7/download/
as it should.
Instead, you get https://ipfs.io/download/
in the url and
ipfs resolve -r /ipns/ipfs.io/download/: no link named "download" under QmPVxQi7Ye1ArY6AFNfcZYauEup6fuTHbAoxAZVm8MvhWs
on your page.
@olizilla @cwaring have you run into this before working with other sites around PL?
Yes, that looks like an issue of using origin-relative urls (starts with a /
) rather than relative urls (no slash)
/download
will always bounce the user to <origin>/download
.../download
will bounce the user to the download folder one directory up from the current location.I'm not sure how to trick hugo into doing that for the aliases
config though. It should be making those urls relative as part of the relativeURLs = true
work it does.
For me it's fine of things like this do not work in the ipfs preview (known issue because of the relative location of the whole site).
I see we've got a:
That jumble of letters after `/ipfs/` is called a [*content identifier*]({{<relref "guides/concepts/cid.md">}}) and it’s how IPFS can get content from multiple places.
...on the IPFS docs Hugo site. Is that helpful in any way? My brain is mush right now and can't reason on this, but I wanted to get it documented somewhere for later. 😆
For #63 (404 on former download documentation url, should redirect to current download landing page)