Better relative urls support #1980
Conversation
When running Hugo with relative URLs, as is the case when a developer runs `hugo` in a regular checkout of this repository, there is no `https://` prefix, and therefore the current logic failed. Fix this logic, and while at it, simplify the preceding code a bit. Note that this logic needs further adjustment, then, for importing the `pagefind.js` library: This `import`, if relative, is relative to the location of `application.js` (which is not the case where `baseURLPrefix` is used to set `href` and `src` attributes, which are relative to the top-level directory of the site). This _happened_ to work before because the bug was hidden by the bug where `baseURLPrefix` was not adjusted correctly for `HUGO_RELATIVEURLS=true`. Signed-off-by: Johannes Schindelin <[email protected]>
When building the site with `HUGO_RELATIVEURLS=true` (which is the default when building locally), the `404.html` page rightfully assumes that its resources, such as images, can be found via relative URLs like `./images/favicon.ico`. That leads to a problem when the `serve-public.js` script wants to Use it in case it does not have certain file that is in a subdirectory. For example, when a developer directs their web browser to http://localhost:5000/docs/git-undo, the result will be the 4O4 page, but it will be unstyled because it looks for the CSS and the wrong location. The solution is to specify the base URL explictly in the served 404 page. In this instance it is easy because we know exactly that this script will serve the site via http://localhost:5000/ and therefore the base url is simply the `/`. Signed-off-by: Johannes Schindelin <[email protected]>
|
I have no idea what this does, but sure |
!
@To1ne It fixes the The idea of The problem solved by this PR is that this computation did not work when the script location was The other problem solved by this PR is that when testing locally via
👍 |
Changes
Context
I was annoyed enough with these problems when testing #1888 in my development setup that I had to fix them, but since they have nothing to do with dark mode support, I've split them out into their own PR.