Problem/Motivation
When reverting a previous revision, a new revision is created with the original data. However, this new revision is not listed on the version history (node/[id]/revisions).
\Drupal\node\Form\NodeRevisionRevertForm does not call \Drupal\Core\Entity\ContentEntityStorageBase::createRevision that sets the revision_translation_affected.
See \Drupal\Core\Entity\Form\RevisionRevertForm::prepareRevision for reference
Steps to reproduce
- Create an Article (revision #1)
- Add new revision (revision #2)
- Revert revison #1 (revision #3)
- Notice revision #3 is not listed on the node version history (node/[id]/revisions)
Proposed resolution
Call $revision = $this->nodeStorage->createRevision($revision); in NodeRevisionRevertForm::prepareRevertedRevision
Remaining tasks
Write a merge requestReview- Commit
User interface changes
A reverted revision is listed on the version history
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3535230-11.mov | 1.87 MB | idebr |
| #10 | Screenshot 2025-07-24 134446.png | 74.61 KB | sagarsingh24 |
Issue fork drupal-3535230
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3535230-a-reverted-revision
changes, plain diff MR !12691
Comments
Comment #2
idebr commentedComment #3
acbramley commentedNice find @idebr, tested locally and the call to createRevision will fix this for Diff. I'm going to work on this today.
I'll also open a follow up to have NodeRevisionRevertForm extend RevisionRevertForm as there's a lot of duplication there.
Comment #4
acbramley commentedComment #6
acbramley commentedComment #7
idebr commentedTest coverage shows the issue is fixed. Contrib tests in #3498660: Fix tests are fixed as well with this change. Thanks!
Comment #8
berdirWe can clean a bit then, left a comment.
I also verified that \Drupal\node\Form\NodeRevisionRevertTranslationForm::prepareRevertedRevision does this correctly.
Comment #9
idebr commentedThe redundant lines were removed.
Comment #10
sagarsingh24 commentedHi, I’m new to the issue queue ,I setup a fresh Drupal 11.2 site and tried the above mention steps to replicate the bug,After the revert a new revision shows up in the list and is marked as the current one so everything looks normal on my end.Is there another condition that I need to add to see the bug?Let me know and I’ll test again.
Comment #11
idebr commentedI added a screencast on a new Drupal standard installation on 11.2.x with steps to reproduce
Comment #12
sagarsingh24 commentedThanks, @idebr. I re‑ran the test with changes in the edit revert works and the new revision appears.No changes in the edit (your screencast steps) new revision doesn’t show in the list.So I can say the bug only shows up in the “no‑changes” scenario.
Comment #13
amateescu commentedLooks good to me.
Comment #14
alexpottThis feels like a massive change of expectations. If you revert to a revision before a translation a translation has been created I would not expect translations that were added afterwards to exist. I don't know but this choice seems deliberate.
Are we sure this change is correct?
Comment #15
acbramley commented@alexpott that's exactly what
ContentEntityStorageBase::createRevisionis documented to do from what I'm reading. Without this fix, reverting a Node to a more recent revision that is not current (i.e clicking Set as current revision) has a really weird outcome and essentially bugs out the revision list (try running the tests without the fix and looking at the HTML output or debugging yourself).Comment #16
smustgrave commented@alexpott thoughts on #15?
Comment #17
acbramley commentedFYI this is also what RevisionRevertForm::submitForm does (i.e the generic revision UI) which Node will eventually use in #3153559: Switch Node revision UI to generic UI
Comment #19
smustgrave commentedThis one may need a rebase.
Comment #20
idebr commentedMR12691 is rebased
Comment #27
alexpottI committed this by mistake. I'm happy with @acbramley's answer. Once this is RTBC it can go in.
Comment #28
smustgrave commentedThanks @alexpott!
So this one was difficult to test manually. Using the workflows module I was able to see it but following the test seems like this bug mainly surfaces when manually creating nodes.
Test-only showed it https://git.drupalcode.org/issue/drupal-3535230/-/jobs/8191844
Either way the fix did address it.
LGTM
Comment #29
alexpottCommitted and pushed 9f2ee8352d4 to main and 2daa9e05047 to 11.x and 1983827c89f to 11.3.x. Thanks!