Error when creating a node with other multiple value field

Hi @dcoppel,
I followed the steps you mentioned but didn't got any error, could you please elaborate the steps you mentioned.

Thanks,
Arun

I did not try to replicatie to problem, yet. It seems identical to a problem i had in another of my modules:
#3422607: office_hours.js hides other [Add] buttons in widget

And #3455636: Use not-randomized drupal-data-selector, not #id

Regarding #7:
the dpm is OK, it is a develoment tool, and secured against misuse.
for the deprecation, I created #3513847: RenderElement and FormElement base plugin classes are deprecated in 10.3 and removed in 12.0, but postponed until later.

I can reproduce, after reading OP carefully.
- create/use a node type with a workflow field as described above.
- Add an unlimited 'Text (plain)' field
- create a new node
- press [Add another item]

Coming from #3508337: Workflow doesn't recognize state change first time I noticed a seemingly related error when simply creating a new node with a Workflow field. I note a change in the behaviour of the module, where the "Change State" widget (in my case, we use radio buttons) no longer populates an initial option value for the state. Instead those radio buttons are empty, and then saving the node results in the following error:

The website encountered an unexpected error. Try again later.

TypeError: Drupal\Core\Field\WidgetBase::errorElement(): Argument #1 ($element) must be of type array, null given, called in /var/www/html/web/core/lib/Drupal/Core/Field/WidgetBase.php on line 580 in Drupal\Core\Field\WidgetBase->errorElement() (line 646 of core/lib/Drupal/Core/Field/WidgetBase.php).

Drupal\Core\Field\WidgetBase->flagErrors() (Line: 277)
Drupal\Core\Entity\Entity\EntityFormDisplay->flagWidgetsErrorsFromViolations() (Line: 268)
Drupal\Core\Entity\ContentEntityForm->flagViolations() (Line: 214)
Drupal\Core\Entity\ContentEntityForm->validateForm()
call_user_func_array() (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers() (Line: 274)
Drupal\Core\Form\FormValidator->doValidateForm() (Line: 118)
Drupal\Core\Form\FormValidator->validateForm() (Line: 593)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
... snip ...

I've also noticed that even if I do select a radio button option, but then save the form and the form validation fails for some reason, the option I'd selected is not retained, and the radio buttons are empty once again, so the problem persists. I can imagine this would be related to the OP symptoms, because the AJAX call when "Add a new item" will attempt to rebuild the form and thus likely trigger the same code path that clears (or never populates?) the state options. Hope that helps!

Please try again. I fixed a typo 'from_state' vs. 'to_state'.

thanks for your better testing: do not test 0, 1 or 2, but also 3 times|
The cache was not properly updated, resulting an infinite recursive call.
Please try again.

No, that should not be the case. But I see our posts crossed. I Will take a look.

What do you mean with base field? Do you add the field programmatically to a programmed entity? Or as a normal field via field UI?

@dcoppel, please test again.
Thoroughly, since the patch is bigger than expected. It also uncovered an incorrect workfllowSate::create().
Thanks for all your feedback and patience!

@johnv: Just made it back to review this issue today, and see if it resolves the issue in our project. Unfortunately, I can confirm I'm seeing the same error on the latest dev- branch that @dcoppel reported above (this is in my clean test environment with a simple node type, 1 workflow with 3 states):

The website encountered an unexpected error. Try again later.

TypeError: workflow_node_current_state(): Argument #1 ($entity) must be of type Drupal\Core\Entity\EntityInterface, null given, called in /var/www/html/web/modules/contrib/workflow/src/Entity/WorkflowTransition.php on line 854 in workflow_node_current_state() (line 420 of modules/contrib/workflow/workflow.module).

Drupal\workflow\Entity\WorkflowTransition::getDefaultStateId()
call_user_func() (Line: 442)
Drupal\Core\Field\BaseFieldDefinition->getDefaultValue() (Line: 169)
Drupal\Core\Field\FieldItemList->applyDefaultValue() (Line: 271)
Drupal\Core\Entity\ContentEntityStorageBase->initFieldValues() (Line: 129)
Drupal\Core\Entity\ContentEntityStorageBase->doCreate() (Line: 94)
Drupal\Core\Entity\ContentEntityStorageBase->create() (Line: 1172)
Drupal\Core\Entity\ContentEntityBase::create() (Line: 203)
Drupal\workflow\Entity\WorkflowTransition::create() (Line: 292)
Drupal\workflow\Plugin\Field\FieldType\WorkflowItem->getTransition() (Line: 298)
Drupal\workflow\Entity\WorkflowTargetEntity::getTransition() (Line: 81)
Drupal\workflow\Form\WorkflowTransitionForm::createInstance() (Line: 106)
Drupal\workflow\Plugin\Field\FieldWidget\WorkflowDefaultWidget->formElement() (Line: 459)

Please try again.
Sorry for the big commits, hiding the real changes.

I will wait for spiderman's feedback and then create a new version.

I have some off-topic questions for this co-operative crowd:
- This module lacks tests. Do you have any automated tests to share in #893294: Implement tests?
- The attraction for this module is dropping, apparently since core has its 'Workflows' module. You are (still) using this module. You might want to share insights in #2852293: Comparing Workflow with Content Moderation+Workflows in core

@johnv: I'm happy to report that as of the latest dev-branch today, this bug has gone away, and the intermediate error is no longer. Thanks for your continued efforts! in terms of your questions, happy to give some feedback on the linked issues :)

@dcoppel: I don't see what you're describing in my "clean" environment, but I also don't have any file fields or the like, it's just a very simple setup for testing workflow. I tried quickly adding a filefield and a multi-value textfield, but can't reproduce what you describe. I can add both a new textfield value, upload a file, and save the new workflow state without problems. I'm guessing something else in your setup is complicating matters. fwiw, I'm about to bring this into the client project using Workflow, which is a much more complicated content model. I'll report back here if I see any issues there :)

