- 🇬🇧United Kingdom catch
Just committed 🐛 Impossible to update an entity revision if the field value you are updating matches the default revision. Fixed , we should still add some dedicated methods here to make everything more explicit/documented.
We discussed this a bit in irc in relation to 🐛 Store revision id in originalRevisionId property to use after revision id is updated Fixed and #2833049: ContentEntityBase::hasTranslationChanges will compare a forward revision with the default one instead of the newest forward revision → . The big issue is that the revision we should be comparing against depends on context.
1. If you load the default revision, and save it as a new default revision, you should compare the old default and the new default.
2. If you load a non-default revision and save it as a new default revision (reverting, or publishing a draft), you should compare the old default and the new default.
In both cases $entity->original as it is now works for this case.
When saving a non-default revision it gets more complex.
1. No existing forward revision exists, saving a new non-default revision based on the current default. In this case you should compare against the default (which is simultaneously the most recent and the one you loaded)
2. Load and edit an existing forward revision, then save it as a new forward revision with a new workflow state. In this case you should compare against the loaded revision (which is simultaneously the most recent, but not the default).
3. You're reverting a forward revision back to a previous one - i.e. loading revision 1, saving revision 3. In this case the comparison ought to be against revision 2 (which is neither the revision that was loaded nor the default, but it is the most recent)
What this points to is that any one time, there are up to three revisions with different relationships to the one we're about to save:
1. The current default revision
2. The 'source' revision - i.e. the version we loaded as the basis of the one we're saving
3. The revision we're 'replacing' - this could be the default revision but it could also be the revision under consideration in a workflow.
(1,2) (2,3) (1,3), (1,2,3) can always point to the same revision (which we assume in the case with $entity->original)), but they can also all three be different.
Needs work
10.1 ✨
There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Just committed 🐛 Impossible to update an entity revision if the field value you are updating matches the default revision. Fixed , we should still add some dedicated methods here to make everything more explicit/documented.