Codify mechanism to set a forward revision as the default revision

One problem is that there isn't a good way to log a revision switch without creating a new revision entry in the node_revision table.

#2: Yes and indeed that is the big problem - "just update the base entity table" ...

Maybe it indeed works in D8 out of the box, but in D7 it was a huge hassle hence why drafty settled on always creating a new revision when publishing.

Hello @jstroller.

I have seen all of the work you have done over the years to help get a reasonable base in core for managing revisions. I appreciate that and the topic has attracted my curiosity.

We just need a way to change the publication status from 0 to 1 and update the base entity table

As you know, historically, the convention has been that each update to the base entity table's vid is accompanied by a new revision (that is identical to the revision being promoted), a new revision id and a new revision log message. Allot of people like it this way because it preserves revision history.

It would be possibile to create a new operation (Action Button) that follows the convention of preserving history and also sets the new revision as published. There is nothing in core to prohibit this from happening in contrib that I know of.

@jstoller, i have faced the problem you had mentioned in your comment #5.

We partially solved it by asking the content editors to clone the node in case they want simultaneously work on another version of the node, once they push the decide to publish a version (at later instance...).

ie. you would be working on a new node instead of revision 16.

This is even more of an issue now Content Moderation module is in core as it can be done via the UI. The problem is then more prevalent when working with content translation too.

Struggling with this has well - implemented Workbench moderation, so new revisions have a status, which is very nice. Described workflow above is exactly as i expected this to work - content editor makes new, unpublished revision (either draft or review), content manager gets an overview of content which latest revision has "Needs review" state, but there is currently no way to set one of the newer revisions as the current revision or published node.

The solution in #5 causes a lot of problems in practice.

When you publish a forward revision, you're making a change from x default revision to y default revision. Modules implement hook_entity_presave() and hook_entity_update() to react to these changes. #2833084: $entity->original doesn't adequately address intentions when saving a revision explains the many ways this can go wrong currently. One concrete example would be the taxonomy_index table in core which only tracks default revisions - if you don't save the entity with the correct before/after state, then this table will get out of sync.

The problem with the forked/branch' entity in #5 is that it creates two histories - the history of forward edits vs. the history of default revision changes. We shouldn't sacrifice the history of default revisions to keep a clean history of forward revisions - the fact the default revision was changed from x to y on Saturday morning is itself useful metadata.

That's better solved by the concept of workspaces so you can track particular sets of changes to entities together, then it'll at least be clearer what the history is. Also storing which revisions are 'default' vs. 'draft' (i.e. we should stop talking about forward revisions at all).

When I make a change from x default revision to y default revision I'm not making any change to the content

The content is (usually) displayed on the site. That content changes when the default revision changes. So changing the default revision is the *most* change possible to the content in terms of what's visible, much more than making a new draft revision is.

@catch yes, valid points indeed.

Drupal architecture assumes linear revision history for nodes. And trying to force a forked or non linear workflow on revisions can't be solved easily. Thats why we sacrificed revision history, by cloning the node (and its content), when editors wanted to fork.

I feel, if forking is allowed then, arguments regarding state vs content doesn't matter. So the question is, what could be done to have content revisions support branches?

@D34dMan there's #2786133: WI: Phase B: Extend the revision API with support for parents which deals with that issue.

FWIW I agree with @jstoller

I see no reason why the default/current/published (whatever you want to call it) revision needs to be anything other than a specified revision in the history. It should be just a pointer that can be changed without creating a new revision. If that's not the case, that seems to me to be an architectural flaw.

The "edit" local task should always default to editing the latest revision, and creates a new non-default revision from that. If there is some confusion about what will be edited, then that is a naming issue (edit latest? edit draft?). It should not be possible to edit an old revision, there should be no branches. Linear workflow, let's not confuse users.

Reverting to an older revision would clone that revision and place it on the top of the revision stack, without changing the default/current/published revision pointer. Then "edit" will edit that reverted revision.

Reverting publicly would be a multi-step process, first revert, edit if necessary, then "publish" (change the default/current/published revision pointer to the latest reverted revision).

The revision history should be a list of state changes, not a list of revisions. I think perhaps that's where we are having conceptual trouble? Presenting it as a list of revisions forces us into cloning a revision just to "publish" it and capture that in the history, when that should be only a state change?

Sorry, excessively flippant.

@jstoller, i think we both want similar user experience.

referring to the diagram in this comment. It seems like we want a user experience for editors, as shown by "teal" colored boxes. I can understand how discarding "da" and "daa" revisions would make it simpler to achieve the required UX.

