Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Main Menu url being re-written incorrectly #2043

Open
4 of 12 tasks
marshalc opened this issue Jun 20, 2024 · 0 comments
Open
4 of 12 tasks

Main Menu url being re-written incorrectly #2043

marshalc opened this issue Jun 20, 2024 · 0 comments
Labels
bug Something isn't working needs-triage

Comments

@marshalc
Copy link

Environment

  • 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:
    • Hugo module
    • NPM module
    • Git submodule
    • Other:
  • 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
    • 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 use1. 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 on2, 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.

Footnotes

  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 marshalc added bug Something isn't working needs-triage labels Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage
Projects
None yet
Development

No branches or pull requests

1 participant