Problem/Motivation

Spin off from #2761409: The latest revision isn't always the current revision.

Currently the only UI for changing the current revision in core, is the 'revert' functionality on the revisions tab.

While this says 'revert', what it actually does is:

1. Load an old revision
2. Save it as a new, current revision

The old revision is left completely intact and unchanged, as it the one being reverted from.

This allows modules that need to consult $entity->original, react to entity saving hooks etc. to behave the same as if the entity had just been edited without new content, it also preserves the revision-to-revision history (i.e. if you revert a revert, that'll also create a new revision, so you can see what the entity looked like at any given point).

However, it's not really 'reverting' - it would also work completely fine for forward revisions too.

Tim Millwood also brought up being able to set the current revision without creation a new one. This would be a lot less involved than the current code - since you'd just change where the pointer is to rather than loading and saving as a new one. I think the advantages of the current system outweigh the simplicity of this though, since not allowing entity hooks to fire could run into data-integrity issues.

Proposed resolution

1. Decide whether the current behaviour is OK or not.

2. Decide whether the language of 'reverting' and 'setting as current' adequately describes what happens to end users.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman at Acquia commented

I agree that the current behavior is safest for core. Maybe some Contrib code can tackle the 'just move the pointer to anther revision'.

The only other wording I can think of instead of 'revert' is 'Publish'. This makes sense because you are making an existing revision the published revision. Its a bit confusing thugh since the revision might have a status=0 which we usually call unpublished.

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
CreditAttribution: timmillwood at Appnovation for Pfizer, Inc. commented

"published" won't work because the revision you're setting to be the current revision may not be published.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Issue tags: +Needs usability review, +Usability

Its a bit confusing thugh since the revision might have a status=0 which we usually call unpublished.

Yep, gets confusing when this happens.

Another option might be 'Set live' or 'Set as the live revision' - one advantage is this works both for forward and backward revisions, and site builders may already be familiar with the concept of a 'live' site (as opposed to dev/staging).

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

Well, making a new copy of the revision allows us to have an audit trail no? How would we have an audit trail if there is not a new revision?

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman at Acquia commented

@Gabor - correct.

'Set as live revision' works well as UI text. But I'm a little uneasy about the term 'live revision'. That would show up in code, developer docs, etc. I think 'Set as active revision' is a bit more natural IMO

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented

@Gabor yes exactly, there's no audit trail if we allow switching between multiple revisions, I think we just need to improve how we communicate it.

'active' feels like it has the potential to be ambivalent once we get to workspaces etc. At that point, when you're in a workspace the non-live revision could be 'active' (i.e. that's what you're viewing and editing based on), but it still won't be 'live'.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Bojhan’s picture

Bojhan CreditAttribution: Bojhan as a volunteer and commented
Issue tags: -Needs usability review

Can anyone describes this in terms of user stories/scenarios?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mrgoodfellow’s picture

mrgoodfellow CreditAttribution: mrgoodfellow commented

I would love to have the option to edit the content of the node prior to reverting, that way any changes can be made when publishing. Currently when reverting with Workbench Moderation we have a workflow issue where the revision is in a drafted state and the page is no longer available to external users. I would like to be able to either be able to draft a new revision and have the previous revision remain published OR have a way to edit the content of the revision before publishing the changes.

Ideally I could hook the editable contents of the revision at the page that propts: Are you sure you want to revert to the revision from...
then changes can be pushed before publishing. I think there may be a pre-save but I'm not sure how I can hook into this page properly.

I'm using workbench moderation with drafty.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.