Problem/Motivation
Workspaces is built for staging and publishing changes to multiple entities at once. This concept of editing multiple entities is somewhat baked into the workspaces UI - e.g. each set of changes is a 'workspace' which can contain one or more entities.
Content moderation only tracks one entity at a time.
Actual Drupal entities are often composites of multiple different entities. For example an article has a path alias, which is an entity. Creating an article may involve adding a path alias on the entity form, which creates another entity. Editing the node and updating the path alias, updates the path alias. Content moderation doesn't know anything about the non-node entities so your path alias is changed on the live site, even if the node edit itself is in moderation.
What we ought to have, is the multi-entity tracking of workspaces, but without the overhead of having a separate 'workspaces' concept when you are mostly dealing with 'one' entity at a time rather than sets of changes.
Steps to reproduce
Proposed resolution
Done: 1. Create a 'workspaces_ui' module which holds the UI bits of workspaces. workspaces will need an update path to install the new module. #2972622: Split the workspaces UI into a separate module
2. Add a 'workflow' field to workflows module, this exists in contrib in the entity_workflows module but should really live in core for re-use #2835545: Provide a Workflow FieldType that references a workflow entity and tracks the current state of an entity
3. Add a 'managed' boolean and 'provider' string to the workspaces entity as base fields, existing issue #3095414: Add the concept of managed/temporary workspaces. This lets us identify workspaces that are not created manually via the workspaces UI and list/treat them differently.
All of the above steps are fairly well defined and prerequisites to everything else. The next bit is a bit more TBD but is where we got to after discussions with @amateescu this week and @fabianx a few weeks ago.
4. Create a new contrib module, to eventually replace content_moderation. When enabled and an entity bundle is moderated, creating or editing an entity via the entity form will implicitly create a workspace and save any changes to implicitly edited entities (path aliases, created media entities etc.) within that workspace. When the content workflow goes to published, it will then be published alongside all the other entities that are tracked with it.
5. We will need some kind of way to make this interoperable with advanced workspaces workflow, e.g. on the 'moderated content' page, add a bulk operation to move items to a 'real'/non-managed workspace. This can be a later step.
When we have a stable contrib module, it will be possible to mark content_moderation as deprecated in core and move it to contrib. The most basic migration path would be 'resolve the moderation state of entities in your site, uninstall content_moderation, install the new module'.
Discussed refactoring content_moderation with @amateescu but we think that there will be a fair bit of custom code that relies on content_moderation implementation details out there, so instead of trying to create a seamless upgrade path for all of those sites in a single minor release and potentially failing, better to let them migrate (or not) on their own schedule. But by having the new module in Drupal CMS we should stop adding to content_moderation usage as quickly as is currently happening which will start new sites off on a good footing.
If we come up with a way to do an in-place refactoring after all, then all of steps 1-3 are exactly the same anyway.
