[meta] Decide how Layout Builder should function with Content Moderation and Workspaces modules

> it is kind of weird to call $entity->validate() when you are not about to save. like what if some of the custom `presave` hooks are in charge of massaging the data so it validates. then these would not be fired so it wouldn’t validate

There is no such thing. Validate is *not* in any way tied to saving. presave can *not* affect the result of validate(). validate() must be called manually before calling save(), presave is part of save(). In fact, it is easily possible in presave() to to things that would fail validation.

#5 @Berdir thanks for the clarification.

I guess my point was calling $entity->validate() when you are not about to save.

what @johndevman and I talked about in regards to

We could try to warn the user about the entity's violations, by filtering $entity->validate() on the layout override page.

Is that while

We could add $entity->validate() when saving layout, then if the transition is not correct we would get an error and not save

does prevent the user from saving an invalid transition state or other violations the user would not know this when they get the layout override page.
They could do a lot work layout and then when they clicked "Save layout" they would be told the transition is not valid or other violations.

One way to avoid this situation would be to call $entity->validate() when the layout override form is being presented to the user.
Then could filter out any violations for the layout_builder__layout field and then present any other violations to the user so they don't start changing the layout.

The problem I see with this is that a lot could happen between when we first present the layout override page and calling $entity->validate() right before save. even between clicking "save layout" and $entity->validate(). or event changes to layout_builder__layout might be the thing that would cause the violations to go away.

I have to say I have not actually used the layout builder yet, so I don't really know how the UI works.

That said, how is this any worse than editing any other field? I can go to the edit form of a node, work on it for an hour and then I get a validation error on save that someone already saved that node?

The normal edit form limits validation errors that actually prevent saving to the fields that are being displayed and are accessible to the user. I guess this could do the same, or as you said, specifically track the validation errors that already exist before and only allow to save if there are new errors due to the changes.

After finding out from @tim.plunkett that entity specific layout overrides are stored in a field on the entity, I don't think there will be any issues.

Content Moderation example:

1. Create a node and override the layout, set it to the "published" state.
2. Edit the node, update the layout, and set the the state as "draft".

There would now be two revisions with different layout. The published revision is the default revision the user sees and the draft revision is the latest pending revision.

Workspace example

1. In the stage workspace create a node and override the layout.
2. Deploy the content from stage to live.
3. Back in stage edit the node updating the layout.

There would now be a version of the content in live, and a version in stage. Both are the same content, but have different layouts. This uses the default / pending revision system. The live workspace has the default revision, the stage workspace is loading the pending revision.

Created a related issue #2973860: When there is an entity forward revision for Content Moderation and a layout override is saved the revision is no longer latest

From that issue

Saving an override is weird because it is saving the entity you update a field but you don't have to have edit permission.

If this wasn't the case the user would not be able to edit the entity.

Maybe if the entity is moderated and the user doesn't have edit access we should allow them save an override. Or maybe just if there is forward revision.

If we there is a forward revision I think there would be problems editing the layout.

1. The user might not have access to know there is forward revision.
2. I think `content_moderation` you should only call $entity->save() on LatestRevision.
3. If so then the Layout Override should also effect the late revision.
4. If a user doesn't have access to the latest revision because it is unpublished then we can't show the layout override page to them because it will show field values for the latest revision.
5. If a user has View access to the latest revision when it is not the default revision they could use the Layout override form but we would have to inform them they were editing a non-default version so they don't expect to see their changes on the entity view and aren't confused that field values on the layout override value are not the same as the node view.

Sorry to cross post this bit, but there are a bunch of issues related to layout builder and content moderation, so I'm not sure who has seen what. Content moderation part from #3004536: Move the Layout Builder UI into an entity form for better integration with other content authoring modules and core features:

I believe the existing proposals to integrate with layout builder fall short because:

• The layout override form is the encouraged mechanism for authoring new content.
• Applying a moderation workflow to fields on the entity is redundant if those fields can be replaced with a non-reusable block and skip moderation altogether.
• If a user transitions an item of content to state "Foo", they are not necessarily allowed to create new content revisions while leaving the state unchanged (think of something going into review, with an author no longer able to make changes to that content until a review has been completed).

The only way I see these two modules integrating in a way that is true to the sprit of both feature sets: rich content driven layouts/moderated content workflows, is if:

• Entity "update" access is respected. (see related issue)
• The latest revision is loaded. (see related issue)
• The same moderation state transition widget is visible and available when saving the layout override form which allows the authoring of new content. (no related issue in discussion)

Edit: rereading this issue more carefully, looks like @johndevman and I came to similar conclusions with:

To solve that, the Layout Builder layout override must then allow the user to choose a given state to be transitioned to?

I've updated the issue proposal in #13 with a demo of layout builder and content moderation working together for anyone who is interested: https://www.youtube.com/watch?v=GT-bf_7o3cY.

I think this is fixed by #2942675: Layout builder should use the active variant of an entity to avoid orphaned revisions and therefore it can be closed, right?

#3032287: Add the content moderation state widget to the layout builder entity form. is the actual implementation issue for CM.
I'm not sure what's up with workspaces these days.

That implementation issue is in. Calling this done!