Replies: 7 comments 5 replies
-
I could definitely see us adding a list of elements that have relations pointed at the current element – either as a list in the details pane on edit pages, or with a new “Reverse Relations” field type that could limit the list to just relations pulled from a specific relational field. (The field type approach would also solve the reverse relation syntax part of #1640, as you’d be assigning a custom handle to the reverse relations.) Adding new relations from the reverse end could be a little tricky, since we don’t really know in advance which elements should be able to store relations to the current element. A relational field could be used on any element type, including Matrix fields, etc..
From their docs it looks like they manage relations relatively similarly to Craft, albeit with only one “element type” to consider. But I’m not seeing anything on that page about reverse relations. How exactly does that work there? |
Beta Was this translation helpful? Give feedback.
-
In the context of Webhook (and other light CMSs we have used), the entity-to-entity relationships are simpler. In Craft, when we set a field type to Entity Type, we have the potential for select multiple Entity Types. In, say, Webhook, relationships were 1:1. If translated to Craft, I could see the spec being something like: Field Type: "Related Entity" Options:
From there, the rest of the Craft experience would remain the same (i.e., the user would still need to manually add the new field to the Books and/or Topics to their Sections/editor templates). If the editor wanted to have multiple relationships, they would just need to add those in a one-off manner (e.g., Books to Topics, Books to Authors, Books to Best Seller Lists). Within the Twig/Template code, the structure could be similar to your proposed #1640 issue. The simplicity would just be the 1:1 nature (vs. needing to deal with 1:multi). |
Beta Was this translation helpful? Give feedback.
-
Yeah something like that could work. Basically relationship fields are set with the constraints for both sides of the relation. To do it right, this new relationship field would need to work with all element types, not just entries, which means we’ll need to wait until element types can define their own condition builders (which will also be needed for #1630) so the admin can have a consistent way of choosing which elements of a given type should be relatable. That may come in a Craft 3.x release, and if not, certainly by 4.0. |
Beta Was this translation helpful? Give feedback.
-
Great -- thanks for considering @brandonkelly! I also edited my comment above to make it clearer / to use the correct terminology (now defined as "Entity Type"). If I can support/review/test/etc. further, please let me know! |
Beta Was this translation helpful? Give feedback.
-
I'd be willing to help test or review this feature too. |
Beta Was this translation helpful? Give feedback.
-
I would also love to see this! |
Beta Was this translation helpful? Give feedback.
-
Curious if this ever saw the light of day at all? |
Beta Was this translation helpful? Give feedback.
-
In our site, we cross-relate a bunch of content types. In other CMSs, these cross relations could be viewed and manage from both sides of the entries.
For example, if we take the generic Book Store example. The data model has:
When we go to the Book entry, we want to view/add/delete all Topics.
When we go to the Topic entry, we want to view/add/delete all Books.
There are a few plug-ins that attempt to solve this for Craft, but they are buggy or view-only (see Discourse thread on similar topic).
So, unless we are missing something very obvious, this feels like a feature that should be native to Craft.
(An example where this worked simply/nicely was in the old Webhook CMS: http://www.webhook.com/docs/relationships/ )
Beta Was this translation helpful? Give feedback.
All reactions