use relative paths for API URL

[joelpmichael]

When OctoPrint is using a base URL that isn't /, e.g. when created using OctoPrint Deploy, MarlinGcodeDocumentation doesn't work because it's trying to load the absolute URL /api/plugin/marlingcodedocumentation which doesn't exist. Using a relative path instead, without the leading /, appears to work fine.

[costas-basdekis]

Thanks for the report and the PR, @joelpmichael!

Is the base URL decided just by the path of the HTML page that is running, or is Octoprint adding a base URL tag?

I haven't run Octoprint for a while, and I'm only worrying that if you run the code from a different path it will try to fetch relative to that. Would adding a serve-side config for the base URL be a better option?

[joelpmichael]

Not sure exactly how Octoprint is handling the base URL, sorry. This is more a "hit it with a rock until it works" kind of fix. There does appear to be other plugins that use a relative URL, e.g. OctoPrint-Cancelobject calls OctoPrint.get("api/plugin/" + PLUGIN_ID);

[costas-basdekis]

OK, sorry for the delay, I finally run OctoPrint and had a look.

So OctoPrint does expose a base URL and a plugin URL, so let's use these on the frontend. Can you check on your various instances what does BASEURL point to in the browser? It should hopefully be what you expect.

Then, this PR should be a bit more straightforward:

1. Add a const MarlinGcodeDocumentationApiUrl = `${window.PLUGIN_BASEURL}marlingcodedocumentation`;
2. Replace any instances of fetch("api/plugin/marlingcodedocumentation" with fetch(MarlinGcodeDocumentationApiUrl

If you amend your PR this way I'll be happy to accept it

[costas-basdekis]

Hey @joelpmichael, gentle reminder about this. I think this is something I should do anyway, so let me know if you want to finish this.