Closed Heraes-git closed 5 years ago
I have edited the first post, to be more precise in the exposure of the problem. I'm doubting on myself about that ticket. Probably more a technical issue due to embeding pages and how PHP functions are triggered, than a legit bug. I'm trying to find a way to improve the plugin so it can work better in that context (or by adding a function, or by just controlling things correctly in Twig).
Found a workaround by defining my own pagination
and limit
options in the frontmatter, under a personal node.
your_node:
pagination: true
limit: 6
{% if config.plugins.pagination.enabled and page.header.your_node.pagination %}
...
content.pagination
nor content.limit
options, and everything will be fine.I considere this topic closed, given that no modification to the plugin is necessary. 👍
Running Grav (v1.6.16) and Pagination v1.4.2
Problem
pagination:
andlimit:
option triggers the automatic call of the plugin but the pagination fails in both the parent page (in the "module") and in the sub-page's (when reaching its route).limit:
option, pagination fails in the parent page (the "module" doesn't have the pagination at the bottom) but works when reaching the sub-page.Configuration
Page
is a blog. It is intended to display as an embebed module accessible at
/critiques
It has 8 items for now.Frontmatter
(of 01.presse : )
Blog's template
I've integrated the possibility to detect if a collection is defined, and if not, to define one if the page has children. In the first case, the automatic use of the pagination plugin is triggered, and in the second case the
{% do paginate() %}
is used.Also, if a collection is already defined but no
limit:
option is defined, it is supposed to switch to the manual creation of the pagination.Tests performed
The tests I have performed are so numerous that I can't summarize them here. It is difficult for me to express how things are broken. As you can see, my template is pretty clean, excepted the IF / ELSE at the begining for automating some sort of detection.
But based on that config, here what I can say :
do paginate
won't be triggered. The items are limited on the page, but no pagination appears (no arrow, no numbers).do paginate
is executed. Pagination works fine.do paginate
is executed too. No pagination shows, and all the items are displayed.So, as you can see, the problem is we can't define a limit for the pagination in the frontmatter. And that's a big problem, because it completly breaks the possibility to create a website for a customer, and to give him the possibility to define its own settings with an option in the blueprint.
Intuition
The PHP of the plugin may be processing the presence of a frontmatter option differently than when relying on the template
do paginate
injection.That difference could explain the difference of displaying, and the bug.
Facts
collection.params.pagination
returnstrue
when using a frontmatterlimit:
(because the frontmatter's collection isn't defined in the parent page !), instead of returning the whole pagination informations usually used for defining the arrows, the number of pages, etc. So the footer's call of the pagination fails and nothing is displayed.This means that something is broken in the way the plugin automatically build pagination with the frontmatter.It just means that it doesn't work when embeding a page supposed to have a pagination, in an other page.