Prev and Next links on subpages

I have a site than has a series of second level pages, some of which have up to 20 third level pages linked from them. To save the user going back to the drop down menu and navigating down to the next sub-sub-page, I would like to have "Prev" and "Next" links down in the footer. I've done this previously in PHP with WolfCMS and several others over the years.

Grav seems to have the functionality built in, with isFirst, prevSibling, etc but I can't get it working. My code looks like:

{% if not page.isFirst %}
   <span class="navprev"><a href="{{ page.prevSibling.url }}">Prev</a>
{% endif %}

The code does not display anything. Yes, I've tried it on pages which are not the first page. The Next code is also in the footer twig and has exactly the same problem.

I've also tried page.isFirst and self.page.isFirst. These always display Prev, but the URL is always for the current page. The corresponding Next functions work identically, including returning the current page.

Can anyone show me what I'm doing wrong?

Thanks, glen.

Slight correction: xyz.url does not return the current page's URL, it returns nothing.

Typically the blog_item.html.twig of the antimatter theme give you all the details of how to add a "prev/next" navigation bar.

In order to make it work, your page must belong to a page collection. Please check whether this is the case (the parent page must have a content entry in the YAML header).

OK, I've made the parent a collection with it members being all it's children and that's made the sibling functions work.

Why is this required? My pages are ordered, I went to some trouble to make sure they were so the menu would display in order correctly. Why are the sibling function ignoring my ordering and making me create a completely separate ordering?

Oh, forgot the most important bit: Thank you, your suggestion worked.

Hi @lgftsa, you're welcome :-D ! You need to setup a parent collection page because otherwise Grav does not know how to order things. When Grav runs it looks for such collections, write them to a global configuration file and uses this to avoid filesystem access as far as possible (at the end performance matters).