.Next & .Prev based on menu parent and weight?

As far as I understand the .Next and .Prev link to the post that has been published before/after the current post based on the date.

Is there a way to have them point to the next/previous post based on the weight?

I want to use hugo for documentation. so I want the user to be able to click through the pages of a chapter and link to the first page of the next chapter if the user is currently viewing the last page of the current chapter (= the post with the highest weight with the same menu parent)

You need to patch Hugo to do that. See Add in-section Next/Prev section pointers for the pull request that adds the missing feature. After patching, I use weight in my page front matter to set the order. My template then uses it like this:

{{ if .PrevInSection }}
  <a href="{{ .PrevInSection.Permalink }}">Prev</a>
{{ end }}
{{ if and .PrevInSection .NextInSection }} | {{ end }}
{{ if .NextInSection }}
  <a href="{{ .NextInSection.Permalink }}">Next</a>
{{ end }}

Help this helps.

Great news! Steve committed a change to Hugo today that makes .Next and .Prev behave correctly. So, in my previous comment, just remove the “InSection” parts and just use .Next and .Prev. Works great!

It should be a bit different. I’m still working on the documentation but the way it’s designed is you need to pass in the current page and it will respond with the page before and after it in any list you call prev/next on.

It’s something like this: (notice the “.” at the tail of each call that is passing in the current page.

  <a href="{{ .Site.Pages.ByWeight.Prev . }}">Prev</a>
  <a href="{{ .Site.Pages.ByWeight.Next . }}">Next</a>

Yes, some doc is needed here. I have no idea how to use this.

The example does not work … It would had Prev/Next returned Permalink in stead of a Page.

A little surprised, but this works:

<a href="{{ (.Site.Pages.ByWeight.Prev .).Permalink }}">Prev</a>
<a href="{{ (.Site.Pages.ByWeight.Next .).Permalink }}">Next</a>

I spoke too soon. I thought it was limited to the Section, but it’s not. bjornerik is correct about the usage of this new feature.

I do have one issue with this new feature: It’s circular nature is surprising to me. For example, I’d expect Pages[0].Prev to be equal to nil.

I agree with @moorereason … I tried to implement this on my blog (with two sections), but the result ended up more confusing than the “mix of sections” version.

I havent’s looked closely at his implementation, but it makes good sense to have a next/prev inside a section.

So the intent here was to provide a general solution that works everywhere with any kind of ordering, etc.

The problem with an explicit Next/Prev function is that it works in only a single application. There are already over a dozen requests for Next/Prev in different locations.

Now, I’m ok with the explict Next/Prev functions being created for Sections as that’s a very common use case because it’s just easier for the user. It just needs to be put in a logical place with the right documentation around it.

I submitted a sort function as a PR. It might be possibly to have a default partial that can be overwritten if people want to choose their own filtering and sorting options.

Can anyone suggest a workaround for .Prev and .Next within a section according to page weight?

Replied to your other thread, but you can use .NextInSection and .PrevInSection. It currently sorts by Weight, Date, and then Title.

@moorereason Perfect example of me gilding the lily on this one. .NextInSection and .PrevInSection work exactly as I had hoped. And I was fiddling with printf and whole slew of other ideas. I will try to submit a pull request to update this in the documentation when I get out of work tonight. Thanks so much!

By the way, when you say “Weight, Date, and then Title”… do you mean “Weight, PublishDate, and then Title”?

No, I mean Date, as in Node.Date. Page.PublishDate is not considered at this point. Perhaps it should, though.

@moorereason Gotcha. I ask because the following is in the docs:

.NextInSection Pointer to the following content within the same section (based on pub date)

Looking at the code, I’m pretty sure that’s inaccurate. Date and PublishDate are two distinct fields. Can you test and verify? We need to fix the docs.