@decoppel, I can also not reproduce your problem, using the following script
- set 'action buttons' to Workflow config, make sure some transitions have a custom label
- create a node, add 2 files and 2 text items, press action button to save
- edit the node, repeat above.
I always see label(s), and node gets committed each time first time

Cannot reproduce on 'Workflow history tab', since the node fields are not on that page.
Cannot reproduce on 'node view' page for the same reason.

@johnv, @dcoppel: I am now seeing the buggy behaviour you're describing! It came up in tests from my client project, where we have an instance that I think has the same conditions you're seeing. We have 2 separate "Add another item" steps on 2 different multi-value entityreference (autocomplete) fields on the form. When I comment out both steps in my test, the Workflow state is created normally. When I leave *one* of the "Add another item" steps in, the Workflow state is created normally.

However, if I have *two* "Add another item" steps, then things fail quietly. The form saves correctly in my case, because I'm also using Workflow Save as Draft module, but it appears no workflow transition has been created. This strikes me as connected to the custom labels going away on the second load, seems like maybe a subtle bug in the form builder/ajax callbacks or something, that's losing track of the form_state value somewhere along the way.

I'm going to see if I can reproduce this in my "clean" environment, just adding some simple fields to my existing "test workflow" node type. I'm guessing Workflow Save as Draft is not a factor, but I'll leave it out deliberately to try and narrow down the STR conditions.

Nice! Does the error log report not give a message?

Ok confirmed this behaviour in my test environment (Workflow Save as Draft NOT installed). Steps to reproduce:

1. Add a multi-value text field (I only needed one) with unlimited values to your node type with a workflow attached.
2. Go to node/add/workflow-node
3. Enter a title, and a first text value in your text field.
4. Click "Add another item" and enter a second text value.
5. Click "Add another item" *again*, and enter a third text value.
6. Click Save.
7. Go to the Workflow tab, and observe no Creation -> State1 transition exists.

If I leave out step 5, everything's fine, so it seems to be something about the *second* AJAX call that trips things up. I've no idea where to look from there, but hopefully that gives you a clue @johnv! Let us know if you need more information or can't reproduce- it feels like we're *very* close to resolving this cluster of bugs, and I'd love to see it done :)

Working on this.
I have an unlimited txt field and an unlimited file field.
Adding multiple texts, then save, indeed does not seem to save the initial transition.
In FormSubmitter::ExecuteSubmitHandlers(), the handels is "file_managed_file_submit", which is not used at all in my case.

In FormBuilder::doBuildForm(), the following happens:

      // If a form contains a single textfield, and the ENTER key is pressed
      // within it, Internet Explorer submits the form with no POST data
      // identifying any submit button. Other browsers submit POST data as
      // though the user clicked the first button. Therefore, to be as
      // consistent as we can be across browsers, if no 'triggering_element' has
      // been identified yet, default it to the first button.
      $buttons = $form_state->getButtons();
      if (!$form_state->isProgrammed() && !$form_state->getTriggeringElement() && !empty($buttons)) {
        $form_state->setTriggeringElement($buttons[0]);
      }

      $triggering_element = $form_state->getTriggeringElement();

@johnv: Glad to hear you're working on it, and hope you're making progress! I'm not sure I understand the implications of your last couple of comments, but that section of code where the comment mentions accommodating buggy IE behaviour *does* seem suspicious, although I don't really understand how it connects to Workflow's code exactly- but I have the feeling you're on the right track!

It strikes me that the specificity of this behaviour might be a clue: the problem *only* seems to happen with *certain kinds* of AJAX calls- a file upload button or an "add another item", but not others (an entityreference autocomplete widget doesn't seem to trigger it). I assume there is something different happening in those kinds of AJAX calls that is affecting the section of the $form array Workflow cares about.

I almost wonder if it's the *first* AJAX call that's creating the problem- somehow omitting something from the $form it returns back to the DOM, and then the second one solidifies the error so that the final POST never sees the relevant Workflow data?

Anyway, I'll continue to watch here for updates, and happily test again when you have something to try :)

If you don't mind, i will treat it as an edge case and a core issue for now. And will focus on getting a release 2.0.0 out.

Renaming the issue.

@johnv: I gather you've had a hard time getting to bottom of this strange behaviour as well. Can I suggest perhaps closing this issue and treating the special case as a separate one? After all, you did fix *part* of the bug here, and the original symptom as reported :)

fwiw, I'm still planning to spend some time adding a test harness to this module in the next couple weeks hopefully. If I have bandwidth, I'll try to take another look at this one, and at least add a test to illustrate the failure.

I realize this issue discussed more then one topic.
So, Indeed, it iseems best to close (and re-rename) this issue and regard only the original problem . Then the submit problem deserves a new issue.

ITMT, upon your next module update, please run update.php and test the history view.

Please try latest dev version.
It contains less custom code in the processing of (attached) fields.

Latest dev should now really make WorkflowWidget behave as any other widget.