However, i still think, we can achieve the user experience when branching or forking could be supported. Added advantage would be, the behaviour will be essentially same if the editor chooses to work with an older revision of the Node.

---

We can also improve the revision log presented to user for the time being, if we show version from which it was derived from.

#13: Technical question:

If I load a revision and set newRevision => FALSE, defaultRevision => TRUE:

What will happen?

Would that not essentially publishing the loaded revision without further changing the revisions table?

I think the main problem is that we would have no way to know which is the published revision, right, because right now it is the top-most one, which is 'published'.

I think the new states for workflow will indeed help with that.

Actually, there are use cases where branching/editing from older version would be desirable.

An example would be a page concerning an annual event whose content might change only slightly from one year's event to the next year's, but that we won't know for certain how much it is changing until it is time for the next event.

Once the event happens in year one, we want to replace the content removing last year's content with a notice that the event has already happened and that the information is not available for the next year.

When the information becomes available for the next year, we would want to build that new revision from the older revision which has last year's details, not from the revision that says the information is not available.

Another use case is where someone has spent some time working on change to an already-published page, but the new draft hasn't been approved yet. A temporary change comes through that needs to be published right away, but it will be discarded once the new draft is approved.

Edge cases to be sure, but they have happened in real life.

If I load a revision and set newRevision => FALSE, defaultRevision => TRUE:

What will happen?

@Fabianx Did some manual testing,

Test:

Let say a Node with id '1' has revision ids '1' through '10' in chronological order, with only the 10th revision as published.

1. User creates revisions 11, 12 and 13
2. User runs the following script

$node_revision = '5';
$node =  \Drupal::entityManager()->getStorage('node')->loadRevision($node_revision);
$node->setNewRevision(FALSE);
$node->isDefaultRevision(TRUE);
$node->set('status', TRUE);
$node->save();

Observation:

1. node_load(1) loads revision 5.
2. Visiting node/1 shows revision 5.
3. Editing node/1 shows revision 5.
4. visiting node/1/revisions will show revision 5 has canonical link
5. visiting node/1/revisions will show revision 5 is set to "current revision"
6. visiting node/1/revisions will show all revisions greater than 5 to have "Set as current revision" action available.
7. visiting node/1/revisions will show all revisions less than 5 to have "revert" action available.

Also setting status of revision 5 to TRUE or FALSE has no consequence on the behaviour. (EDIT: the node would appear as published/unpublished accordingly, but it will always load revision 5... and not some other published revision)
Neither do publish status of nodes with revision id greater than 5 has any consequence on the behaviour. (i didn't expect this to be honest).

Needs testing:
A casual code reading doesn't reveal any effect on taxonomy reindexing and node grants rebuild since both of them wipe out old data related to node and recreate new entries (against revision 5). But needs testing nonetheless.
Search reindexing accepts Node id as parameter (instead of current node object), so this part of the code has to be checked if it works as expected.

We need non-liner revision history for content replication / deployment to work correctly.

Lets take the example we're trying to get into core, workspaces. Where on one site you have three workspaces, dev, stage, and live. If the same entity is edited on dev and stage we need to know which revision the change stemmed from so when the replication takes place we can resolve any conflicts.

This results in a revision history like this:

This example is taken from http://rakeshverma.in/final-submission. Rakesh worked with us on a Google summer of code project to build a library for resolving merge conflicts.

Ideally it'd result in a graph, not a tree, where a merged revision is created stemming from two parent revisions.

@timmillwood Love that the idea of the tree is coming up again. I did an analysis of revisions and limitations back in 2012 and i we caught up with some problems outlined in the post:
http://www.md-systems.ch/en/blog/techblog/2012/06/16/drupal-8-multilingu...
I back then discussed with people about the need for a branching revision model. It could start as simple as each revision knowing its predecessor, but people felt this is too crazy and Drupal 8 Core could never cover this model. Thus i steered into the minimum need for a revision / graph per language. (And the revision tab is still confusing in multilingual revision workflows.)

@Fabianx #21 - if you published an older revision like that, by overwriting the previous revision default, you'd then make it impossible to revert back to what was the previous default.

Based on recent work that we did with e.g. CotentEntityStorage::createRevision(), which enforces a new revision when "publishing" a pending revision, @plach and I think this should probably be closed as either outdated or won't fix as it. Anyone against doing so?

Since there was no followup from #33 opting to close as outdated.