getgrav / grav-plugin-pagination

Grav Pagination Plugin
https://getgrav.org
MIT License
27 stars 20 forks source link

Pagination doesn't work in an embeded page #44

Closed Heraes-git closed 5 years ago

Heraes-git commented 5 years ago

Running Grav (v1.6.16) and Pagination v1.4.2

Problem

Configuration

Page

05.critiques
    01.presse

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 : )

content:
    items: '@self.children'
    pagination: true
    limit: 6
    order:
        by: date
        dir: desc

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.

{# *** Collection preprocessing *** #}
{% if page.collection.count > 0 %}
    {% set collection = page.collection() %}
    {% set limit = page.header.content.limit ?? 6 %}{# Have to use null-coalescing instead of classic ternary, or the plugin bugs ! #}
{% else %}
    {% set limit = '6' %}
    {% set collection_options = { items: {'@page.children': page.url}, 'limit': limit, 'order': {'by': 'date', 'dir': 'desc'}, 'pagination': true } %}
    {% set collection = page.collection(collection_options) %}
{% endif %}
{# *** /Collection preprocessing *** #}

{# *** Manual pagination *** #}
{% if config.plugins.pagination.enabled and collection.params.pagination and not page.header.content.limit %}
    {% do paginate(collection, limit) %}
{% endif %}
{# *** /Manual pagination *** #}

{% for item in collection %}
    ... Display of the items...
{% endfor %}

<div class="footer">
    {% if config.plugins.pagination.enabled and collection.params.pagination %}
        {% include "#{DNA_conf.partials}/pagination.html.twig" with {'base_url':page.url, 'pagination':collection.params.pagination} %}
    {% endif %}
    {% if config.plugins.taxonomylist.enabled %}
        {# include "#{DNA_conf.partials}/taxonomy_list.html.twig" with {'base_url':page.url, 'taxonomy':'tag', 'children_only':false} #}
        {% include "#{DNA_conf.partials}/taxonomy_list.html.twig" with {'base_url':"/critiques", 'taxonomy':'tag', 'children_only':false} %}
    {% endif %}
</div>

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 :

  1. If I set a paginate / limit in the frontmatter, the collection is detected, the limit variable is created but isn't used because the do paginate won't be triggered. The items are limited on the page, but no pagination appears (no arrow, no numbers).
  2. If use a paginate option but no limit, the collection is detected, a default limit variable is set, and the do paginate is executed. Pagination works fine.
  3. If don't set any pagination nor limit in the frontmatter, the automatic collection creation is realized, and the 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 returns true when using a frontmatter limit: (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.

Heraes-git commented 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).

Heraes-git commented 5 years ago

Found a workaround by defining my own pagination and limit options in the frontmatter, under a personal node.

Workaround

  1. When creating pages manually, or in your blueprint, define a
    your_node:
    pagination: true
    limit: 6
  2. In your Twig, control the presence of the node :
    {% if config.plugins.pagination.enabled and page.header.your_node.pagination %}
    ...
  3. Never use the normal 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. 👍