uglyURLs - Permalink and RelPermalink of home page not ugly

[kusma]

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)?

$ hugo version 
Hugo Static Site Generator v0.68.3/extended linux/amd64 BuildDate: 2020-03-25T06:15:45Z

Does this issue reproduce with the latest release?

Yes

[stale[bot]]

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.

[kusma]

I'm still seeing this:

$ hugo version
hugo v0.89.2-63E3A5EB+extended windows/amd64 BuildDate=2021-11-08T15:22:24Z VendorInfo=gohugoio

[kusma]

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...

[dvdksn]

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 -}}

[github-actions[bot]]

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.

[kusma]

This is still relevant, nothing has changed. Please drop the "stale"-tag.

[chuanhhoang]

Any update?

[matttproud]

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:

1. Splitting the table tests into two: one for ugly URLs and one for not

2. 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.

[wd400]

Hello I have a related issue with the language selector https://github.com/orgs/hbstack/discussions/57#discussioncomment-9488895