edu
edu copied to clipboard
Fix nav buttons
Type of change
Bug fix
What should this PR do?
This PR rewrites the site navigation Instead of going to random pages, it creates a depth-first run of the site (up to five levels) to collate all sections in order, extracts relevant pages from each section, creates a master listed page collection in order of weight, then moves the user along site using that flattened collection.
One detail here is that the implementation will go through all "regular" pages on a level, then go down or forward (in the tree) to the next section. This does make a difference, as in a few places we have a section nested in the middle of another section, but I think it works fine as a previous/next implementation.
Why are we making this change?
The previous and next buttons have a functionally random behavior on the current version of the site.
What are the acceptance criteria?
We should check that this solution doesn't break anything. In terms of behavior, it can only be an improvement to the previous and next buttons, but we also don't want anything else to get affected on the site.
How should this PR be tested?
Try out the behavior of the previous and next buttons. They should (mostly) line up with the left sidebar, and I used a similar approach to the sidebar code (depth-first to five levels). The overview page is the first page and should only have a next button. I think the video on sigstore is the last page. Unlisted pages should not appear.
Notes
I just want to complain about how Hugo handles stuff. The previous and next logic is reversed (why?) and their previous and next method implementation is incredibly naive.
Resolves #860