repeater.count only works after pagesave

[BernhardBaumrock]

Short description of the issue

selectors like this fail if the page was never saved manually:
$pages->find('repeater.count>0');

Expected behavior

it should return all pages with at least one repeater item

Actual behavior

it returns only pages that where saved MANUALLY. pages that where populated via the API (setAndSave) or even saved via the API ($page->save()) will not appear on that selector.

Optional: Screenshots/Links that demonstrate the issue

https://processwire.com/talk/topic/17549-is-this-a-wrong-selector-or-bug/?do=findComment&comment=154214

Steps to reproduce the issue

1. create a page with a repeater field
2. create a new page and populate this repeater via the api
3. do a $pages->find('repeater.count>0')->each('path');

it will only return manually saved pages.

[adrianbj]

Any chance this is connected to this: #36 - the whole 2048 vs 2049 thing? What is the status of those items when saved via the API?

[BernhardBaumrock]

hi adrian, i don't think so:

is this code enough to verify it is not related or should i try something else?

[adrianbj]

Hey @BernhardBaumrock - I am not certain - I have a feeling that if it is connected, the selector might exclude them from the results before you even get to your status check.

Can you take a look at the repeater pages in the PW database and see if they have 2048 or 2049 and manually change one temporarily to see if it helps?

I might be totally off-base here - just a thought.

[BernhardBaumrock]

the selector uses my quickfix with a regular integer field populated via a saveready hook. so it definitely returns all feedback pages and loops through all repeater items.

it still returns only the 3 manually saved pages

[BernhardBaumrock]

another one to make it clearer:

[ryancramerdesign]

What is the code being used to add and save the repeater items? The count wouldn't be known by the page containing the repeater unless/until the $page containing the repeater knows about the addition, and that $page (again, the one containing the repeater) is saved. Or at least the repeater field on it is saved (setField, setAndSave, etc.).

[BernhardBaumrock]

@ryancramerdesign thank you, I was indeed using a slightly different code than you show in the docs. But please see my new post here: https://processwire.com/talk/topic/17549-is-this-a-wrong-selector-or-bug/?do=findComment&comment=165944

What do you think about that behaviour? Isn't it at least strange? Shouldn't it also work with my version of code?

Thanks

[netcarver]

@ryancramerdesign Bumping for your consideration.

[ryancramerdesign]

@BernhardBaumrock @netcarver I don't know the answer on this, but can tell you a little more about that count property. It is populated by the FieldtypeRepeater::sleepValue() method and is a literal DB column in the repeater table, rather than a dynamic count as used by PageFinder for counting multi-value fields. The count column in the repeater table contains the count of non-hidden, non-unpublished pages in the repeater that have already been saved (i.e. already have an id). So if you are getting an incorrect count using one method and not another, then it means either the page(s) added to the repeater were added to a clone of the actual value, or that the pages might be hidden or unpublished. I don't know what might be the case here, but from the linked thread it sounds like you've found a method that works in your scenario.

[BernhardBaumrock]

Thx @ryancramerdesign,
I read the thread again and think robin is right with the variable assignment explanation.