Leverage PluginWithFormsInterface to encapsulate @WorkflowType schema and clean up state/transition form methods.

Can we document why we want this in the IS?

IS was updated in #12. I just improved formatting a bit more.

By not giving @WorkflowType plugins a chance to react to the submission of their state/transition forms (just like \Drupal\Core\Plugin\PluginFormInterface allows you to), we're breaking encapsulation by blindly setting those form values into 'type_settings'.

Emphasis mine.

+++ b/core/modules/workflows/src/WorkflowTypeInterface.php
@@ -108,6 +109,18 @@ public function getInitialState(WorkflowInterface $workflow);
+  public function submitStateConfigurationForm(array &$form, SubformStateInterface $form_state, StateInterface $state);

@@ -128,6 +141,18 @@ public function buildStateConfigurationForm(FormStateInterface $form_state, Work
+  public function submitTransitionConfigurationForm(array &$form, SubformStateInterface $form_state, TransitionInterface $transition);

The devil's advocate question is: Why can't WorkflowTypeInterface extend PluginFormInterface then?

AFAICT the answer is Because every @WorkflowType plugin supports two kinds of forms: one for state, one for configuration.

Questions:

1. Is my understanding correct — is that the reason why this is not reusing the existing interface, and is instead adding two methods?
2. Why is there no need for validation callbacks, only for submit callbacks?
3. Why not use \Drupal\Core\Plugin\PluginWithFormsInterface (which is fairly new, it was added almost exactly a year ago, in #2763157: Allow plugins to provide multiple forms). Then you could change
   

    * @WorkflowType(
    *   id = "content_moderation",
    *   label = @Translation("Content moderation"),
    *   required_states = {
    *     "draft",
    *     "published",
    *   },
    * )
   

   to

    * @WorkflowType(
    *   id = "content_moderation",
    *   label = @Translation("Content moderation"),
    *   required_states = {
    *     "draft",
    *     "published",
    *   },
    *   forms = {
    *     "state" = "FQCN",
    *     "transition" = "FQCN",
    *   },
    * )
   

Whichever direction this ends up taking, a change record will be necessary.

For now, updated the IS to reflect the solution the current patch is proposing.

Ultimately this is needed because we can't have Workflows module assuming anything about the type_settings, however I have one concern.

+++ b/core/modules/workflows/src/Form/WorkflowTransitionAddForm.php
@@ -5,6 +5,7 @@
@@ -105,11 +106,6 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,

@@ -136,6 +132,11 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   public function save(array $form, FormStateInterface $form_state) {

In each of the form classes we're moving the construction of the entity object from copyFormValuesToEntity() to save(). Wouldn't this cause validation issues?

Couldn't we call submitStateConfigurationForm() and submitTransitionConfigurationForm() within copyFormValuesToEntity.
Or add copyStateToEntity() or copyTransitionToEntity()?

#19: Oh, I hadn't even found WorkflowTypeFormInterface! I see it does interface WorkflowTypeFormInterface extends PluginFormInterface, WorkflowTypeInterface {}, which makes sense. And class ContentModeration extends WorkflowTypeFormBase {}, which also makes sense. But that means that for ContentModeration, there will not be two, but three submit handlers, so it's even more complex than I thought!

1. Ahh! This is extremely illuminating :) Is that documented somewhere? I don't see a workflows.api.php file. It's also not documented in either \Drupal\workflows\Annotation\WorkflowType or \Drupal\workflows\WorkflowTypeInterface. Even just adding this one sentence that you provided here would be super helpful:
   

   There are three kinds of forms @WorkflowType plugins can provide. A global one, one for individual states and one for individual transitions. The global workflow form is the one that PluginFormInterface assists with.

2. 👍
3. You can still use SubformStateInterface ! You might want to talk to @tim.plunkett about this, he worked on this, and is a Form API maintainer, so he'll be able to best explain this :)

Oh, also — by adding these 2 methods to WorkflowTypeInterface, you're effectively making the state & transitions forms required, but the global one is optional. Is this intentional?

1. +++ b/core/modules/workflows/src/Annotation/WorkflowType.php
   @@ -50,4 +50,17 @@ class WorkflowType extends Plugin {
   +   * Forms which will be used for the workflow UI are 'configure', 'state' and
   +   * 'transition'.
   +   *
   +   * @see \Drupal\Core\Plugin\PluginWithFormsInterface
   +   * @see \Drupal\Core\Plugin\PluginFormInterface
   

   Would be good to @see the 3 base classes here too.

2. +++ b/core/modules/workflows/src/Form/WorkflowStateAddForm.php
   @@ -86,12 +120,23 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   
   @@ -101,6 +146,15 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   
   +++ b/core/modules/workflows/src/Form/WorkflowTransitionAddForm.php
   @@ -128,6 +161,13 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('transition')) {
   
   @@ -136,6 +176,15 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('transition')) {
   

   Do we also need an else case? Or are these entirely optional?

   (Would be good to have that documented.)

3. +++ b/core/modules/workflows/src/Plugin/WorkflowTypeConfigureFormBase.php
   @@ -0,0 +1,51 @@
   +abstract class WorkflowTypeConfigureFormBase implements PluginFormInterface, PluginAwareInterface {
   
   index 942c2d6..0000000
   --- a/core/modules/workflows/src/Plugin/WorkflowTypeFormBase.php
   
   +++ b/core/modules/workflows/src/Plugin/WorkflowTypeStateFormBase.php
   @@ -0,0 +1,55 @@
   +abstract class WorkflowTypeStateFormBase implements PluginFormInterface, PluginAwareInterface {
   
   +++ b/core/modules/workflows/src/Plugin/WorkflowTypeTransitionFormBase.php
   @@ -0,0 +1,55 @@
   +abstract class WorkflowTypeTransitionFormBase implements PluginFormInterface, PluginAwareInterface {
   

   👍 — but would be great to get @tim.plunkett's thoughts on this.

4. +++ /dev/null
   @@ -1,16 +0,0 @@
   -interface WorkflowTypeFormInterface extends PluginFormInterface, WorkflowTypeInterface {
   

   👍

5. +++ b/core/modules/workflows/src/WorkflowTypeInterface.php
   @@ -15,7 +15,7 @@
   -interface WorkflowTypeInterface extends PluginInspectionInterface, DerivativeInspectionInterface, ConfigurablePluginInterface {
   +interface WorkflowTypeInterface extends PluginWithFormsInterface, DerivativeInspectionInterface, ConfigurablePluginInterface {
   
   @@ -121,45 +121,6 @@ public function decorateTransition(TransitionInterface $transition);
   -  public function buildStateConfigurationForm(FormStateInterface $form_state, WorkflowInterface $workflow, StateInterface $state = NULL);
   ...
   -  public function buildTransitionConfigurationForm(FormStateInterface $form_state, WorkflowInterface $workflow, TransitionInterface $transition = NULL);
   

   👍

6. +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeConfigureForm.php
   @@ -0,0 +1,37 @@
   +class ComplexTestTypeConfigureForm extends WorkflowTypeConfigureFormBase {
   
   +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeStateForm.php
   @@ -0,0 +1,29 @@
   +class ComplexTestTypeStateForm extends WorkflowTypeStateFormBase {
   
   +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeTransitionForm.php
   @@ -0,0 +1,29 @@
   +class ComplexTestTypeTransitionForm extends WorkflowTypeTransitionFormBase {
   

   Perhaps an @see \Drupal\workflow_type_test\Plugin\WorkflowType\ComplexTestType here?

7. +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Plugin/WorkflowType/ComplexTestType.php
   @@ -17,9 +15,14 @@
   + *   forms = {
   + *     configure = "\Drupal\workflow_test_type\Form\ComplexTestTypeConfigureForm",
   + *     state = "\Drupal\workflow_test_type\Form\ComplexTestTypeStateForm",
   + *     transition = "\Drupal\workflow_test_type\Form\ComplexTestTypeTransitionForm",
   + *   }
   

   ❤️

1. +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeConfigureForm.php
   @@ -8,6 +8,8 @@
   + * @see \Drupal\workflow_type_test\Plugin\WorkflowType\ComplexTestType
   
   +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeStateForm.php
   @@ -8,6 +8,8 @@
   + * @see \Drupal\workflow_type_test\Plugin\WorkflowType\ComplexTestType
   
   +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeTransitionForm.php
   @@ -8,6 +8,8 @@
   + * @see \Drupal\workflow_type_test\Plugin\WorkflowType\ComplexTestType
   

   You added these, but I think you also want this for the content_moderation @WorkflowType plugin.

2. +++ b/core/modules/content_moderation/src/Plugin/WorkflowType/ContentModeration.php
   @@ -29,9 +27,13 @@
   + *   forms = {
   + *     "configure" = "\Drupal\content_moderation\Form\ContentModerationConfigureForm",
   + *     "state" = "\Drupal\content_moderation\Form\ContentModerationStateForm"
   + *   },
   

   So content_moderation does not have a transition form, right?

P.S.: pinged @tim.plunkett :)

+++ b/core/modules/workflows/src/Form/WorkflowEditForm.php
@@ -213,12 +247,16 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
+        ->submitConfigurationForm($form['type_settings'], $subform_state, $workflow);

+++ b/core/modules/workflows/src/Form/WorkflowStateAddForm.php
@@ -101,6 +146,15 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
+        ->submitConfigurationForm($form['type_settings'], $subform_state, $workflow_type->getState($form_state->getValue('id')));

+++ b/core/modules/workflows/src/Form/WorkflowStateEditForm.php
@@ -138,6 +185,15 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
+        ->submitConfigurationForm($form['type_settings'], $subform_state, $workflow_type->getState($this->stateId));

+++ b/core/modules/workflows/src/Form/WorkflowTransitionAddForm.php
@@ -136,6 +176,15 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
+        ->submitConfigurationForm($form['type_settings'], $subform_state, $workflow_type->getTransition($form_state->getValue('id')));

+++ b/core/modules/workflows/src/Form/WorkflowTransitionEditForm.php
@@ -141,6 +182,16 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
+        ->submitConfigurationForm($form['type_settings'], $subform_state, $transition);

+++ b/core/modules/workflows/src/Plugin/WorkflowTypeConfigureFormBase.php
@@ -0,0 +1,51 @@
+  public function submitConfigurationForm(array &$form, FormStateInterface $form_state, WorkflowInterface $workflow = NULL) {

+++ b/core/modules/workflows/src/Plugin/WorkflowTypeStateFormBase.php
@@ -0,0 +1,55 @@
+  public function submitConfigurationForm(array &$form, FormStateInterface $form_state, StateInterface $state = NULL) {

+++ b/core/modules/workflows/src/Plugin/WorkflowTypeTransitionFormBase.php
@@ -0,0 +1,55 @@
+  public function submitConfigurationForm(array &$form, FormStateInterface $form_state, TransitionInterface $transition = NULL) {

+++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeConfigureForm.php
@@ -0,0 +1,39 @@
+  public function submitConfigurationForm(array &$form, FormStateInterface $form_state, WorkflowInterface $workflow = NULL) {

The third parameters of submitConfigurationForm seem wrong to me. Are those really required? I'm not sure, but in the case of passing $workflow ($this->entity), it should be retrievable as $form_state->getFormObject()->getEntity()...

One alternative might be to set the state and transition into $form_state instead, and perhaps provide protected methods on the base forms for getState(), getTransition(), getWorkflow() which derive those values from the $form_state and $form_state->getFormObject()->getEntity() as you suggest.

This sounds like a good approach

1. +++ b/core/modules/workflows/src/Form/WorkflowEditForm.php
   @@ -184,12 +212,14 @@ public function form(array $form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('configure')) {
   ...
   +        ->createInstance($workflow_type, 'configure')
   
   @@ -201,9 +231,13 @@ public function form(array $form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('configure')) {
   ...
   +        ->createInstance($workflow_type, 'configure')
   
   @@ -213,12 +247,16 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('configure')) {
   ...
   +        ->createInstance($workflow_type, 'configure')
   
   +++ b/core/modules/workflows/src/Form/WorkflowStateAddForm.php
   @@ -42,11 +73,15 @@ public function form(array $form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   @@ -86,12 +121,23 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   @@ -101,6 +147,16 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   +++ b/core/modules/workflows/src/Form/WorkflowStateEditForm.php
   @@ -62,10 +93,15 @@ public function form(array $form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   @@ -125,10 +161,22 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   @@ -138,6 +186,15 @@ protected function copyFormValuesToEntity(EntityInterface $entity, array $form,
   +    if ($workflow_type->hasFormClass('state')) {
   ...
   +        ->createInstance($workflow_type, 'state')
   
   +++ b/core/modules/workflows/src/Form/WorkflowTransitionAddForm.php
   @@ -62,10 +93,15 @@ public function form(array $form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('transition')) {
   ...
   +        ->createInstance($workflow_type, 'transition')
   
   @@ -128,6 +161,13 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('transition')) {
   ...
   +        ->createInstance($workflow_type, 'transition')
   
   @@ -136,6 +176,16 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass('transition')) {
   ...
   +        ->createInstance($workflow_type, 'transition')
   

   If configure, state and transition have special meaning - should we make them constants. Nothing worse than loosing an hour to a typo.

2. +++ b/core/modules/workflows/src/Form/WorkflowTransitionEditForm.php
   @@ -21,6 +24,32 @@ class WorkflowTransitionEditForm extends EntityForm {
   +   * The plugin form factory.
   +   *
   +   * @var \Drupal\Core\Plugin\PluginFormFactoryInterface
   +   */
   +  protected $pluginFormFactory;
   +
   +  /**
   +   * Creates an instance of WorkflowStateEditForm.
   +   *
   +   * @param \Drupal\Core\Plugin\PluginFormFactoryInterface $pluginFormFactory
   +   *   The plugin form factory.
   +   */
   +  public function __construct(PluginFormFactoryInterface $pluginFormFactory) {
   +    $this->pluginFormFactory = $pluginFormFactory;
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public static function create(ContainerInterface $container) {
   +    return new static(
   +      $container->get('plugin_form.factory')
   +    );
   +  }
   

   We add this three times - case for am abstract base class that sits above EntityForm?

3. +++ b/core/modules/workflows/src/Plugin/WorkflowTypeConfigureFormBase.php
   @@ -0,0 +1,51 @@
   + * The content moderation WorkflowType configuration form.
   

   is this correct?

1. Agreed that using the constants in the annotations is perhaps too verbose.
2. #46 is now using the constants for hasFormClass() calls. But we're still doing $form_state→get('some_string'). Why not use the constants there too?

3. +++ b/core/modules/workflows/src/Annotation/WorkflowType.php
   @@ -50,4 +50,20 @@ class WorkflowType extends Plugin {
   +   * @see \Drupal\Core\Plugin\PluginWithFormsInterface
   +   * @see \Drupal\Core\Plugin\PluginFormInterface
   +   * @see \Drupal\workflows\Plugin\WorkflowTypeConfigureFormBase
   +   * @see \Drupal\workflows\Plugin\WorkflowTypeStateFormBase
   +   * @see \Drupal\workflows\Plugin\WorkflowTypeTransitionFormBase
   

   Perhaps now also @see the constants?

4. +++ b/core/modules/workflows/src/Form/WorkflowEditForm.php
   @@ -17,6 +19,32 @@
      /**
   +   * The plugin form factory.
   +   *
   +   * @var \Drupal\Core\Plugin\PluginFormFactoryInterface
   +   */
   +  protected $pluginFormFactory;
   +
   +  /**
   +   * Creates an instance of WorkflowStateEditForm.
   +   *
   +   * @param \Drupal\Core\Plugin\PluginFormFactoryInterface $pluginFormFactory
   +   *   The plugin form factory.
   +   */
   +  public function __construct(PluginFormFactoryInterface $pluginFormFactory) {
   +    $this->pluginFormFactory = $pluginFormFactory;
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public static function create(ContainerInterface $container) {
   +    return new static(
   +      $container->get('plugin_form.factory')
   +    );
   +  }
   +
   

   In #46.2, you say that you don't think a base class is a good idea. An alternative could be a trait.

#46 will also need a review from Tim Plunkett for #40.

In #46.2, you say that you don't think a base class is a good idea. An alternative could be a trait.

None of our traits in core container a constructor, let's keep it that way cause the DX of extending and calling the parent is naff with a trait.

Let's open a follow up to discuss if its worth adding a base class, can be done later.

Any ideas on where we'd put these? These seem kind of implementation specific, it doesn't feel like they belong on an interface.

Perhaps move the existing three constants off WorkflowTypeInterface onto their respective interfaces?

TransitionInterface::PLUGIN_FORM
StateInterface::PLUGIN_FORM
WorkflowInterface::PLUGIN_FORM

or could name them PLUGIN_FORM_KEY so its more explicit.

Will ping timplunkett to chase that re-review

1. +++ b/core/modules/workflows/src/Plugin/WorkflowTypeConfigureFormBase.php
   @@ -0,0 +1,50 @@
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function validateConfigurationForm(array &$form, FormStateInterface $form_state) {
   +  }
   +
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function submitConfigurationForm(array &$form, FormStateInterface $form_state) {
   +  }
   

   It's not common to provide an empty build or submit method. No reason to subclass if you don't have form elements to return or submit.

2. +++ b/core/modules/workflows/src/Plugin/WorkflowTypeStateFormBase.php
   @@ -0,0 +1,55 @@
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
   +  }
   

   Same here. The corresponding submit method in this class isn't empty, so the build shouldn't be either.

3. +++ b/core/modules/workflows/src/Plugin/WorkflowTypeTransitionFormBase.php
   @@ -0,0 +1,55 @@
   +  /**
   +   * {@inheritdoc}
   +   */
   +  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
   +  }
   

   And again

4. +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeStateForm.php
   @@ -0,0 +1,31 @@
   +  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
   ...
   +    $form = [];
   

   No need to empty out $form here

5. +++ b/core/modules/workflows/tests/modules/workflow_type_test/src/Form/ComplexTestTypeTransitionForm.php
   @@ -0,0 +1,31 @@
   +  public function buildConfigurationForm(array $form, FormStateInterface $form_state) {
   ...
   +    $form = [];
   

   Same

The rest of the PWFI changes are great.
I have no opinion on constants vs magic strings in this case.
I agree that a trait is harmful here, and don't think a base class would be much help. Boilerplate is boilerplate.

Both (#56 and #58) failures are segfaults in garbage collector.

I've taken a look at the code and manually tested, looks good to me.

Not sure I'm qualified to RTBC, but +1 from me.

1. +++ b/core/modules/content_moderation/src/Form/ContentModerationConfigureForm.php
   @@ -0,0 +1,136 @@
   +          'label' => ['#markup' => '<strong>' . $this->t('@bundle types', ['@bundle' => $entity_type->getLabel()]) . '</strong>'],
   ...
   +            '#prefix' => '<br/><span id="selected-' . $entity_type->id() . '">',
   ...
   +            '#suffix' => '</span>',
   

   Not used to seeing markup concatenated like this anymore, could this instead use '#type' => 'inline_template'?

2. +++ b/core/modules/content_moderation/src/Plugin/WorkflowType/ContentModeration.php
   @@ -375,68 +347,4 @@ public function getInitialState(WorkflowInterface $workflow, $entity = NULL) {
   -          'label' => ['#markup' => '<strong>' . $this->t('@bundle types', ['@bundle' => $entity_type->getLabel()]) . '</strong>'],
   -          'selected' => [
   -            '#prefix' => '<br/><span id="selected-' . $entity_type->id() . '">',
   -            '#markup' => !empty($selected_bundles) ? implode(', ', $selected_bundles) : $this->t('none'),
   -            '#suffix' => '</span>',
   

   I see that it's copied from another place, and not changed in this issue. Can someone open a follow-up to fix this?

Still needs a change record, but marking RTBC for the patch itself.

You linked this issue instead, I believe you meant #2898886: ContentModerationConfigureForm should use inline list in place of concatenated markup. Thanks for opening it!

1. +++ b/core/modules/content_moderation/src/Form/ContentModerationConfigureForm.php
   @@ -0,0 +1,136 @@
   +              'title' => $this->t('Select'),
   

   Again I realise this is just being moved from elsewhere, but this needs a follow-up for a11y, there is no context to the link for a screen reader. Needs to the entity type and the workflow labels into a hidden span.

2. +++ b/core/modules/workflows/src/Form/WorkflowTransitionAddForm.php
   @@ -128,6 +161,13 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass(TransitionInterface::PLUGIN_FORM_KEY)) {
   
   @@ -136,6 +176,17 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    if ($workflow_type->hasFormClass(TransitionInterface::PLUGIN_FORM_KEY)) {
   

   I love that this solved the issue without needing to use instanceof

Committed as f7f742e and pushed to 8.5.x.

Cherry-picked as 65b9f1f and pushed to 8.4.x

@Sam152 can you make those change record changes?

See you in #2843494: WI: Workflows module roadmap

After running updates and rebuilding caches, I'm still getting some issues that seem related to this:

Working fine on HEAD for me @plach - see https://d2ghq.ply.st/ (23hrs to go).

Did you reinstall?

@Sam152 pointed me towards #2896630: Unofficial content_moderation 8.3.7 to 8.4.0 upgrade path for an upgrade path if you don't have the option of reinstall.

I was just testing in my local dev env, I forgot we don't support an upgrade path yet for CM, sorry for the noise :)

Per #70.

Updated CR to clarify impact: https://www.drupal.org/node/2897706/revisions/view/10586340/10586346.