Open kusma opened 4 years ago
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
I'm still seeing this:
$ hugo version
hugo v0.89.2-63E3A5EB+extended windows/amd64 BuildDate=2021-11-08T15:22:24Z VendorInfo=gohugoio
I'm not sure I follow the code entirely, but it looks like before 14227351f, this was kinda just an artifact of the logic, whereas after it seems very intentional. So maybe I'm having some unreasonable expectations here. I guess ugly URLs isn't intended for this use-case, just to render non-index pages with a different scheme.
But I would really like to be able to support my use-case. So what would be the right way of doing that? It kinda seems like adding yet another boolean option isn't the best plan...
I'm experiencing the same issue, also in the context of using GitLab and exposing job artifacts.
My workaround solution is to check hugo environment in templates and append index.html
for non-production builds
{{- with .Site.Home -}}
<li>
{{- $suffix := cond hugo.IsProduction "" "index.html" -}}
<a class="item{{ if $currentPage.IsHome}} active {{ end }}" href="{{ .RelPermalink }}{{ $suffix }}">
{{ .Title }}
</a>
</li>
{{- end -}}
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master
branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.
This is still relevant, nothing has changed. Please drop the "stale"-tag.
Any update?
Issue #11878 may describe a partial work-around for this problem, but I wouldn't trust it.
I spent about 90 minutes diving into Hugo's source, and I think the problem lies in function page.CreateTargetPaths
. The code flow is rather tricky to follow, but I found that adding:
if isUgly && link == slash {
link = pagePath
}
after line 315 fixes the problem with manual testin. The tests in page_paths_test.go
break. Fixing the tests proves difficult (and I don't have adequate time). Part of this reason for this is the multi-layer logic of wrapped loops in the table test definitions (cf. Testing on the Toilet: Data Driven Traps).
I suspect the tests could be made more maintainable by:
Inlining the test data expectations instead of having test.d
computed/manipulated with the net effect being:
for _, test := range []struct{
scen ScenarioState // It seems like there is ancillary state used to power the test (unclear what purpose it serves).
in Input
out Output
}{
...
}{
env := setup(test.scen) // Use env to do whatever needs to happen to test.in (if anything)
out := CreateTargetPaths(test.in)
if diff := cmp.Diff(test.out, out); diff != "" {
t.Errorf("CreateTargetPaths(%v) = %v, want %v\ndiff (-want, +got):\n%v", test.in, out, test.out, diff)
}
}
The amount of inline data in the table test definition would grow significantly, but I reckon literal data is easier to manage and follow than computed/derived test data. The cmp
API is rather extensible and can allow for unnecessary
data in the page.TargetPaths
output to be filtered in the table tests.
Trying to offer the above as a constructive comment to help simplify the stack than lodge a broader critique on a system's legibility. :-)
I'd be curious about the maintainers' opinions. This is just a guess, and I imagine that the real fix is a lot simpler and more targeted, but it seems that page.CreateTargetPaths
is the code responsible for the link target per my debugging.
Hello I have a related issue with the language selector https://github.com/orgs/hbstack/discussions/57#discussioncomment-9488895
When using ugly-URLs, links to the homepage render as "/" instead of the expected "/index.html". This causes problems when trying to host Hugo sites on hosts that disable
DirectoryIndex
. In my particular use-case, it's when I use the gitlab "exposed artifact"-feature to preview website changes for mesa3d.org.What version of Hugo are you using (
hugo version
)?Does this issue reproduce with the latest release?
Yes