PR#266 was closed recently after commit b719ba7. However, the commit doesn’t actually solve the issue of restricting Page.Next/Prev to a Section. The original PR seems to be the simplest solution, but Steve doesn’t like it. So…
I started trying to come up with some ideas for another solution. Based on Steve’s recent commit, I considered this:
That’s a little convoluted. Plus it would probably be a pain to implement: cache and return slice of a subset of Pages? You still can’t use Next/Prev pointers without copying Pages.
Next idea was to toy with .Site.Sections, but it’s a WeightedPages type. I couldn’t come up with a workable solution for this scenario.
Last idea:
(.Section.Pages.ByWeight.Prev .).Permalink
This one I like, but… I think Section would need to promoted to a type which could set off a chain reaction.* Plus you still need to avoid having to duplicate/copy the Page objects so that the Next/Prev pointers could be modified. The ramifications of this change could be major. Are there other reasons to have Site-like features on a Section (like Front Matter)?
Anyone else have any ideas? PR#266 is looking better and better to my simple mind.
* If a Section type implemented the Stringer interface, would the template engine call Section.String() if it sees a lone “.Section” to keep from completely breaking backward compatibility?
This is an old thread, and I’m having trouble figuring out if something like this has been implemented @moorereason since .NextInSection still only seems to apply to .PublishDate. I think the last example is probably the most logical:
(.Section.Pages.ByWeight.Prev).Permalink
If I’m missing something, please disregard. Thanks!
This works fine, but just be aware of the little bit confusing (at least it is for me) part that .Prev is never nil; it just goes round and round. So prev from the first goes to the last …
And getting nada. Also set verbose = true and verboseLog = true in config.toml and this is all I get in the console:
Change detected, rebuilding site
2016-03-05 12:23 -0600
INFO: 2016/03/05 found taxonomies: map[string]string{"tag":"tags"}
0 draft content
0 future content
7 pages created
0 paginator pages created
6 tags created
in 40 ms
INFO: 2016/03/05 File System Event: ["/Users/ryanwatters/Desktop/GitHub/digital-strategy-documentation/layouts/_default/single.html": CHMOD]
I think I get what you’re saying about it never evaluating to nil- it is kind of confusing - but I thought I could work around that with a conditional in the same _default/single.html.
Change detected, rebuilding site
2016-03-05 12:35 -0600
INFO: 2016/03/05 found taxonomies: map[string]string{"tag":"tags"}
ERROR: 2016/03/05 Error while rendering page json/json-index.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page Wrike Project Management/getting-started.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page A to Z Style Guide/abbreviations.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page Digital Writers Guide/introduction.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page A to Z Style Guide/preferred-usage.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page Digital Writers Guide/writing-for-cap-audiences.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
ERROR: 2016/03/05 Error while rendering page A to Z Style Guide/references.md: template: _default/single.html:11:29: executing "_default/single.html" at <.Section.Pages.ByWei...>: can't evaluate field Pages in type string
0 draft content
0 future content
7 pages created
0 paginator pages created
6 tags created
in 36 ms
INFO: 2016/03/05 File System Event: ["/Users/ryanwatters/Desktop/GitHub/digital-strategy-documentation/layouts/_default/single.html": CHMOD]
If this is a bug, happy to report via GH, of course, but I’m assuming I’m thinking I’m missing something. Any suggestions on other workarounds @moorereason?
.Section.Pages will not work because .Section returns a string, which is why you get the error message “can't evaluate field Pages in type string”. My use of that construct in my original post was simply an idea of how we might alter the .Section field to return a Node type (or something), but that proposal was never discussed further nor implemented.
Now, the order of sorting precedence should be Weight, Date, and then Title. Site.Sections is a Taxonomy which is a map of WeightedPages with each section as a map key. WeightedPages is a slice, so each section has a slice of WeightedPages. Sorting of those pages ultimately happens here in hugolib/taxonomy.go.
All that to say that sorting by weight should work within a section.
I’m somewhat frustrated - it seems that the publish-date is the only way to order prev/next links in my sections.
So I’ve found that a useful workaround is to remove the weight from front-matter and put in artificial dates that function as weights. The prev/next links come out link I want them to, but it’s ugly.
