Link hook has no context to current page

[christianlupus]

I have a homepage that I want to customize with render hooks for a certain section. I created the corresponding folder layouts/glossary/_markup/ and a file render-link.html inside. According to the documentation (or at least my understanding of it), in the render hook, I should have access to .Page that points to the page containing the link.

If you put a (debug) script in the render-link.html file containing

The page is {{ .Page }}.

and create a link in the section (glossary in my case), you will see, that .Page is the page object of the pointed-to page.

So, either one should be done in my opinion

1. Fix the behavior to have access to the current page where the link is actually output
2. Update the docs to reflect the fact that the .Page refers to the page that the link points to

Personally, I think it would be useful to have access to the local page, I see benefits for both solutions.

What version of Hugo are you using (hugo version)?

I use the NPM package [email protected].

$ hugo version
hugo v0.134.3-5fb333b9f5ff4ec018f9d78910177d0bec1befb0+extended linux/amd64 BuildDate=2024-09-19T14:28:20Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

This is the latest version I can find on NPM and the latest version here on GitHub. I have not build hugo from scratch to test on master.

[bep]

I should have access to .Page that points to the page containing the link.

That's is how it works. I'm guessing a little, but what I think you mean is that if you do something like this in the homepage template:

{{ range site.RegularPages }}
   {{ .Content }} // the page you as .Page in the render hooks for .Content is "." (e.g. `/posts/page1`) and not $ (the home page)
{{ end }}

You expect the .Content in the range loop to get the home page in the hooks.

Does the above describe the problem?

[christianlupus]

You are right. I wasn't aware of that myself but by .Content, I seem to switch context to the subpage (e.g. /posts/post1). In that sense, the implementation seems working correctly.

In fact, I needed $.RelPermalink or $.Permalink (having $ defined as you as the page /posts). I could circumvent this by just using the local anchor which worked for me in this case. You are free to close this as it is no bug in fact. Nevertheless I would be very pleased if you could hint me on how I can transport the value $ into the render hook.

[bep]

I would be very pleased if you could hint me on how I can transport the value $ into the render hook.

We recently added support for what I called "scoped content rendering", which should support what you want. We haven't found time to complete the documentation, yet:

• Document Page.Markup hugoDocs#2669
• https://github.com/gohugoio/hugo/releases/tag/v0.134.0

There are some things that's important to understand:

• You can access the top level $ page with the global page.
• You can also pass data downwards in site.Home.Store or $.Store etc.
• The output of .Content gets cached so page and the Store data may not be what you'd expect.

But with the new scoped content feature you can recursively create a variant for e.g. the home page:

{{ range site.RegularPages | first 20 }}
  {{ with .Markup "home" }}
    {{ .Render.Content }}
  {{ end }}
{{ end }}

In the above example (given that the named scope is only used on the home page), you can be certain that page == home (also in render hooks) and that any data you pass down in $.Store e.g. is what you'd expect.

I'll close this now, I suggest you take further questions at https://discourse.gohugo.io/

[bep]

In fact, I needed $.RelPermalink or $.Permalink (having $ defined as you as the page /posts).

I'm not totally sure what's your requirements, but I think Hugo's internal link hook template provides a good compromise for link resolution:

https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/_default/_markup/render-link.html

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.