Revision/version language on revision listing page is misleading with content moderation enabled

@jhedstrom don't you think that's a little useless though? It'd be better if it created a new revision, with the same state as the revision you clicked the button for, but it's made the "default" revision.

The other option is just remove the button for pending revisions.

This is somewhat related to #2809123: Reverting a revision doesn't keep moderation state

When the button is clicked it; makes a copy of the revision.

Why not update the label to state what the button does, which is make a copy;

from: "Set as current revision"
to: "Make a copy of this revision"

I came across this issue during a training today and it's indeed misleading. If I would be to decide, I would go with "Make a copy of this revision", as suggested by #10

I changed the default moderation state, but the copy is still unpublished.
Maybe the better behavior is to have a log message and moderation state fields in the revert form to set a message and process that form as latest revision page does. For example when you change to published, then a published revision should be create with that message.

Hello,

I'm working for a client (government) and they are struggling with this. Their content editors can't make head nor tail of that button. When they asked me to explain I was also baffled at how unintuitive it is.

Workflow and Content Moderation is in core now. Thank you for that. But using it is not easy.

• The button does not do what it says.
• The "Revert" functionality which might seem like a destructive action is not very well explained on the confirmation page.

So in name of the client I want to focus attention again on this issue. Maybe some effort needs to go into the UI.

Here is what I believe is happening from a technical point of view:

• Content moderation always deals with the latest revision when loading up an entity form.
• The revision revert form loads old revision, sets some content like the revision log message, flags it as the default revision and saves it.
• During entity pre-save, content moderation will intercept the save, respond to the moderation state of that revision and then set the corresponding defaultness and published status of that revision.
• This results in a draft revision continuing to function as a draft and a published revision continuing to function as a published revision.
• In general, reverting or setting as the current revision will still enforce the pending/published nature of that revision according to content moderation.

So really, with content moderation enabled the button really means "continue the moderation workflow from this point in time", which beyond some confusing labels, seems like the correct behavior.

Imagine if the converse was true and clicking the button immediately published the revision. The interface could be used to simply bypass any kind of permission enforced content moderation workflow by creating new drafts, then switching over to the revisions tab to make them live.

I know @jhedstrom was working on a patch in #2906568: Provide users with the option to select an appropriate moderation state when reverting to a previous revision to revamp the revert form to provide some additional options during a revert, but this does feel like something content moderation probably shouldn't have to alter for every entity type if we can agree on the current semantics.

With that in mind, I'm not quite what what labels other than 'Revert' and 'Set as current revision' really cover ALL use cases for when content moderation is both enabled and disabled. Would putting something generic in there be a usability regression for just nodes?

#2612222: Provide a better way to alter entity revision overview might be an interesting avenue to address this.

It seems to me maybe Set as current revision' should become 'Set as latest version' or better yet 'Copy as latest version', which would align with the tab that says 'latest version' and the log message that says 'Copy of the revision from'. Meanwhile the 'Current Version' text may be better off saying 'Published' as its published nature seems most important.

Additionally, the Current/Published version should still be able to be copied to latest. If I am working on new drafts ahead of published, and then I need to make a change based on the existing published version, I should be able to create a new draft based on the published version, publish it, and then 'copy' the changes I was working on prior to updating published.

An example would be my page is currently discussing spring topics. I then start creating drafts of my changes for summer. I then realize I need to make a quick edit to spring. I copy spring to be the latest version, I make my changes and publish. I then copy summer back to latest version and continue my work.

I believe the Drupal\node\Form\NodeRevisionRevertForm already supports it, we just need to fix the table and links.

Looks like something is preventing the 'Current revision' from being 'Reverted' to be the latest revision, however previous and future revisions can be 'reverted'. Additionally, Drupal\node\Form\NodeRevisionRevertForm would need updating as well as the title of the form is 'Are you sure you want to revert to the revision from ?'.

Hi @michaellander, it kind of sounds like you're kind of on the path of #3023194: [PP-2] Add parallel revisioning support. I don't think it's necessarily expected that the revert feature would cater for hotfixes on the current published revision. While you've got an impressive work-around with some small changes, it sounds to me like a usability disaster, which is what this issue was originally opened to resolve :)

I do however really like your proposal of 'Copy as latest version'. Since discussing this issue 5 months ago, I've rolled this out for a client who additionally had this feedback:

We understand reverting to a draft creates a draft, but there is no feedback on which revisions are drafts or published.

While we're lacking #2612222: Provide a better way to alter entity revision overview, I replaced \Drupal\node\Controller\NodeController with:

