Page Autocomplete selector string within a repeater with dependencies

[Kiwi Chris]

I'm trying to get a page reference field inside a repeater working with autocomplete with dependencies on other repeater fields.

I'm using the Selector String option to configure page autocomplete.

Currently I have: 

template=moveStockItem, productVintage=page.vintage.title, sort=page.vintage.title, clientCode%=page.createdUser.clientCode

page.vintage.title returns nothing, as it's a field on the repeater, not a field on the page the repeater is in.

[MarkE]

Does this help? https://github.com/MetaTunes/CustomDependSelects
 

[da²]

@Kiwi Chris

Try this:

productVintage.id=page.vintage.id

or:

productVintage=page.vintage

 

If you search by title, it would be:

productVintage.title=page.vintage.title

But I don't see any reason to search by title instead of id.

Edited August 17 by da²

[Kiwi Chris]

23 hours ago, MarkE said:

Does this help? https://github.com/MetaTunes/CustomDependSelects
 

Does this work with autocomplete? The examples look like they're using a standard select list. I can already do this via a hook in ready.php, but I've specifically been asked to provide autocomplete rather than select lists, and the code that works for select lists does not work with InputfieldPageAutocomplete.

[Kiwi Chris]

I've found this thread: 

Apparently I need to use item. rather than page. to refer to a field within the repeater field. Looks like the inline documentation needs some improvement.

Still haven't got it working, but think I'm heading in the right direction.

The problem I'm getting is in Tracey Debugger, I can see that the selector query is not getting any value for either page.vintage.title or item.vintage.title, it's just blank.

 

 

 

[da²]

@Kiwi Chris Yes, page.vintage refers to the property vintage on the current page. I thought it was your goal, but I missed you are trying to reference item fields in repeater.

If I understand good, in your page you have a page reference field with the selector string, and this field must reference the pages that are set in a repeater on the same page?
Or is the page reference field inside the repeater too? ?

Edited August 18 by da²

[da²]

I had a look at it, I remember trying to do the same with an autocomplete field except I tried to reference pages from a Profields Table, and never found a correct solution.

What you can do is search for repeater items instead of the pages inside items.

Or hooking into ProcessPageSearch::findReady to update selector, but it's not clean, I think only solution is to add "id=xxx|xxx|xxx|xxx|xxx|xxx|...." in selector. ? 
Or maybe hooking into ProcessPageSearch::executeFor and doing your own search.

For the hooks you need to know on what page you are, I don't know how.
EDIT: Except with a ugly hack, like adding in selector string "name=page.id", and so in ProcessPageSearch::executeFor you can get the page id with $event->return, do a search directly in repeater (like this) and finally format and return results.

 

Edited August 18 by da²

[Kiwi Chris]

What I'm trying to do is restrict a list for a page reference to pages with template of moveStockItem, that are pulled in from an external API, so I don't have control over the fields in that template, as they just replicate what's in the external API. In that template productVintage is a numeric field, but that's fine, as no one ever edits it manually. 

That's why I need to use a selector that matches productVintage = item.vintage.title, because in the repeater, users do need to select a vintage, and providing a page reference field helps restrict them to a sensible range.

Hooking ProcessPageSearch::findReady seems like an option, but it does seem to be quite messy. 

With a select list it's easy to hook InputfieldPage::getSelectablePages and that works ok, but switching to autocomplete for the page reference field makes things harder.

with autocomplete, I've found using a selector string rather than a hook works fine if the dependency and the dependent fields are on a normal page rather than a repeater, however if both the dependent field and its dependency are in the repeater, that's where things get messy.

In the example I'm trying to get working, this part: clientCode%=page.createdUser.clientCode does work, so I seem to be able to reference a field from the page with the repeater field in it ok. I double checked by adding an additional section to the selector to check that page.id refers to the id of the page the repeater field is on, and not the repeater itself, and it does refer to the parent page, not the repeater.

I've done some further checking, and although in the thread I linked to previously Ryan says that item should refer to fields in the repeater, in this case it is returning the page the repeater is on. 

I'm not sure if this is a bug, or an inherent limitation of using find for the autocomplete option?

[da²]

I've reached the same conclusions when I tried with Profields Table. I use a lot the autocomplete field because the select is not good for hundred of pages.

From what I understand, limitation is on both sides: the find() string selector, and the ProcessPageSearch. Just one needs to be improved to solve this limitation. The easier fix is probably ProcessPageSearch: we need a hookable method to replace results, like the getSelectablePages() of InputfieldPage, and like in other hooks we need the page and field from where the request was sent.