2-stage selector not working as expected [SOLVED]

[MarkE]

I know this seems fairly basic, but I'm a bit stumped. I have a Selector field that returns something like "template=198" in response to the user selecting a template (i.e. it returns the id, not the name). Another field on the same page selects a parent page, say "parent=20940". If I use $pages->find("parent=20940, template=198") then the correct pages are found. If I do 

$subPages = $pages->find('parent=20940');
d($subPages);
$subPages = $subPages->find('template=198');
d($subPages);

then the second dump is an empty array. This can be fixed by using 'template.id=198' in the second selector. However, at least in my context, it is not really feasible to hack the selector that is returned from the Selector field. I have no idea what the selector might be.

(BTW, the context, in case it is relevant, is that I am iterating the selector test down the page tree, starting at the parent page's children and stopping at the first level that finds a match).

Any ideas?

[adrian]

I think you've just come across another one of those cases where in-memory selectors don't match DB ones 😖

[MarkE]

12 hours ago, adrian said:

another one of those cases where in-memory selectors don't match DB ones

AKA 'bugs'? Are these documented somewhere. I'm wondering if it is possible to apply a sanitizer hook to fix them.

[szabesz]

1 minute ago, MarkE said:

AKA 'bugs'?

Not a bug but rather the result of the two evolving separately without being designed to be "equal" from the beginning. One afterthought followed the other. We must live with it.

[MarkE]

3 minutes ago, szabesz said:

We must live with it.

Any idea how, in my context?

[szabesz]

13 hours ago, MarkE said:

This can be fixed by using 'template.id=198' in the second selector.

What stops you from using that? I must be missing the point, I guess...

[MarkE]

8 hours ago, szabesz said:

I must be missing the point, I guess...

See my post re the context

22 hours ago, MarkE said:

However, at least in my context, it is not really feasible to hack the selector that is returned from the Selector field. I have no idea what the selector might be.

(BTW, the context, in case it is relevant, is that I am iterating the selector test down the page tree, starting at the parent page's children and stopping at the first level that finds a match).

Now that I know the cause, my solution is to build a selector that always operates on the DB, by merging the user's selector with the one that was used to generate the Page Array:

	/**
	 * Find the first generation of children that matches the given selector.
	 *
	 * This method traverses the children of the given parent page, generation by generation,
	 * and returns the matches in first generation that has matches for the provided selector.
	 *
	 * @param Page $parentPage The parent page whose children are to be searched.
	 * @param string $selector The selector to match against the children.
	 * @return PageArray Returns a PageArray of the first generation that has matches, or an empty PageArray if no matches are found.
	 */
	public function findFirstMatchingGeneration(Page $parentPage, string $selector) {
		$currentGeneration = $parentPage->children();
		$count = 1;
		while($currentGeneration->count()) {
			$currentSelector = $currentGeneration->getSelectors(true);
			$matching = $this->pages()->find("$currentSelector, $selector");
			if($matching->count()) {
				return $matching; // Return the first generation that has matches
			}
			// Move to the next generation
			$nextGeneration = new PageArray();
			foreach($currentGeneration as $child) {
				$nextGeneration->add($child->children());
			}
			$count += 1;
			$currentGeneration = $nextGeneration;
		}
		return new PageArray(); // Return an empty PageArray if no matches are found
	}