Hello,
As documented here: https://www.drupal.org/node/3052114
I use $node->setSyncing(TRUE) to be able to update fields values of the latest revision without creating a new revision.
I have noticed that unfortunately, if the value I try to save is the exact same value that the one stored in the default revision, setSyncing(TRUE) will prevent this value from being saved !
Let me explain a little bit more:
I have a node that has already been published at least once. So its default revision is the last published one. It's the one you would get by doing a simple Node::load($nid)...
Since the last published revision, I have created multiple draft versions. So I have more recent revisions, and I make sure to load the latest one when I try to programmatically updated it:
$revision_ids = \Drupal::entityTypeManager()->getStorage('node')->revisionIds($node);
$last_revision_id = end($revision_ids);
$last_revision = \Drupal::entityTypeManager()->getStorage('node')->loadRevision($last_revision_id);
and then to update one field value of this latest revision, without creating a new revision, I do this:
$last_revision->field_MY_FIELD = "Some value";
$last_revision->setSyncing(TRUE);
$last_revision->save();
This works, but if "Some value" is already the value stored inside the default revision (last published), the value will not be saved (for the last revision which is the one I try to update).
So you can try to change the value to something different than the default version, witness that it's indeed working, saving and not creating a new revision. Then try to put the exact value stored in last published version, and witness that the value is not updated in the last revision.
However, if you comment setSyncing(TRUE) you are able to save the value even if identical to the one of the default revision.
Comments
Comment #2
nicolas bouteille commentedComment #3
sam152 commentedI think this might be a dupe of #2859042: Impossible to update an entity revision if the field value you are updating matches the default revision.
Comment #4
nicolas bouteille commentedThanks for reading my issue and spotting the similarity!
I thought you had it right, but the issue you mention does not mention setSyncing(TRUE) at all.
I am surprised because people seem to have faced the same problem I did but without event setting setSyncing(TRUE).
I on the other hand only have this bug if I setSyncing(TRUE). If I don't, I am able to update the value of the revision even if it matches the one of the default revision. I don't need to specify $entity->original... The only drawback of not setting setSyncing(TRUE) is that it creates an additional revision, which I don't want.
Comment #5
sam152 commentedThe only reason setSyncing is required in this case is because content moderation forces a new revision without it. If you disabled moderation, it would not be required and you would trigger the same bug without it.
Comment #6
nicolas bouteille commentedThat makes sense! I'm gonna try to manually set $entity->original like mentioned in #29
Comment #7
nicolas bouteille commentedYes setting $entity->original does work!
Thanks again for the quick follow up
Marking as duplicate as suggested :)