cuelang.org: Hugo client-side redirects don't work for pages that have sub-pages

jpluscplusm commented 5 months ago

What page were you looking at?

https://alpha.cuelang.org/docs/tour/

What version of the site were you looking at?

https://github.com/cue-lang/cuelang.org/commit/e64dd477a75a056c3ef853b722c56c05d82021e1

What did you do?

I tried to use Hugo/client-side redirects to push users from /foo/bar/ to /foo/bar/baz/, but they didn't work.

Background

In https://github.com/cue-lang/cuelang.org/commit/e64dd477a75a056c3ef853b722c56c05d82021e1 we established a better UX across the tour's sections, by establishing 2 chained redirects in this flow:

/docs/tour/basics/folding-structs/'s "Next" lozenge loads ..
/docs/tour/basics/next/, which is a Hugo/client-side redirect to the next section of the tour ...
/docs/tour/types/, which is a Netlify redirect to the "Types and Values" section's first content page,
/docs/tour/types/types/, which contains content.

The client-side redirects have some slight SEO disadvantages, but shouldn't significantly impact the search performance of the site as they're only pointers and don't contain content. I believe we should prefer them as they're visible to authors inside the content/ tree, as opposed to being hidden away inside netlify.toml/.cue.

The less visible Netlify redirects are needed because the technique that redirects /next/ requests (in the above chain) doesn't work when the page being redirected from is a page that has sub-pages. Which is the case for every /docs/tour/foo/ to /docs/tour/foo/first-page/ redirect.

What did you expect?

I expected to be able to use https://github.com/cue-lang/cuelang.org/tree/alpha/hugo/layouts/redirect to redirect a page to a sub-page of itself.

What did you see instead?

The redirection logic simply didn't activate, showing a page indexing its sub-pages.

myitcv commented 4 months ago

Is this still having an impact for the launched site? i.e. how important is this to fix?

jpluscplusm commented 4 months ago

Is this still having an impact for the launched site?

We have redirects split across Netlify and Hugo, with different levels of visibility into those redirections, for authors.

There's no active problem, right now, but I can definitely see it biting someone who doesn't know that we have two, disjoint, sources of truth for which page a reader ends up seeing.

This issue is a blocker to achieving a single source of truth - regardless of it they're encoded as Netlify/server-side or Hugo/client-side redirects.

cue-lang / cue