docsy icon indicating copy to clipboard operation
docsy copied to clipboard

Main Menu url being re-written incorrectly

Open marshalc opened this issue 1 year ago • 0 comments

Environment

  • [x] Version of Docsy you are using: Docsy 0.10.0 (OUH lightly modified - https://github.com/ouhft/docsy/tree/ouhft)
  • [ ] How are you using Docsy? As a:
    • [x] Hugo module
    • [ ] NPM module
    • [ ] Git submodule
    • [ ] Other:
  • [x] Version of Hugo you are using (output of hugo version): hugo v0.126.1+extended darwin/amd64 BuildDate=2024-05-15T10:42:34Z VendorInfo=brew
  • [ ] OS:
    • [ ] Linux
    • [x] macOS
    • [ ] Windows
    • [ ] Other:

Problem

Discussion to identify this can be found at : https://discourse.gohugo.io/t/main-menu-url-being-re-written-incorrectly/50298

Scenario:

  • Internal Gitlab server, with Pages publishing setup
  • Projects use Hugo+Docsy to build their html documentation output, which the Pages deploy then puts on the internal hosting server
  • There are groups and sub-groups in use[^1]. Gitlab has an algorithm for its URL building that essentially goes: GROUP.internal.domain/PROJECT/ or GROUP.internal.domain/SUB-GROUP/PROJECT/ or GROUP.internal.domain/SUB-GROUP/SUB-SUB-GROUP/PROJECT/, etc
  • Our builds all have i18n turned on[^2], and a default language of en.

Thus, we have a group top-level project that produces output for GROUP.internal.domain/, and a menu link defined in config for a project in a subgroup, i.e. at GROUP.internal.domain/SUB-GROUP/PROJECT/.

When you visit GROUP.internal.domain/ it redirects to GROUP.internal.domain/en/ and similarly GROUP.internal.domain/SUB-GROUP/PROJECT/ redirects to GROUP.internal.domain/SUB-GROUP/PROJECT/en/ - this is all good and as expected.

However, the menu link in hugo.yaml for the top level project is defined as:

# hugo.yaml -- Base config
baseURL: https://epr.internal.domain/

# snip...

menus:
  main:
    - identifier: all-projects
      name: All Projects
      weight: 1000
      url: https://www.internal.domain/
    - identifier: mpages-build
      name: MPages
      weight: 800
      url: https://epr.internal.domain/mpages/build/

Where epr and www are top level groups, mpages is a subgroup of epr, and build is the name of the project in the mpages subgroup.

Unfortunately, whilst we’ve put an explicit FQDN for the mpages-build entry, that is being rewritten in the output to a relative url of:

      <li class="nav-item">
        <a class="nav-link" href="/en/mpages/build/" target="_blank" rel="noopener"><span>MPages</span></a>
      </li>
      <li class="nav-item">
        <a class="nav-link" href="https://www.internal.domain/" target="_blank" rel="noopener"><span>All Projects</span></a>
      </li>

Clicking the MPages link then takes you (as expected) to https://epr.internal.domain/en/mpages/build/, which doesn’t exist so 404’s (it obviously should be ending up at https://epr.internal.domain/mpages/build/en/)

I can see that it’s doing a basic find/replace of the base url here, but in this instance, I don’t want that to happen - and I can't see how to avoid that occurring. I.e. I'm being explicit about what I want in the menu, and the Docsy template is applying some baseURL logic that incorrectly substitutes that.

Thanks to another developer, it looks like this is a problem within https://github.com/google/docsy/blob/main/layouts/partials/navbar.html

I'm not sure what the correct logic here could or should be (and I suspect there may be a processing impact if checking for whether the url links to an internal page or not), so I don't have a recommendation on a fix. The brute force approach might be to suggest that all URLs should maintain their FQDN+Path and not be relative.

Help please.

[^1]: New recent use of sub-groups led to this issue being discovered as till then, all published sites had been projects within the top group level only. [^2]: Whilst we currently only have English outputs, this choice was to support future plans

marshalc avatar Jun 20 '24 08:06 marshalc