filter a collection by 'visible' is not respecting proper count of items on paginated page

[glasswork]

{% set posts = page.collection().visible %}

The above declaration of a collection, with the below parameters for display

@self.children Max Count: 10

with the following display code:

{% for child in posts %} --- code to display posts --- {% endfor %}

...should yield 10 posts per page of results, with only visible posts displayed.

However, if the page of results would have had one of the not 'visible' (filtered) items on it, then the results page will only display nine posts, so the count for the posts collection is returning 10 posts per page and just excluding the filtered invisible posts AFTER THE FACT which is throwing off the count.

Shouldn't the filter take only the visible items of the collection and then count them out by tens so that only the visible items are counted?

To test, my reasoning I changed the filter from 'visible' to 'published', like so:

{% set posts = page.collection().published %}

...and changed the not 'visible' pages to not 'published'. After doing so the count is rendered properly with all filtered (unpublished) posts removed prior to the collection count so that ten items display per page. But, of course, the urls for those posts throw a 404 because they are unpublished, so that is not an acceptable workaround.

Any ideas? Let me know if I need to provide more data.

Thanks!

[flaviocopes]

The collection should already contain only published pages.

The problem here I think you're confusing visible with published.

In Grav, visible simply means it's not shown in any menu item (https://learn.getgrav.org/content/headers#visible), but it's still linkable and can be opened by a user, while published means it can't be reached at all.

[glasswork]

The collection should only contain 'visible' pages, you mean.

I am clearly not confusing 'visible' and 'published' - please re-read my post ;) I know what each (visible and published) does, I even mention the difference between the two.

The important line is this:

{% set posts = page.collection().visible %}

What is at issue is the fact that only nine results are returned on a page that would otherwise have displayed a not 'visible' page.

Ignore everything about published.

The results page should always return ten. It should not include not 'visible' pages in the count and then just not display them on the page thus short-changing the count of displayed results.

I hope that makes more sense... ;)

[glasswork]

Replicated this issue on a clean install - first page of returned results for a collection always shows 1 item less than it should if one of the items is set as not 'visible' and you filter the collection by visible.

{% set posts = page.collection().visible %}

The code above SHOULD eliminate the not 'visible' item before the page collection count is made, not afterward.

Thank you in advance for your attention to this matter. It is a critical issue for further development and I appreciate your time and willingness to assist.

[glasswork]

The same happens with {% set posts = page.collection.routable %}

9 items on a results page that would have had a non 'routable' item on it, all other pages return 10.

[glasswork]

What more info do you need? I will gladly supply it to get a fix for this.

[Splode]

I'm having this issue as well. When a page is set to visible: false and published: true and the page collection filters by visible pages, the pagination plugin is including the invisible page in the pagination array.

In other words, if the pagination limit is set to limit: 4 and the first page in the filtered collection is visible: false, the invisible item will not render (expected behavior), but only 3 pagination items will render (unexpected behavior).

[glasswork]

I managed to figure out a work-around for this issue so I am closing it. I'd post the work-around, but it is only of value for my particular use-case. Of course, the original issue remains ...

[tomceek]

I managed to figure out a work-around for this issue so I am closing it. I'd post the work-around, but it is only of value for my particular use-case. Of course, the original issue remains ...

how did you manage to solve this? having the same issue. thanks

[glasswork]

The following assumes that 1) you have a paginated Blog landing page; that 2) you wish to have a featured item (ours takes up two columns and sits at the top of the first results page); and that 3) the remaining items are in rows of dual side-by-side columns. Your needs may vary and so must the specifics of your solution.

Because of a bug in the Paginations plugin (and/or Grav core)---and because I want to display a Blog post as a ‘featured’ piece at the top of the Blog landing page (which pulls it out of its normal page order)---I had to make a number of hacky adjustments to functionality.

The Featured or Hero Post

The ‘featured’ Blog post must be routable and published but not visible.

Under the Advanced tab: Set Visible to Disabled; and Set Routable to Enabled.

Under the Options tab: Set Published to Yes.

I also had to add basic data (Slug) into a field on the Blog landing page so I know which post to include at the top of the Blog landing page. This allows me to call the featured item’s information as page data separate from the page collection data.

Blog Placeholder Post

To compensate for the featured item being pulled out of the collection’s numbering in the pagination plugin, I had to add a placeholder post with the following frontmatter:

title: Placeholder published: true routable: false visible: false

The published value of true is so that the placeholder will be included in the raw count of posts replacing (within the count) the featured item which we removed from the count by making it invisible since we filter the page collection by visible (see code below).

The routable value of false is so that the placeholder will not be available in the raw count of category and tag archive results since the featured item must be re-included in the count due to my filtering by routable (instead of visible) on those pages.

The visible value of false is so that the placeholder will not display on the Blog landing page.

One needs to make sure that, in the Advanced tab, folder number prefixing is disabled for the placeholder post.

This ensures that the placeholder post is always outside the numbering system so that new posts will be added as the last numbered child of the Blog page and then I sort those in descending order so as to display the most recent posts first.

One Final Note

For all of this to work, the placeholder post must be brought into play on the Blog landing page's first results page. This means that on the Blog page the Max Count value has to be an even number sufficiently large to allow that to happen. Therefore, keeping the same featured post for an extended period of time means that the Max Count value has to keep getting larger to accommodate. If one sees that the bottom row of any but the last results page has only one post (rather than two), then this has gotten out of whack and the Max Count value will need to be adjusted.

I must leave it up to you to figure out a specific implementation suited for your needs, for, as was stated, my solution was specific to mine.

I hope that helps.

[tomceek]

Thanks for such detailed instructions and explanation!