Contrib.social

Allow for / implement simplified content workflow with workspaces

Open on Drupal.org →
Created on 8 November 2024, 5 months ago

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' content when you are mostly dealing with 'one' entity at a time rather than sets of changes.

Steps to reproduce

Proposed resolution

1. Create a 'workspaces_ui' module which holds the UI bits of workspaces. workspaces will need an update path to install the new 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 📌 Provide a Workflow FieldType that references a workflow entity and tracks the current state of an entity Needs work

3. Add a 'managed' boolean and 'provider' string to the workspaces entity as base fields, existing issue #3095414: Consider adding the concept of 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.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

workspaces.module

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment 5 months ago →
    🇬🇧United Kingdom catch
  • Comment 5 months ago →
    🇷🇴Romania amateescu
  • Comment 5 months ago →
    🇩🇪Germany Fabianx
  • Comment 5 months ago →
    🇬🇧United Kingdom catch
  • Comment 5 months ago →
    🇷🇴Romania amateescu
  • Comment 5 months ago →
    🇬🇧United Kingdom AaronMcHale Edinburgh, Scotland

    This is a really clever idea, and could really solve some interesting problems! I could see this being used to allow, for example, paragraphs on a node to all move with the node through the workflow.

    One thing we need to be mindful of is the large number of sites using content moderation with existing complex workflows. So we need to be clear that not all workflows are simply draft/review/publish. For instance, I'm on a project right now where we have content moderation workflows with many stages and transitions, and some branching logic. For instance, we essentially have different "tracks" within a workflow that content can be on depending on other factors. The fact that it's easy to set the moderation state of a node in-code, just by calling ->set('moderation_state', '...') really helps enable these more complex workflows.

    If we can continue to maintain the power and flexibility of content moderation, this could be very powerful stuff!

  • Comment 5 months ago →
    🇬🇧United Kingdom catch

    The fact that it's easy to set the moderation state of a node in-code, just by calling ->set('moderation_state', '...') really helps enable these more complex workflows.

    Hopefully this will stay exactly the same.

    The current idea is that there is a primary entity for a content moderation workspace, e.g. when you edit or create a node, we create a workspace for that entity and then edits to other entities within that workspace are included, but the workflow status is still tracked on the node itself. When the workflow state moves to published, this publishes the workspace and the other downstream changes (media, path aliases, menu links, paragraphs etc.) are published alongside it. This way the current UX and data model would be preserved as closely as possible, e.g. we'd be adding extra data but not necessarily moving or removing what content_moderation already stores.

  • Comment 5 months ago →
    🇬🇧United Kingdom AaronMcHale Edinburgh, Scotland

    Thanks for explaining that @catch, that does sound like a very cool idea then! I can definitely see the potential in this!

  • Comment 4 months ago →
    🇬🇧United Kingdom catch
  • Comment 3 months ago →
    🇬🇧United Kingdom catch
  • Comment 3 months ago →
    🇬🇧United Kingdom catch
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024