Selector problems

[apeisa]

Shouldn't these two API queries return same pageArray?

foreach($pages->get("/")->find("limit=6, template=post, sort=-created") as $post)

and...

foreach($pages->find("limit=6, template=post, sort=-created") as $post)

Now the first one returns only one result, and it's not even latest post, it is (I think) neares result in pagetree.

Using 2.1

My intention is not get("/") but get("/some/page/deeper/")->find..., but I think this is easier to debug (if there is an error) this way.

[ryan]

Those two should return the same thing, except that the first example wouldn't include the homepage (if that was part of your results).

I'm testing the same thing locally, but getting the expected result -- same pages are returned from both.

Hard to tell what might be the problem. What are the results from the second call?

Getting different results from the get("/")->find(...) could mean something is amiss in the pages_parents table and point to a bug somewhere. PW manages this pages_parents table as a way to execute finds within a specific part of the tree. To test if there might be a problem with the table, you can force PW to rebuild it by doing this trick:

$home = $pages->get("/"); 
$home->trackChange('template'); 
$home->forceSaveParents = true; 
$home->save(); 

Then try the two find operations again. Is there any change?

[apeisa]

Yep, that fixed it! (well, needed to put $home->setOutputFormatting(false) also to get that snippet working- just mentioned here for reference).

I have created many templates, fields, pages etc.. so difficult to say when this has occured...

[ryan]

It sounds like there must be a bug somewhere if the table was incorrect in the first place. That helps to know that the rebuild fixed it. The only place this table gets populated is in the Pages::saveParents() private function, and that function is only called by the Pages::save() in certain conditions. Meaning, if there's a bug, it's probably confined to the logic in a few lines of code, which should make it relatively easy to fix. The only thing that makes it difficult is that this has not turned up before, so it may be something that only occurs under rare conditions. I'm going to take a closer look at this and see what I can find. If you encounter the Page::find() producing incorrect results again, please let me know, and I'm going to try and duplicate here too.

Thanks,

Ryan

[apeisa]

This happened to me again. There were some template changes and moving pages around and after that lot's of confusion why my selector didn't work as expected. Running this fixed it. Running on almost latest version of P21.

[ryan]

Thanks for letting me know. I'm thinking it has to do with moving pages rather than template changes. The reason is that template changes force the entire thing to rebuild (which is what running that code snippet does). Whereas moving pages attempts to just rebuild the affected page(s).  I am going to experiment further and attempt to duplicate. Was the selector that was failing the same one you posted before or different?

Thanks,

Ryan

[apeisa]

Selector was this:

$page->find("template=gallery, gallery_images>0 limit=4, sort=-created");

And it was run on page which had two children (neither of those were galleries, but gallery-categories). Something like this:

$page

--> category1

------> imagegallery (found)

------> imagegallery2 (found)

--> category2

------> imagegallery3 (not found)

And if I remember correctly imagegallery3 was the one which was moved from category1 to category2.

[ryan]

Thanks, this is a really helpful example and well explained. I'm going to attempt to duplicate the same scenario here, and have a feeling this will lead to a fix.

[ryan]

I duplicated the tree you setup, and I was able to reproduce it. Thank you for your testing here. I found that the first child of a parent wasn't triggering population of the pages_parents table, which is what the Page::find() operation uses. That explains why the pages in category1 were being found but not the page in category2. Hopefully this is now fixed in the latest commit.

Thanks,

Ryan