A reverted revision is not listed on the version history

Created on 10 July 2025, about 2 months ago

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)

Steps to reproduce

  1. Create an Article (revision #1)
  2. Add new revision (revision #2)
  3. Revert revison #1 (revision #3)
  4. Notice revision #3 is not listed on the node version history (node/[id]/revisions)

Proposed resolution

Show the reverted revision on the version history

Remaining tasks

  1. Write a merge request
  2. Review
  3. Commit

User interface changes

A reverted revision is listed on the version history

Introduced terminology

API changes

Data model changes

Release notes snippet

πŸ› Bug report
Status

Active

Version

11.0 πŸ”₯

Component

node system

Created by

πŸ‡³πŸ‡±Netherlands idebr

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @idebr
  • πŸ‡³πŸ‡±Netherlands idebr
  • πŸ‡¦πŸ‡ΊAustralia acbramley

    Nice 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.

  • Merge request !12691Issue #3535230: Fix set as current revision β†’ (Open) created by acbramley
  • Pipeline finished with Failed
    about 2 months ago
    Total: 702s
    #544570
  • Pipeline finished with Success
    about 2 months ago
    Total: 1084s
    #544575
  • πŸ‡³πŸ‡±Netherlands idebr

    Test coverage shows the issue is fixed. Contrib tests in πŸ› Fix tests (next minor) Active are fixed as well with this change. Thanks!

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    We can clean a bit then, left a comment.

    I also verified that \Drupal\node\Form\NodeRevisionRevertTranslationForm::prepareRevertedRevision does this correctly.

  • πŸ‡³πŸ‡±Netherlands idebr

    The redundant lines were removed.

  • Pipeline finished with Failed
    about 1 month ago
    #553939
  • Hi, I’m new to the issue queue ,I setup a fresh Drupalβ€―11.2 site and tried the above mention steps to replicate the bugs,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.

  • πŸ‡³πŸ‡±Netherlands idebr

    I added a screencast on a new Drupal standard installation on 11.2.x with steps to reproduce

  • @idebr Thanks for checking it out.Please try making some changes while editing the content, then save it. Once saved, try reverting the content to see if the issue reproduces.

  • πŸ‡·πŸ‡΄Romania amateescu

    Looks good to me.

  • πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ
    
        // The node should retain the translations from the last default revision.
        // @see \Drupal\Core\Entity\ContentEntityStorageBase::createRevision.
        $this->assertTrue($node->hasTranslation('it'));
    

    This 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?

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    @alexpott that's exactly what ContentEntityStorageBase::createRevision is 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).

Production build 0.71.5 2024