TypeError: WorkflowTransitionElement::copyFormValuesToTransition() (line 356) when hiding subfields

Created on 14 June 2024, 14 days ago
Updated 18 June 2024, 10 days ago

Problem/Motivation

Trying to create a new Node from a content type, after filling up all fields including "To State" field and "Log message", then proceeding to save it, It throws a WSOD:

TypeError: Cannot access offset of type string on string in Drupal\workflow\Element\WorkflowTransitionElement::copyFormValuesToTransition() (line 356 of modules/contrib/workflow/src/Element/WorkflowTransitionElement.php).

Steps to reproduce

Setup workflows as normal, then add a new node, fill up everything, and then save

Steps to fix?

I was fiddling around when i found the error i encountered in #4. To further try to fix this, i tried to do these, which ended up "fixing" the issue:

  1. Navigating to the workflow settings (/admin/config/workflow/workflow/workflow_name)
  2. In "Workflow form settings" - Disable fieldset/No fieldset option, then
  3. "Show available states" - Select list
  4. Navigating to "Manage form display of the workflow" (/admin/config/workflow/workflow/workflow_name/form-display)
  5. Disable "To state", "Timestamp", and "Log message"
  6. Navigate to content type where the Workflow is attached, then go to "Manage form display"
  7. Set the Widget of the Workflow to "Select list" then save.
  8. Retry adding/updating the node, it will save without any issues.
🐛 Bug report
Status

Needs review

Version

1.8

Component

Code

Created by

🇵🇭Philippines iaacristobal Manila

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

Merge Requests

Comments & Activities

  • Issue created by @iaacristobal
  • 🇵🇭Philippines iaacristobal Manila

    I'm encountering an issue applying the patch. It's returning this error on my end:

    patch: **** Only garbage was found in the patch input.
    
       Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2024-06-07/workflow_3452716_8_undefined_key.patch

    I applied this using composer-patches.

  • 🇵🇭Philippines iaacristobal Manila

    Additionally, i also noticed this. The states are redundant, we have one on the "Edit" tab (How to show the available states), and also one on the "Manage form display tab" (To state). When the "To state" field is shown, It's the one who throws the error i have described in the title. But when i disable it, the states from the "Edit" tab show, but saving the node will throw the following errors:

    Warning: Undefined array key 0 in Drupal\workflow\Element\WorkflowTransitionElement::copyFormValuesToTransition() (line 356 of modules/contrib/workflow/src/Element/WorkflowTransitionElement.php).

    Warning: Trying to access array offset on value of type null in Drupal\workflow\Element\WorkflowTransitionElement::copyFormValuesToTransition() (line 356 of modules/contrib/workflow/src/Element/WorkflowTransitionElement.php).

    Error: content [node id] has no workflow attached. The data is not saved.

    This value should not be null.

  • 🇵🇭Philippines iaacristobal Manila
  • 🇵🇭Philippines iaacristobal Manila
  • First commit to issue fork.
  • Pipeline finished with Success
    14 days ago
    Total: 143s
    #198610
  • Status changed to Needs review 14 days ago
  • 🇳🇱Netherlands johnv

    Regarding comment #4:
    Indeed, in /admin/config/workflow/workflow/TYPE, the states are redundant. This is since the elements of the Transition are made customizable. The one in 'Manage form display' should be hidden, and the settings should not be used. I will open a ticket for that.

    (Note: There is another issue requesting to have such settings on field basis, not on Workflow basis.)

    The steps in 'Steps to fix?' are not to be used IMO. The result will be that you only change the state., without scheduling or comments. For that, you can just use the widget on the node, setting it from TransitionForm to Select.

  • 🇳🇱Netherlands johnv

    Regarding MR #8.
    Thanks for the contribution.
    It seems it is not against latest version. Latest Dev Version is 1.8 + 4 patches.
    In the first part (setting fieldnams/sid to NULL), that is already assured in latest commits.
    In the second part, I see that some data is missed, when elements are hidden in the Workflow Settings.
    Please check attached patch. Sorry for not having learned how MR's work.

  • 🇳🇱Netherlands johnv
  • 🇳🇱Netherlands johnv

    Question: are you experiencing this in a new install, or after the upgrade to version 1.8?

    • johnv committed 3b6f25e5 on 8.x-1.x
      Issue #3454558 by immaculatexavier, johnv, iaacristobal: TypeError:...
  • 🇳🇱Netherlands johnv

    I assume the provided patch is OK.
    Also, a comment is placed on the 'Manage form display' page, hinting to the unexpected behaviour.
    Until now, I did not make that page prevalent, since:
    - is does not support 'required'
    - needs backporting existing installations
    - does not support the 'per formatter' settings.

    Please test current dev version and report back if the error has gone in all situations.
    I will try to create a new version soon.

  • 🇵🇭Philippines iaacristobal Manila

    #15 - I am yet to test the patch in #11 as it is currently an awkward time in my country to test right now, i will be back with a proper result for later

  • 🇵🇭Philippines iaacristobal Manila

    Okay so, i can't apply the patch file again for some reason, both in dev and in current 8.x, so i cloned the 8.x-1.x branch to my test environment, but i am now encountering a new problem:

    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).

    This error happens as when creating a node or updating a node using the "To state" field found in the manage form display section

    I setup a new user for this as well to test if it is an admin-only problem but the same problem exists.

Production build 0.69.0 2024