You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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
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. ↩
Whilst we currently only have English outputs, this choice was to support future plans ↩
The text was updated successfully, but these errors were encountered:
Environment
hugo version
): hugo v0.126.1+extended darwin/amd64 BuildDate=2024-05-15T10:42:34Z VendorInfo=brewProblem
Discussion to identify this can be found at : https://discourse.gohugo.io/t/main-menu-url-being-re-written-incorrectly/50298
Scenario:
GROUP.internal.domain/PROJECT/
orGROUP.internal.domain/SUB-GROUP/PROJECT/
orGROUP.internal.domain/SUB-GROUP/SUB-SUB-GROUP/PROJECT/
, etcen
.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. atGROUP.internal.domain/SUB-GROUP/PROJECT/
.When you visit
GROUP.internal.domain/
it redirects toGROUP.internal.domain/en/
and similarlyGROUP.internal.domain/SUB-GROUP/PROJECT/
redirects toGROUP.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:
Where
epr
andwww
are top level groups,mpages
is a subgroup ofepr
, andbuild
is the name of the project in thempages
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:
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 athttps://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
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. ↩
Whilst we currently only have English outputs, this choice was to support future plans ↩
The text was updated successfully, but these errors were encountered: