Using Playa child fields in a search form
Hi Low,
I've got an Events channel and an Images channel. The Images channel has a single select Playa field which links an image to an event.
I've got an Image search form, and the client is asking if it's possible to pull search fields from the Events channel (the child entry in Playa terms, I think!) into this search form.
Is this possible at all? Here's what I was trying, which didn't work (it just told me there were no results when I entered anything into this field):
<label>Event Custom Field Test</label>
<input type="text" name="child:cf_event_test_field" value="" />
Thanks,
Stephen
Replies
Low 27 Feb 2013 15:33
Two options here.
The option child:cf_playa_field expects an entry_id as value, so you'd have to create a <select>-field where you can select the child entry. Results will then be filtered by entries that have the selected entry as a child.
The option search:cf_playa_field can also work, as Playa stores data in the native exp_channel_data table like this:
...so you can search through the child entry's titles only.
Because Playa saves its data like that, the Playa field itself can also be weighted and added to the search index, so you could even use keywords.
Stephen 27 Feb 2013 16:19
Hi Low,
Thanks for going through what is currently possible. I guess this is how I got the following working yesterday in another search form (for Events), as it looks through the title field.
<label><input type="checkbox" name="parent:cf_gallery_event[]" value="not EMPTY" /> Images attached</label>
I guess this post has turned into a feature request, as I'd love to be able to filter results by the custom fields in the parent or child entries too. Is this something you can see coming in the future? Or is is a massive ball-ache to go down that route?
Thanks,
Ste
Low 28 Feb 2013 08:29
I think you're mistaken the constant EMPTY with IS_EMPTY there (see the native docs on that).
As for your feature request -- I'll consider it, but I doubt it'll make it to the core. I've already thought long and hard about adding related entries to the search index, but that opens up a big can of worms, especially if the related entry in turn has a 3rd tier relationship.
Now, searching fields directly does simplify things somewhat, but still. Ball-ache sounds about right.
It could always be done as an add-on for Low Search. :)
Stephen 1 Mar 2013 04:26
Hi Low,
Thanks for the IS_EMPTY pointer - I'll fix that.
Yes, it's mainly the searching directly (rather than keyword search indexing) that I'm after. I've told the client it isn't possible (other than the title searches/filtering), but I reckon it'd be a good feature to add to the core if you've ever got 5 minutes to spare one afternoon! ;-)
Thanks,
Ste
Low 1 Mar 2013 12:28
Also note that if you'd want to search the relationship field specifically, try using search: instead of parent:.
Stephen 17 Jun 2013 03:05
Hi Low,
I'm just running a search on this Events channel again, and trying to filter the results to those events that have had an image uploaded and linked to them via the Playa field in the Images channel.
I thought the search was working fine, but I've just noticed that I'm only getting 398 results, when I should be getting 553 results. Do you have any ideas from the code sample below why all the results aren't being brought show in my search results?
Running the following query on the database for the Images channel is giving me 553 results (field_id_94 is the Playa field), which also tallies up with the results I'm getting in the Edit page of the CP.
Thanks,
Stephen
Low 8 Jul 2013 14:43
Okay, so. Here's the thing.
You can only use the IS_EMPTY string effectively in search:field parameters. This includes "not IS_EMPTY" and all other uses. The string is used in native search-parameters, and will be used literally in any other field, which you can see in queries in the output profiler.
I think you want to search for Contacts that have been selected in any of the Orders channel's entries, correct? If so, there is currently no way to do that with Low Search, I'm afraid.