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 }}
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.
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.
@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”?
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.