/**
 * Override the node controller to display a better revision table.
 */
class NodeController extends CoreNodeController {

  /**
   * {@inheritdoc}
   */
  public function revisionOverview(NodeInterface $node) {
    $build = parent::revisionOverview($node);
    $node_storage = $this->entityTypeManager()->getStorage('node');

    /** @var \Drupal\content_moderation\ModerationInformationInterface $moderation_information */
    $moderation_information = \Drupal::service('content_moderation.moderation_information');

    // Only alter the revision table if the entity is moderated.
    if (!$moderation_information->isModeratedEntity($node)) {
      return $build;
    }

    $workflow_type = \Drupal::service('content_moderation.moderation_information')->getWorkflowForEntity($node)->getTypePlugin();
    $table = &$build['node_revisions_table'];
    $table['#header'][2] = $table['#header'][1];
    $table['#header'][1] = $this->t('Moderation state');

    foreach ($this->getRevisionIds($node, $node_storage) as $delta => $vid) {
      $node_revision = $node_storage->loadRevision($vid);
      isset($table['#rows'][$delta]['data']) ? $row = &$table['#rows'][$delta]['data'] : $row = &$table['#rows'][$delta];
      $row[2] = $row[1];
      $row[1] = $workflow_type->getState($node_revision->moderation_state->value)->label();
    }

    return [
      ['#markup' => $this->t('<p>Reverting to a revision which was previously a draft will create a new draft of that revision, which can then be published if required. Reverting to a published revision will immediately publish the contents of that revision.</p>')],
      $build,
    ];
  }

}

It might potentially be worth spinning this out into an opinionated contributed project and I'd definitely be interested in bringing in the 'Copy as latest version' terminology.

@Sam152, thanks for the feedback. I think we can still do this with sequential revisioning, but I may just be misunderstanding the issue. If for example we start with the following revisions:

• 4 (Draft)
• 3 (Draft)
• 2 (Current/Default/Published)
• 1

and I need to make an update to 2, I could copy it to be the next revision in the sequence:

• 5 (Copy of 2 - Current/Default/Published)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

I could make some edits:

• 6 (Current/Default/Published)
• 5 (Copy of 2)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

I could then continue work where I left off:

• 7 (Copy of 4 - Draft)
• 6 (Current/Default/Published)
• 5 (Copy of 2)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

I've got a working version on my local which i'm happy to post a patch for, but I'm fairly new to the inner workings of drupal revisions and want to make sure I'm not misunderstanding. I do think parallel revisions would be awesome but that obviously has an entirely new set of challenges.

(If you think this deserves a separate issue, let me know)

I've found some additional threads that might overlap with this:
#1863906: [PP-1] Replace content revision table with a view
#2350939: Implement a generic revision UI

Yeah, I think I understand the process you're using. I was pointing out in #20 that while that capability exists in the current implementation, it's ridiculously hard to wrap your head around this as an end user and the current UI provides very little hints on what the behavior actually is and additionally no hints on if a certain revision was a draft or published revision. Thus as a user, by default it seems near impossible to "discover" this feature :)

Feel free to post whatever patches you think might be relevant to the discussion, it may provide some new ideas or clarify any misunderstanding.

I also think both of those issues along with #2612222: Provide a better way to alter entity revision overview, would provide content moderation with the tools to at least clarify how things work at the moment.

FWIW, I'm looking for a way to do the exact thing that Michael is doing.

While the revisions UX is too complex (especially due to the inconsistent naming of things, sometimes referring to versions and sometimes revisions, without a clear distinction to the inexpert user as to the difference between "current" and "latest") once you do get your head wrapped around it it seems really daft that there's no way to make the current revision the latest revision. Right now, if someone wants to go back and edit the currently-published revision their only real solution is to delete all the revisions they've created since then! Which is WAY worse than any possible confusion that might be caused by introducing this ability. For that matter, I actually think it helps make things make more sense, since there's currently no real logical reason why there's not a way to make the current revision the latest revision, so the lack of that button just confuses things even more.

I also agree that "Copy as latest version" seems to map best to what's actually happening here. Though I still wonder why we're using "version" here rather than "revision" which is used pretty much everywhere else in Drupal.

I've started a basic first pass at this update. During my review, I could see that the "version" terminology is a holdover from the workbench moderation module. In my patch I've done the following:

1. Updated the labels to use core's chosen terminology of "revision" over "version".
2. Updated the confirmation page when a "revert" action is being performed to make it have a message detailing what is happening.
3. Updated associated automated tests with the new labeling.

