interledger / interledger-website

🙅 Previous version of the interledger.org website
6 stars 10 forks source link

Tech Doc hyperlinks in center column route to 404 #6

Closed mccamon closed 3 years ago

mccamon commented 3 years ago

Start at https://interledger.org/rfcs/0027-interledger-protocol-4/ Index in left column works properly as build from the yml file in CloudCannon. Issue is with links in main (center) column. For instance visit https://interledger.org/rfcs/0009-simple-payment-setup-protocol/ then review the STREAM hyperlink in the body copy. Hover shows the link is https://interledger.org/rfcs/0029-stream/0029-stream.md Clicking on this link resolved to 404. While I did not exhaustive verify each instance of this issue, I did reproduce the error with other center column links on other doc pages like: https://interledger.org/rfcs/0031-dynamic-configuration-protocol/ (Interledger Architecture), and https://interledger.org/rfcs/0032-peering-clearing-settlement/ (Specification).

tbeck commented 3 years ago

@mccamon I did some further digging on this issue and it looks like these have always been broken links. Within the context of Github they behave as expected, but when we pull in the spec content the relative paths don't work as you outlined.

You can see what I mean here: https://github.com/interledger/rfcs/blob/master/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

It is not always consistent in the specs though and I have found instances that link to the folder rather than the .md file ie... The links in this spec content https://github.com/interledger/rfcs/blob/master/0026-payment-pointers/0026-payment-pointers.md

Possible Solutions:

  1. Update spec content so that all links point to folder rather than .md files
  2. Write a custom filter (regex) that would strip the filename and extension from those links as we pull spec content on build.
  3. Add a redirect pattern that could catch all .md requests and redirect accordingly.
  4. Dynamically update all spec links to point to Github instead of the

Let me know if you have any insight or opinions on the solutions I outlined here? Especially with regards to 4. Otherwise... we will attempt to implement either the second or third option and test.

Thanks!

mccamon commented 3 years ago

Yikes, that’s a real riddle. Personally where possible I like categorical solutions. Before I answer wouldn’t #1 fix this for good and create higher reliability long term and in other places where it might get ingested? Clearly it’s not a quick as we would need to submit pull requests on the original doc. Maybe they could help clean that up too??

================ Mike McCamon 913.940.2737 "Always do right. This will gratify some people, and astonish the rest." - Mark Twain

On Apr 9, 2021, at 9:44 AM, Tom Beck @.***> wrote:

 @mccamon I did some further digging on this issue and it looks like these have always been broken links. Within the context of Github they behave as expected, but when we pull in the spec content the relative paths don't work as you outlined.

You can see what I mean here: https://github.com/interledger/rfcs/blob/master/0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md

It is not always consistent in the specs though and I have found instances that link to the folder rather than the .md file ie... The links in this spec content https://github.com/interledger/rfcs/blob/master/0026-payment-pointers/0026-payment-pointers.md

Possible Solutions:

Update spec content so that all links point to folder rather than .md files Write a custom filter (regex) that would strip the filename and extension from those links as we pull spec content on build. Add a redirect pattern that could catch all .md requests and redirect accordingly. Dynamically update all spec links to point to Github instead of the Let me know if you have any insight or opinions on the solutions I outlined here? Especially with regards to 4. Otherwise... we will attempt to implement either the second or third option and test.

Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

tbeck commented 3 years ago

Yes... the first option is the easiest on our end and would prevent us from inadvertently causing additional issues with link paths.

mccamon commented 3 years ago

Okay I agree #1 is best. So what's the easiest way to get that fixed (and by whom?) I don't mind submitting pull requests, just want to be sure it's correct and complete.

tbeck commented 3 years ago

@mccamon - I don't know who would be responsible for this. It would need to be someone on the Interledger side though. Adrian or Briana should know.

tbeck commented 3 years ago

@mccamon - Just pushed a simple fix for this to the develop branch.