When disabling moderation there is no way to remove moderation states

Button that only appears after moderation is enabled and the user tries to disable it.

Here is an early patch. Since we don't have a concrete entity reference field to the associated entity we can't write queries that include the bundle. There was some unholy approach I could see that involved a hook query alter, but the easiest approach seemed to be to store the bundle as well.

Before going any further and writing tests and an upgrade path we should probably discuss/agree on:

• If storing the bundle is something we want to do.
• What the UI should look like, strings, buttons, messages.

This is not reviewable. Can this get a less technical explanation?

Most of what I see in the screenshot would be a HIG violation, so I would recommend to start with identifying the different ways this could be solved, rather than already converging to the one solution.

Most of what I see in the screenshot would be a HIG violation

For those of us who don't know much about this, can you elaborate on what aspects are wrong? I think the convergence is based on there being a limited number of places or options this feature could slot in.

I think useful feedback would be:

• The use of a button vs some kind of appearing checkbox or toggle
• The visual style of the button (as Tim pointed out)
• The label of the button

I like the idea to make the button red.

Hi everyone :) I read the description of the problem and all the comments and I would like to ask the following questions:

1. @Bojhan is there an existing Human Interface guidelines Drupal document which I can find somewhere and read it? If there is such a document is everything in it obligatory or is the information in it just supposed to guide people?

2. @timmillwood and @Sam152 - in your case you wanted to delete all ContentModerationState entities for the given bundle and that is why you added the button in question. However, is this the only action which should be offered to the user? In other words I would like to suggest that some users may want to directly change the state of content to "published" and not delete it. Or are you deleting only the states and not the content itself which was set to be in one of these states? Also if only the states are deleted what will happen to content which was set to any of the states - to me personally this is not clear. Probably I am not able to understand the whole picture.

When disabling moderation on a bundle all ContentModerationState entities are left intact

For whom is this a problem in the first place? I don't think content editors would care, or is there a scenario where this could bite them sometime later?

Do site builders care? How does not deleting the moderation state entities impact their work?

Do developers care? Probably yes or this issue wouldn't exist :-). Do they need a UI for this?

To me it seems super technical to first make people understand that actually, the moderation state your content was in is stored in separate thingies that are now unused and do you want to delete them? “I don't know!” :-)

Lets first establish if, and if so, why, we need to make this a task for the user to make a decision about.

*Why* should content editors care though? :)

My initial assumption was indeed that it could work similar to uninstalling modules. You lose the settings related to moderation because you disabled it. But there is a difference between uninstalling and disabling. I'm trying to find out if there's a reasonable scenario where you'd expect your moderation settings to magically reappear when you turn moderation on again.

This seems similar to the "Deleting an Image Style" scenario. In that case, we allow admins to select a replacement image style and shift any references to the replacement. This is a bit different, but letting admins choose which states should map to "Published" and which ones should map to "Published" seems like the best approach to avoid accidents.

From an editor’s perspective I don't think there’s a problem with leaving it around. I assume it’s mostly about programmatically cleaning up after ourselves? But it seems like there’s value in keeping these around.

Doesn't anyone else have the issue of View related duplicates after uninstalling Workbench moderation on a multilingual site? I've already dealt with using language filters to deal with multilingual duplicates, and it now seems the only duplicates that are showing up, are those with no revision information.

I want to upgrade core beyond 8.2.7 on a production site, but Content Moderation must be disabled first. https://www.drupal.org/node/2869631

Content Moderation cannot be disabled until the states of all nodes are removed (There is content for the entity type: Content moderation state. Remove content moderation states) but the link to remove Content moderation state returns an error (The website encountered an unexpected error. Please try again later.).

Losing all the states, or having them all default to published is rather problematic but it is what it is, I guess we'll have to do a lot of preparation if we want to restore things manually later.

I found the following thread that has a patch to assist with uninstalling the content moderation module. Is the the only way to get past the issue so that I can upgrade core? https://www.drupal.org/project/workbench_moderation/issues/2627012

Any assistance greatly appreciated. Rick

Hi all,

Recently I have tried to remove an early created workflow. The workflow type hasn't got any entity type assigned to it now but it was assigned to some content types in the past and some content is using it.
When I tried to delete the workflow type, I got the message "This workflow is in use. You cannot remove this workflow until you have removed all content using it."
I don't want to delete the content as the content type is assigned to a new Workflow.
To do that, I have created an update script similar to the one in the current patch where it deletes all the content_moderation_state entries for a particular Workflow type.

/** @var \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager */
  $entity_type_manager = \Drupal::service('entity_type.manager');
  $content_moderation_storage = $entity_type_manager->getStorage('content_moderation_state');
  foreach($workflows as $workflow) {
    // Load all the content moderation of a workflow type.
    $results = $content_moderation_storage->loadByProperties(['workflow' => $workflow]);
    /** @var \Drupal\content_moderation\ContentModerationState $result */
    // Delete the content moderation entity.
    foreach ($results as $result) {
      $result->delete();
    }
  }

Now I can delete the Workflow type.
Will this cause any issue to the site?

Re-opening this because it seems that the stale workflow entities left on the content type are causing issues. Namely, the workflow cannot be deleted and gives the message:

"This workflow is in use. You cannot remove this workflow until you have removed all content using it."

This also breaks configuration management as the config import will fail with the same message as above when it attempts to delete the workflow on the site that had it before but can't.

Here I have tried to add reroll of patch #2 on Drupal 9.3.x.

Resolved CSpell errors

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 200, following Review a patch or merge require as a guide.

This seems more like a feature request and will need a test case for it

Thanks.

Fixed Drupal CS issue of patch #25, still needs work for comment #26,