Re-order children incompatibility with content_moderation

This is expected behaviour

The forward revision is not the parent at that stage, the published one is

I will need to think about how to handle this without changes being visible on the live site

In addition to ordering the children of the live revision, our editors want to work on batches of changes of a whole tree in draft mode, which includes ordering the children in the draft view.

Hey @sime, just to clarify, when you say "in draft mode", do you mean when the parent content is being drafted, or do you mean creating a draft version of the whole entity hierarchy and then publishing that once it's ready?

Putting aside #4 and #5 and purely looking at the steps in the issue summary, you can choose to load the default revision in that reorder form, which does indeed grant you access to reorder the tree, while creating a draft.

I'm not sure if this impacts other areas of EH, but conceptually I guess it would be modifying the "live" version of the tree, like @larowlan mentioned in #2. I'm unsure what users expectations are at that stage, considering they are mid-way through a draft or if "leaking" into the live version is useful or not.

Seeing what the bot says.

Just trying to clarify my own understanding of the module and the problem space (please correct me if I'm wrong):

• Each node has a parent field.
• The parent fields of a group of nodes together create the hierarchy.
• The hierarchy is revision aware, because you can draft a node and re-parent the draft (to be later published).
• The parent field is standard field storage, stored in a revision alongside all other page content.
• The re-order form is required to modify revisions of children, to set the weight, so the reordering works.
• So conceptually, the draft of a parent has no relationship to the hierarchy created by the revisions of children, the reorder form kind of gives that impression, but under the hood, it's reaching into a child revision and resaving it (see #3188383: Reordering children overrides their drafts).

I do wonder if given this information, it's conceptually possible to "draft" tree reorder changes and have that be independent of child content changes, without a massive amount of complexity. I do wonder if storing the tree information in a field is going to afford this level of flexibility.

Conceptually, maybe a "reorder" operation needs to direct users into the child entity form to make changes. From there, they are already presented with options around drafts and publishing, so decisions about when things are reflected in the live version would be more explicit.

This does introduce a massive limitation, that reordering and reparenting are stuck and bound to content changes that might be occurring at the same time. This is unsolved in core and was once in scope for the workflow initiative. The issue tracking such revision semantics is: #3023194: [PP-2] Add parallel revisioning support:

The typical example is an entity going through a set of significant changes (either via Workspaces or via an editorial workflow implemented via Content Moderation) and at the same time needing a small typo fix in its default revision.

In this case the "typo" that the parent entity wants to fix up is the weight of the child.

Thanks, rolling 8.x-2.25