GetPage with a custom permalink as the argument

support
1

I am trying to use the link render hook, specifically this nice implementation. It works great for the most part, very useful stuff, but it stumbles upon links that don’t follow the folder structure inside content.

I might be not phrasing that in correct terms, so here’s an example minimal project, just in case.

The content folder structure is:

./content/
├── about
│   └── index.md
└── posts
    ├── my-first-post
    │   └── index.md
    └── my-second-post
        └── index.md

The permalinks format in the config is:

[permalinks]
    posts = "/posts/:year/:month/:day/:filename/"

And here comes the problem. In this Markdown source of an article:

Testing links:

- matches the `content` folder structure: [/posts/my-first-post](/posts/my-first-post)
- matches the custom `permalinks` structure: [/posts/2024/11/07/my-first-post](/posts/2024/11/07/my-first-post)

both links are rendered with a correct href value, so I can click on any of them, and the correct page will open. But the link render hook will print a warning/error for the second link:

WARN  The link render hook was unable to resolve the destination "/posts/2024/11/07/my-first-post" in posts/my-second-post/index.md

and also that link’s <a> element will get appended with broken CSS class (in development environment):

So I figured I need to extend the link render hook code, as it apparently doesn’t cover a scenario of custom permalinks, but there I encountered a problem that the GetPage call does not find the page if it is passed in a custom permalink format:

/* this one doesn't find it */
site.GetPage "/posts/2024/11/07/my-first-post"

/* and this one does find it, but I need to use the permalink format */
/* site.GetPage "/posts/my-first-post" */

So then my question: is it possible to verify that a linked page exists, using its custom permanent link format, like the one I have in this example? It doesn’t have to be with GetPage, I’ll take any other option that would work inside the link render hook.

2

The .GetPage methods on Site and Page expect the argument to be a logical path.

Also, have you tried Hugo’s embedded link render hook? That feature was implemented long after the article you reference was published.

https://gohugo.io/render-hooks/links/#default

But there’s one importance difference: it does not throw a warning or error if it can’t find the page reference.

3

The .GetPage methods […] expect […] logical path

I suspected as much. So then are there any other ways aside from .GetPage to verify that there is an actual page behind a given permalink (such as /posts/2024/11/07/my-first-post)?

https://gohugo.io/render-hooks/links/#default

I tried enabling that one, but it does not warn/error even about clearly broken links like /posts/something-that-does-not-exist. Looking at its source, I reckon it is expected that one is supposed to extend it with whatever verification logic one desires (as there is none there out of the box), but that brings me back to the problem of verifying the page existence based on its permalink (hence the topic/thread name).

it does not throw a warning or error if it can’t find the page reference

Yeah, that is the whole point why I started looking at render hooks in the first place :slight_smile:

I’d like to see warnings/errors in Hugo output about broken links, and I really liked the idea of appending broken CSS class to them in preview, so your hook that I referenced in the beginning is almost the thing that I was after.

1 Like
4

Not that I can think of.

As I am sure you know, a page’s permalink and relative permalink are affected by …

  • front matter
    • slug
    • url
  • site configuration
    • baseURL (with and without a subdirectory)
    • canonifyURLs (don’t use, see docs)
    • defaultContentLanguageInSubdir
    • disablePathToLower
    • permalinks
    • relativeURLs (don’t use, see docs)
    • removePathAccents
    • uglyURLs
  • language

…and probably some other stuff that I’m not thinking about.

You can get from a page reference to a permalink or relative permalink, but you can’t go the other direction. At least not cleanly that takes all of the above into account.

1 Like