djipco / webmidi

Tame the Web MIDI API. Send and receive MIDI messages with ease. Control instruments with user-friendly functions (playNote, sendPitchBend, etc.). React to MIDI input with simple event listeners (noteon, pitchbend, controlchange, etc.).
Apache License 2.0
1.53k stars 115 forks source link

website: Add trailing slash to `/api` to prevent 404 #263

Closed Vexcited closed 2 years ago

Vexcited commented 2 years ago

When navigating on the navbar to the 3.x API, you are redirected to /api and every links there are something like api/classes/....

But when you're navigating using the sidebar in API, you're redirected to /api/ which breaks all the links in the page because of the paths.

Here, my solution is to add the trailing slash to /api in the navbar and to remove all the api/ in the links from the API index page.

Hope it helps !

djipco commented 2 years ago

I just merged you PR and, when I tested it locally, I got errors because the links now look like that: /api/api/classes/WebMidi.

I probably should have looked more carefully at what your were proposing. In fact, what problem is that PR solving?

Meanwhile, I'm going to revert it until we can figure out what's going on.

Vexcited commented 2 years ago

The problem is that when you're using https://webmidijs.org/api/, the links are https://webmidijs.org/api/api/classes/WebMidi which leads to a 404.

My proposal was to always keep the trailing slash and update the paths to match with it (so without api/ at the beginning).

Vexcited commented 2 years ago

I got errors because the links now look like that: /api/api/classes/WebMidi.

I tried to re-build the website myself and I didn't had this issue.

By the way, the link for the API Reference is wrong in the README.md: https://webmidijs.org/api/index gives me a 404.

If you want me to illustrate what my PR fixes, I'll try to show you what is happening for me.

/api/index

image

/api/ => Here the links are /api/api/classes

image

djipco commented 2 years ago

Well... I have been scratching my head over this for the past two hours. There are trailing slash issues in Docusaurus. Also, you can check out this table to understand how various hosting providers handle trailing slashes (webmidijs.org is hosted on GitHub).

So far, the only way I could make everything work is by setting Docusaurus' trailingSlash directive to false. However, doing so means that if somebody manually adds a trailing slash, the page will load but some links will be broken.

I tried setting the trailingSlash directive to true (which would make more sense in my opinion) but then all documentation files were getting a trailing slash. So, for instance, /api/classes/WebMidi became /api/classes/WebMidi/ which broke the links on that page.

So, for now, the link to the API page is /api and the link to the documentation is /docs. If you use /api/, links on the page will be broken. This is annoying me to no end but I do not yet know how to fix it. If you have an idea, I'm all ears (a workaround could be to force a redirect but this feels clunky).

By the way, thanks for bringing this issue to light. I really wish there would be a better solution...

Vexcited commented 2 years ago

Well, we could maybe do a script that fixes the build before pushing it to GitHub.

As you can see, in the /api/index.html file, the links are broken, but on /api.html, they aren't.

So maybe, we could remove the /api/index.html file to force GitHub Pages to use /api.html ?

Or we could do the contrary by keeping every trailing slash. According to this guide https://github.com/slorber/trailing-slash-guide, when hitting a folder from /folder, on GitHub Pages, it redirects to /folder/ so maybe /folder/index.html ?

djipco commented 2 years ago

Well, we could maybe do a script that fixes the build before pushing it to GitHub.

We could do that but, honestly, I'd like to keep things simple. It's already complicated enough as it is.

Or we could do the contrary by keeping every trailing slash.

I tried keeping all trailing slashes (trailingSlash: true) but it broke the links on most pages because they were now treated as folders.

There's probably a clean way to fix all this but I just don't have the bandwidth right now. For now, unless users manually play with the URLs, the documentation is working fine.

Having said that, if you find a clean solution, I will happily merge it. Thanks again for your help on this matter.

djipco commented 2 years ago

I contacted the Docusaurus technical team and was finally able to find a better solution. Inside a specific plugin, you can link to the actual markdown files instead of using urls. When you do so, Docusaurus takes care of properly updating links. This is what I did for the /api section. Starting now, it does not matter if you use /api or /api/, both simply work.

For links across plugins, the solution is to use root-relative links. So, all links in the /docs section that are pointing to pages in the /api section have been updated to be root-relative.

With both these changes, I think we now have something that's clean and working properly.