-
Notifications
You must be signed in to change notification settings - Fork 641
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage "Field Type: Entry" from both sides of the relation. #3907
Comments
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? |
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). |
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. |
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! |
I'd be willing to help test or review this feature too. |
I would also love to see this! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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/ )
The text was updated successfully, but these errors were encountered: