Issue with has_parent selector

[Sinmok]

Hello,

I'm having trouble with a has_parent selector..which seems to work..only sometimes.

I've got a page tree like so (ids are made up for demo purposes)

Home
    Page 1 (id = 1050)
        sub 1
        sub 2
   Page 2 (id = 1080)
        sub 3
        sub 4
   Page 3  (id = 1090)
        sub 5
            sub 6
                 sub 7
            sub 8
                  sub 9

The really weird thing is that the same selector with different page id returns something unexpected..despite the only change being the page id

 

for example, i'm getting

$result = $pages->find("has_parent=1050") //returns a page array of 2 pages

$result = $pages->find("has_parent=1080") // returns an empty page array (WHY?!)

$result = $pages->find("has_parent=1090") //returns a page array of 5 pages

is there anything that could be causing the selector for page id 1080 to return nothing? the templates, access control and all that are all exactly the same

Are there any other known variables that might affect the result of a 

has_page

 selector?

I'm using ProcessWire 2.3.0

Edit: Basically, all I need is a PageArray of all descendants of a given page - do you know of another way of doing this?

[horst]

Have you double checked that the ids of your pages are correct?

$ids = array(1050, 1080, 1090);

foreach($ids as $id) {
    $parent = $pages->get($id);
    if (0 < $parent->id) {
        // page is found, lets call the selector
        $result = $pages->find("has_parent=" . $parent);
        echo "<p>found {$result->count} pages</p>";
    } else {
        echo "<p>wrong ID for parent!</p>";
    }
}

[Sinmok]

I am absolutely sure they are the correct page ids.

$p = $pages->get(1080) // returns the page i want

$result = $pages->find("has_parent=$p") // still empty

and produced the same result..

[horst]

ok, then add a "include=all" to the selector, just to be sure that there are no pages get excluded because of restrictions!

$result = $pages->find("has_parent=$p, include=all");

[Sinmok]

No luck

[Sinmok]

Also worth noting that the following does not work either:

$p = $pages->get(1080) // returns the page I wanted

$r = $p->find("") //returns empty..

//as does

$r = $p->find("id>0") //also returns empty

however

$p->children //DOES return a page array

This DOES work on other pages that has children. Whaaa

[Soma]

You have moved those pages around from amother parent? Move those out of the parent and then back in. Works?

[Sinmok]

Wow, that worked.

What causes this? Is there any way to prevent it / workaround?

[Soma]

It a bug known since a long time, but Ryan can't reproduce it. I got caught by it years ago, and recently it happened to 3 other people. Can you tell what you did to those pages? Move around, clone?

https://github.com/ryancramerdesign/ProcessWire/issues/404

[Sinmok]

A client made the pages, so I can't be 100% certain but they do like using their page-clone tools so it is highly likely it has something to do with it.

[Soma]

What PW version?

That's why I'm not using clone tool. But see others using it all the time. This bug is not something you'll recognize unless you use has_parent, and I think there's lots of PW sites where this happens and nobody recognized it yet. It's that the parents table is broken for those. It's annoying cause once you stumble over it you have no idea whats happening, or you don't even will ever notice that some pages may not get returned.

[Sinmok]

The version was 2.3.0, I don't know if it affects newer versions.

This has most certainly affected other projects because I remember asking questions and being told has_parent was the answer, but no matter what I did, has_parent just wouldn't work. That project was using a lot of cloned pages, too..

I won't be using Page cloning any more as a safety pre-caution until we can get verification!

[Soma]

2.3 is very old and surely there's bugs, but not sure it's fixed completely and it really has to do with clone tool. There was a attempt to fix issue with it, but I got a coworker running into it where this fix was in place already so it's a mistery.

[harmvandeven]

Hi everybody, I'm very glad I found this topic, thank you Soma for your answer. It worked like a charm.

I did run into the issue myself (while using version 2.5.3), my actions where the following:

I've cloned a page (including it's children), the page itself was found in it's parent but it's children weren't.

Example:

1001   =    Products

----- 1002   =   T-shirts

----- ------  1003  =  Small

----- ------  1004  =  Medium

----- ------  1005  =  Large

Duplicate *T-shirts* and rename it *Sweaters*

Tree looks like this:

1001   =    Products

----- 1002   =   T-shirts

----- ------  1003  =  Small

----- ------  1004  =  Medium

----- ------  1005  =  Large

----- 1006   =   Sweaters

----- ------  1007  =  Small

----- ------  1008  =  Medium

----- ------  1009  =  Large

find(has_parent=1001) returns:

1001,1002, 1003, 1004, 1005, 1006

The children of 1006 are missing.

I hope Ryan can reproduce the issue this way. 

[valan]

Recently I've met the same issue at 2.6.4.

Looks like a super-critical bug as it compromises PW consistency...

If anybody knows - please share how to fix this. Finding&moving pages to/from is not a solution for db with over 100000 pages... I guess, some kind of repair script should be available. Thanks.

[opalepatrick]

Just for the record, had this just happen on 2.7.2

[LostKobrakai]

The has_parent issues are not 100% fixed for 2.7.3 either. I've a fixer module in my installation, which does fix all the missing pages_parents rows every few hours.

[Jozsef]

On 10/4/2017 at 2:57 PM, LostKobrakai said:

The has_parent issues are not 100% fixed for 2.7.3 either. I've a fixer module in my installation, which does fix all the missing pages_parents rows every few hours.

Hi, I just ran into this issue with 3.0.61. I have has_parent as a sub selector for a page reference field.

$categories = $pages->find("page_field=[has_parent=1234]");

It worked fine and at some point it stopped producing any results. It works if I move it out and do a two step filtering.
The only thing I did was to import more pages via Ryan's Import CSV module.

$parent = $pages->find("has_parent=1234);
$categories = $pages->find("page_field=$parent");

@LostKobrakai, would you mind sharing your module for fixing the parents table?
Thanks

[LostKobrakai]

If it works with pulling the selector out it's a different issue. My problem were literally missing rows in the table, which would make both your examples fail.

[webaff]

Just came across this issue in 3.0.62 and glad to find @Soma's workaround.

Not sure if it's caused by the clone function as the pages are created by a client, but highly possible.

Hope @ryan can fix this soon, maybe with @LostKobrakai's fixer module. Thx.

[Sipho]

I also got this on 3.0.62 and @Soma's fix worked. I can't exactly tell what caused it. In my case has_parent only worked for the direct parent. Anything higher would fail to find anything.

[Autofahrn]

Still seems to happen with 3.0.96. Pages were bulk-imported via API, affects ~2 from more than 1000. Moving the parent page around fixed it.

[Zeka]

Just happend on PW 3.0.163. 

Fixed by rebuildAll method available since 3.0.156

$pages->parents()->rebuildAll();

 

[Orkun]

On 7/26/2020 at 12:59 AM, Zeka said:

Just happend on PW 3.0.163. 

Fixed by rebuildAll method available since 3.0.156

$pages->parents()->rebuildAll();

 

Hi @Zeka

Would it be a good idea to make cronjob which executes this code daily and takes care of that?

Or should i only use it, when I stumble upon anywhere? Or is it enough, when I have used it once?

KR
Orkun

[Zeka]

@Orkun I think that it is enoght to run it once if you have some issues or after update to PW >= 3.0.156. 

https://github.com/processwire/processwire/blob/master/wire/core/PagesParents.php#L485

Save method from PagesParents class executes on every page save and if it's necessary it will execute rebuildAll method.

https://github.com/processwire/processwire/blob/master/wire/core/PagesParents.php#L502