Additional work would be required to make the actual route names and internal Drupal backend code use "revision" instead of "version". At this time, I didn't think that was prudent to include here because it would delay this ticket. Not to mention changes to Drupal's routes could cause unforeseen regressions across the contrib and custom module space. Any changes like that should probably be in a separate ticket.

1. +++ b/core/modules/content_moderation/content_moderation.permissions.yml
   @@ -2,7 +2,7 @@ view any unpublished content:
   -  title: 'View the latest version'
   +  title: 'View the latest revision'
   

   These string changes are valid, but they shouldn't be part of this patch as they're not related to the problem for this issue. They should be posted as a patch on a new issue.

2. +++ b/core/modules/node/src/Form/NodeRevisionRevertForm.php
   @@ -55,11 +63,14 @@ class NodeRevisionRevertForm extends ConfirmFormBase {
   +    $this->moduleHandler = $module_handler;
   

   I can't see why the module handler is being injected here?

3. +++ b/core/modules/node/src/Form/NodeRevisionRevertForm.php
   @@ -98,14 +110,33 @@ public function getCancelUrl() {
   +    if ($this->moduleHandler->moduleExists('content_moderation')) {
   

   I'm not sure about putting this in node module. It's not good DX to have these strings that describe CM module in a different module.

   Could this be done with a hook_form_alter() instead?

   Bear in mind #2350939: Implement a generic revision UI though -- it needs to be generic. (Which is another reason not to have this in node module, as it's then not usable by other entity types.)

I have not read all the comments, so here some feedback based on the "Proposed resolution", and the latest patch.

It seems the issue is focused on label changes - which is fair, if we want to remain within the original issue scope.

I just want to mention that just label changes are not enough.
For a forward (draft) revision, especially the latest revision, the current "Set as current revision" operation is not just poorly labeled, but also quite useless in most scenarios.

Currently the operation will create a copy of the chosen revision, with the same workflow state. This is almost never desirable for the latest forward draft revision - it adds additional revisions with no added value.
With #2906568: Provide users with the option to select an appropriate moderation state when reverting to a previous revision, it might set a different workflow state, depending how it is configured. This might be useful, but is still kinda weird.

More useful for a forward draft revision would be a "Publish" operation, which would copy the revision as a new default published revision.

If a node has more than one forward draft revision, there is a discussion to be had. Should we treat those the same as the latest revision, with a "Publish" operation, or should we treat them like older revisions?

----

I don't know if any of this should be addressed in this issue. Perhaps it should be addressed in #2906568: Provide users with the option to select an appropriate moderation state when reverting to a previous revision instead.

@donquixote I consider the option to have a "Publish" operation interesting, it is the equivalent to the "Revert" operation for past revisions.
But that is somewhat a different discussion, so I would discuss it and implement it in a different issue.

The operation that is being discussed here, "Set as current revision" (hopefully renamed to "Copy as latest version" or "Copy as latest revision"), must still exist, it should not be replaced for the one you propose.

This operation allows the editor to set a new revision as the latest.
When there are a few new revisions, only the latest, the one shown in the tab "Latest version", can be published.
Also, when an editor is seeing the Published version and clicks the "Edit" link, it will go to the latest version.
Choosing between new revisions, which one is the latest, it is an important operation that we must keep allowing.

So, the goal of this ticket, to improve the label, is important and we should focus on that IMO.

@merauluka the patch you're providing in #25 is changing from "Revert" to "Copy as latest revision". This would change the label for past revisions.
As I understood, the goal here is to change the current label "Set as current revision". The change only applies to new (or current, weirdly enough) revisions.

I'm now proposing a new patch that does just that. Really.
For now I've chose "Copy as latest version" as the new label.

If we agree on this, I propose as next step, to change from "Copy as latest version" to "Copy as latest revision".
This should be done together with the renaming of the tab "Latest version" to "Latest revision", to ensure we use the same term across the page.
Also the sentence "Revisions allow you to track differences between multiple versions of your content, and copy revisions to be the latest version." should be changed to "Revisions allow you to track differences between multiple versions of your content, and copy revisions to be the latest revision.

I respect dxvargas' very limited approach, but it doesn't seem to have gotten any traction.

So...I'm updating the issue description to expand the scope. I hope this doesn't ruffle too many feathers. This issue has been stalled for a while and I think it's because of the piecemeal approach. I'm hoping to cast a unified vision for better terminology that we can agree on and move forward. Patch coming soon.

So here's a patch to try to get my proposal rolling. These are heavily based on #25.

I've taken out #3252521: Allow reverting to current revision to try to handle the use-case outlined in #18.

I've also taken out #3252540: Disallow reverting latest revision to remove the "revert" operation from the latest revision since I don't think it makes any sense.

In #2350939: Implement a generic revision UI there's some discussion of the fact that the 'revert' terminology is confusing at the API layer as well. Perhaps that discussion can be folded into this one.

I propose "Restore" as the API verb to use when we want to tersely reference the idea of copying an old revision and making it the latest revision. I think it occupies a less-crowded namespace and does a better job of conveying the idea of what's happening.

+1 for changing "Revert" to "Restore", I agree that it conveys the meaning of the action better.

Regarding “restore”: to me that has a similar problem to “revert”.

If you consider the way backup and restore systems usually work, the restore part usually takes the entire system back to a previous state, so that it is in the exact way it was at such a time. If you apply that to this case, that could imply that the revision history would be essentially rewritten to the exact state it was at the time which is being restored to; But that isn’t the case because the version history between the revision being restored and now is still retained with a new “restore revision”.

So I would say that the word “restore” is generally too widespread with specific implications that it could lead to confusion among users.

I think the problem is that there isn’t an elegant well understood term to describe what it is that the Drupal revert action does.

Maybe we need to consider fundamentally changing how the revert revision action works. If we consider that we now have the ability to have forward revisions, and that the current revert behaviour hasn’t fundamentally changed since the older Drupal days. Maybe there’s a case to say that instead of revert creating a new “revert revision” it should actually just change the current revision to the revision that the user wants to restore to.

@AaronMcHale I agree that there's not an elegant, well-understood term to describe what Drupal's doing.

Unfortunately your proposal to just make the selected revision be the current revision does imply quite a few changes to the entire revisioning system. The entire approach to determining the "current revision" is (defined as the most recently-created revision in a "default" state) would have to change since, with your proposal, you could have newer revisions than the now-current revision in "default" states. Moreover, there are revisions that couldn't/wouldn't have normally ever been "current" that would not have to be able to be current (consider draft revisions that come after revisions in a "default" state).

Anyhow, while I agree that Drupal's revisioning system has plenty of points of confusion, I'd argue we should work on making UI improvements in this ticket rather than overhauling the underlying behavior of the entire API.

While "restore" isn't perfect, to me it does a better job of conveying some of the nuances of the action as compared to "revert", and I'd hope we'd continue to provide terminology like "Copy as latest revision" where practical.

The tab should be "Latest revision" by default.

I have users really struggling to understand Drupal revisions, especially with content moderation in the mix. The problem is "current revision" does not necessarily mean "published". It could be:

• The latest revision of an entity that has never been published. This is also the default revision.
• The published revision, with no forward drafts. This is also the default revision.
• The published revision, with some forward drafts on top of it. The latest draft is the default revision.
• A previously-published revision, with no forward drafts. This is also the default revision.
• The latest forward draft of a previously-published revision. This is also the default revision. Current no longer corresponds to a revision that is or was published - WTF?

Given the above, I don't think "current revision" is a useful term in a list of revisions. It's only relevant internally. Editors want to be able to easily identify:

1. The published revision.
2. If there is no published revision, the last-published revision.
3. The editable revision.
4. Whether the entity as a whole is published (there may be a long list of forward drafts).

Then the revision action labels and confirmation form text needs to be different, depending on what the actual outcome will be:

• Will the revision become published?
• Will the revision become the new editable revision?
• Are there any forward drafts that will become orphaned?

We have workflow state transitions and state transition labels. Can we make use of those?

Updated the issue summary to note that there is no help text on the confirmation forms, and the "set as current" confirmation button is labelled "Revert".

We encountered this issue on a client project and have created a minimal patch to address the most confusing labels.

Changes:

"Current revision" → "Published" (when the default revision is published)
- Keeps "Current revision" when the default revision is unpublished, as this remains accurate
- Uses inline ternary: $node->isPublished() ? $this->t('Published') : $this->t('Current revision')

"Set as current revision" → "Copy as new revision" (only when content_moderation module is enabled)
- With content moderation, this action creates a new forward revision rather than directly setting it as default, so "Copy as new revision" better describes the actual behaviour
- Retains the original "Set as current revision" label when content moderation is not enabled, as the action does behave as described in that context

This is a minimal, targeted change that addresses the core UX confusion without the broader terminology changes discussed earlier in this issue. We felt it was better to contribute something small and focused rather than wait for consensus on the larger scope.

Happy to adjust based on feedback.