Active
Project:
Entity Reference Revisions
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
16 May 2016 at 06:17 UTC
Updated:
15 Feb 2023 at 08:10 UTC
Jump to comment: Most recent
Comments
Comment #2
berdirNo, it doesn't yet.
I agree that this might be useful. In paragraphs, it is currently not possible to edit a paragraph on its own, just within the host entity. So this wasn't a priority for us.
We will need a way to prevent recursion :)
A new revision, created on its own would currently simply not get used at all, since the reference is still to the old. I think we'd need to see what your use case is first to identify what to do here.
Comment #3
jmuzz commentedComment #4
jmuzz commentedI think we need a well defined meaning and expected behaviour for composite entities.
The concept of a composite entity is that it doesn't exist on its own but it operates as data that exists as part of the host's data. It may be useful here to separate "reference by design" and "reference in implementation."
I would say that the regular case of an entity reference or entity reference revisions is a reference by design. For example several entities can all refer to the same target.
The case of composite entities however is more like "reference in implementation," in other words the relationship is implemented in code as a reference to a composite entity but that doesn't mean that it should behave like a regular reference but should have extra features and restrictions to make it behave as though the entity is a part of its host's data rather than a separate entity that the host is merely referring to.
As @Berdir pointed out it doesn't make sense to allow a new revision of a composite entity without any change to the host.
I believe that for composite entities it should as much as possible be hidden from the user that the composites are separate entities and just held as references. Drupal does not allow a user to revert a single field in a node to a previous revision. The whole node needs to be reverted at once or not at all. For these reasons there should be a 1 to 1 relationship between a host entity's revisions and the revisions of its children, and every time a new revision of a child entity gets made a new revision of the host should as well.
The fact that the relationship does not currently work like this may be a bug. For example, the behaviour that is defined in the usual direction (making new revisions of the host) currently doesn't work in many scenarios either. #2801321: New host revisions do not always create new composite entity revisions.
Comment #5
bibliophileaxeThis would be useful for paragraph library items which can be edited independently of the node.