Drupal\Core\Field\WidgetBase::errorElement()

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:
🐛 office_hours.js hides other [Add] buttons in widget Fixed

And 📌 Use not-randomized drupal-data-selector, not #id Fixed

I try to precise things.
When you click on Add a new element button of a multiple text field, loading turn and no new text element appears... and a message appears up to the form : Oops, something went wrong. Check your browser's developer console for more details.

The original error message is visible only in logs of drupal with this 3 warnings :

Warning : Undefined array key "original_deltas" dans Drupal\Core\Field\WidgetBase->flagErrors() (web/core/lib/Drupal/Core/Field/WidgetBase.php line 576)
Warning : Trying to access array offset on value of type null dans Drupal\Core\Field\WidgetBase->flagErrors() (web/core/lib/Drupal/Core/Field/WidgetBase.php ligne 576)
Warning : Undefined array key "" dans Drupal\Core\Field\WidgetBase->flagErrors() (web/core/lib/Drupal/Core/Field/WidgetBase.php line 577)

I have this issue since workflow changed from v1.7 to v1.8.

To improve module, I can relay this 3 informations too return by a scan result :
web/modules/contrib/workflow/src/Entity/WorkflowTransition.php 1182 Calls to function dpm should not exist.

web/modules/contrib/workflow/src/Element/WorkflowTransitionElement.php 22 Class Drupal\workflow\Element\WorkflowTransitionElement extends deprecated class Drupal\Core\Render\Element\FormElement. Deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. use Drupal\Core\Render\Element\FormElementBase instead.

web/modules/contrib/workflow/src/Element/WorkflowTransitionTimestamp.php 19 Class Drupal\workflow\Element\WorkflowTransitionTimestamp extends deprecated class Drupal\Core\Render\Element\FormElement. Deprecated in drupal:10.3.0 and is removed from drupal:12.0.0. use Drupal\Core\Render\Element\FormElementBase instead.

Regarding #7:
the dpm is OK, it is a develoment tool, and secured against misuse.
for the deprecation, I created 📌 RenderElement and FormElement base plugin classes are deprecated in 10.3 and removed in 12.0 Postponed , 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 🐛 Workflow doesn't recognize state change first time Active 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.

Hi, Thanks for your work !

I just tested. If I click on "Add a new element" button on my multiple text field, it works now !

Nevertheless, if after I add a file in a file field of the same form, it doesn't works..... (ajax loading never end and message "Oops, something went wrong. Check your browser's developer console for more details" appears => ajax request return 500)

I did the test by load the file first (it works !) then click on "Add a new element" button on my multiple text field and same issue process => (ajax loading never end and message "Oops, something went wrong. Check your browser's developer console for more details" appears => ajax request return 500)

So it works the first time but not after...

There's not much missing I think !

I saw that field base on a workflow contains now the workflow transition label value and no more the workflow state value. Is is something normal ?

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?

Hi, it's ok now with the last dev version ! Thanks a lot !!!

Just to inform you that the issue with status value of node field link to my workflow is still existing.
When I display this field value on a node list view, all of node status value are one of my transition label instead of one on my state value.
If you can check this point please ?

@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!

Now my status state came back to normal thanks !

Nevertheless, I have a new issue when accessing to my node form with error :
TypeError : workflow_node_current_state(): Argument #1 ($entity) must be of type Drupal\Core\Entity\EntityInterface, null given, called in web/modules/contrib/workflow/src/Entity/WorkflowTransition.php on line 854 in workflow_node_current_state() (line 420 of web/modules/contrib/workflow/workflow.module).

Thanks to give your time on those issues !

@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 just tried and issue disappears !!!! Thanks a lot !
The only things I need now is a version stable 1.9 to put it on production !!!
Thanks again !

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: Add 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 💬 Is Workflow redundant now that Content Moderation+Workflows is in core? Active

Sorry I have no automated tests.
I just shared my feeling regarding this module as you asked on the dedicated space !
I hope this module will still live as I love it ! Thanks for you great job support !

Just a little thing : when I press on an action button of my workflow node field, I need to press twice on my action button to valid my node form. The first press, just refresh my form (without loosing my filled datas) and then the second press valid my form (I have no log error about the first press ?) It arrive only when I add a new value in my multiple field text and then an attached file in my node file field. If I do just one of this two things, I need just one press to valid form.
Do you have the same things with this kind of test ?

@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 :)

Regarding the last problem I saw and explaned in #32, the first form load display my actions buttons with specific transitions label I configured in my workflow parameters. And the anormal second load form after first submittion displayed my actions button without my custom transition labels. I don't know if it can help...

@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?

I did an other simple test with a form with only a title, one muti value text and one file field and my workflow field (actions buttons).
I edit a node by adding two value of my text field and add one file. I press one of my action button, the form reload and I loose one of my text value. The second press on action button submit form correctly.
I saw no errors in console and log of drupal. Hope it helps !

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.

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.