Multi-step & bi-directional relations with relatedTo

[brandonkelly]

Craft currently supports multi-step relational queries, but only for relations that go through a Matrix field. For example you can load all of the assets related to an entry via a container Matrix field like so:

{% set assets = craft.assets
    .relatedTo({ sourceElement: entry, field: 'matrixHandle.assetsHandle' })
    .all() %}

This functionality should be expanded to A) allow for additional steps and/or fields that aren’t Matrix (see #1564), and B) allow the steps to be bi-directional (mix both forward- and reverse-relationships together in a single path).

Common example: Let’s say you have Books, Authors, and Publishers, and two relationship fields on the Books channel: author and publisher. On a Publisher’s page, you want to list all of the Authors that have published books with them.

Currently that would require two queries:

{% set bookIds = craft.entries()
    .section('books')
    .relatedTo({ targetElement: publisher, field: 'publisher' })
    .ids() %}

{% set authors = craft.entries()
    .section('authors')
    .relatedTo({ sourceElement: bookIds, field: 'author' })
    .all() %}

But ideally it could be done with one:

{% set authors = craft.entries()
    .section('authors')
    .relatedTo({ element: publisher, via: 'book!.author' })
    .all() %}

(The ! in book! would be to indicate that it’s a reverse relationship. Not married to it but we will need some way to do this.)

[brandonkelly]

For reference, Yii handles multi-step relations with viaTable() and via(): http://www.yiiframework.com/doc-2.0/guide-db-active-record.html#junction-table

[narration-sd]

Cute -- and this is right back to Playa days, isn't it...concepts always refining.

Would kind of favor a function approach (via()) rather than yet another cryptic punctuation, as we have plenty of those in our wider software world now, no?

And nice that it would 'functionally' be more clear...

[nateiler]

I think the current syntax of source and target is intuitive and I've never had a problem with it.

Looking at A) I could see this as field that have relations implement a new RelationFieldInterface. When iterating over the matching fields, you call the field to build the relation condition instead of the ElementRelationParamParser.

We have a field type (Meta) that is a stripped down version of Matrix and need to apply our own table joins. In this case it would be a simlar join syntax to Matrix, but with our own tables. We also have another field type that records dues for user and mirrors the relations table.

Thoughts on ElementRelationParamParser.php:260 checking for a new interface (as above) and passing the logic off to the field type to build the condition? I'm suggesting an interface to identify this relationship vs BaseRelationField as both of the field types we built do not inherit that class.

[brandonkelly]

I think the current syntax of source and target is intuitive and I've never had a problem with it.

The problem with it is it assumes each step in the field path is going the same direction. In the above example, both the Publisher and the Authors are “targets” of two different relations on the Books, so targetElement and sourceElement no longer make sense.

[brandonkelly]

Thoughts on ElementRelationParamParser.php:260 checking for a new interface (as above) and passing the logic off to the field type to build the condition?

Not against it, but after spending a day refactoring relations and thinking about how to go about it, I’ve realized that doing it right will be a bit more involved than I originally expected, and when we do find the time to address it, we should also make multi-step/bi-directional relations possible.

[rob-c-baker]

This would be very useful. I am currently trying to get this to work (multiple nested relations):

In pseudo-code...

interestedCategory = { Category query for specific category }->one()

entries = { EntryQuery for single entry in section }
    ->entryViaEntriesField
    ->{ entryViaAnotherEntriesField within entryViaEntriesField entry }
    ->targetCategory

... where interestedCategory == targetCategory In either Twig or PHP.