With a multipage form, using a computed token field containing a token for a 'Select Other element', get the following error:

Warning: Array to string conversion in Drupal\webform\Utility\WebformOptionsHelper::getOptionText() (line 131 of modules\contrib\webform\src\Utility\WebformOptionsHelper.php).

Drupal\webform\Utility\WebformOptionsHelper::getOptionText(Array, Array, ) (Line: 411)
Drupal\webform\Plugin\WebformElement\OptionsBase->formatTextItem(Array, Object, Array) (Line: 1374)
Drupal\webform\Plugin\WebformElementBase->format('Text', Array, Object, Array) (Line: 1331)
Drupal\webform\Plugin\WebformElementBase->formatText(Array, Object, Array) (Line: 234)
Drupal\webform\Plugin\WebformElementManager->invokeMethod('formatText', Array, Object, Array) (Line: 1073)
_webform_token_get_submission_value('field_610', Array, Object, Object, Object) (Line: 743)

Changing the field to a standard Select (without Other), the error goes away.

CommentFileSizeAuthor
#26 diff.png220.67 KBodensc
#6 webform.webform.issue_3350275.yml5.91 KBjrockowitz

Issue fork webform-3350275

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

alangallery created an issue. See original summary.

cilefen’s picture

cilefen commented
Issue summary: View changes

Please provide the yaml of a minimal form that exhibits the bug.

alangallery’s picture

alangallery commented

Thanks cilefen

Creating a simple multi-paged test form with select other element didn't give errors, but adding a conditional visibility to the select other element did. So it seems to be related to having conditions in the form.

The form I'm creating has lots of visibility/required conditions on elements, but not actually on the select other element.

Minimal form with bug:

first_page:
  '#type': wizard_page
  '#title': 'First page'
  standard_select_question:
    '#type': select
    '#title': 'Standard select question'
    '#options': yes_no
    '#required': true
second_page:
  '#type': wizard_page
  '#title': 'Second page'
  do_you_want_to_answer_the_next_question:
    '#type': select
    '#title': 'Do you want to answer the next question'
    '#options': yes_no
  select_with_other_question:
    '#type': select_other
    '#title': 'Select with other question'
    '#options': yes_no
    '#other__option_label': Other
    '#other__placeholder': 'Please enter the answer'
    '#states':
      visible:
        ':input[name="do_you_want_to_answer_the_next_question"]':
          value: 'Yes'
third_page:
  '#type': wizard_page
  '#title': 'Third page'
  computed_tokens:
    '#type': computed_token
    '#title': 'Computed tokens'
    '#mode': text
    '#template': '"[webform_submission:values:standard_select_question]","[webform_submission:values:do_you_want_to_answer_the_next_question]","[webform_submission:values:select_with_other_question]"'
    '#store': true
alangallery’s picture

alangallery commented

Further information - if rendering token as raw value [webform_submission:values:select_with_other_question:raw]

Get two errors showing on form:
User error: "select" is an invalid render array key in Drupal\Core\Render\Element::children() (line 98 of core\lib\Drupal\Core\Render\Element.php).

User error: "other" is an invalid render array key in Drupal\Core\Render\Element::children() (line 98 of core\lib\Drupal\Core\Render\Element.php).

Both regarding the token [webform_submission:values:select_with_other_question:raw]

_webform_token_get_submission_value('select_with_other_question:raw', Array, Object, Object, Object) (Line: 743)
webform_tokens('webform_submission', Array, Array, Array, Object)
odensc’s picture

odensc
he/him
commented

I ran into this issue too. Doing some debugging with XDebug, it seems the error is coming from Drupal\webform\Plugin\WebformElement\OptionsBase::formatTextItem/formatHtmlItem. The call to getValue is returning an array of ["select" => [...], "other" => "..."] for some reason, but only when called from inside a computed token/computed twig field and when the select element is conditionally visible.

When the select element isn't conditional/when the token is in the confirmation page, it seems to be returning a string (either the option selected, or the value of the Other field), as expected.

I was able to do an ugly workaround by using a computed twig field, by detecting if it's an array and returning an empty string, otherwise computing the token:

{{ data.select_element is iterable ? '' : webform_token('[webform_submission:values:select_element]', webform_submission) }}

jrockowitz’s picture

jrockowitz commented
Version: 6.2.0-beta5 » 6.2.x-dev
StatusFileSize
new webform.webform.issue_3350275.yml5.91 KB

The attached webform replicates the issue using the elements from #3.

odensc opened merge request !469

odensc’s picture

odensc
he/him
commented
Status: Active » Needs review

@jrockowitz Thanks for the repro config.

I've submitted an MR with tests that fixes this issue. Interestingly, there was already code to handle a similar bug in OptionsBase::getElementSelectorInputValue, from issue #3000202. I pulled that code out to an overriden getValue function which should fix the bug for all code paths including OptionsBase::formatTextItem/formatHtmlItem mentioned above, which is the source of the error in this issue.

odensc’s picture

odensc
he/him
commented

We've now been using the fix in MR #469 in production for a month without any errors, and have been able to remove our workarounds. It'd be great if someone else could test and change this issue to RTBC!

jmaxant’s picture

jmaxant commented

Tested today, works on a clean install & ran "test-only changes" job, which shows coverage. Everything looks fine by me !
I'll change it to RTBC shortly if no one else does in the meantime.

jmaxant’s picture

jmaxant commented
Status: Needs review » Reviewed & tested by the community
liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Version: 6.2.x-dev » 6.3.x-dev
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll

Please reroll for 6.3.x.

odensc closed merge request !469

odensc opened merge request !543

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented

Thanks for the reroll.

There is no need to make a new merge request. You can just force-push to the branch of existing one.

odensc’s picture

odensc
he/him
commented
Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs reroll

Thanks for the tip, I tried a force push and changed the target branch of the MR to 6.3.x, but the MR was showing all of the changes from my fast-forward merge of 6.3.x in the diff for some reason and I couldn't get it to refresh.

Side note, the `WebformElementSignatureTest::testSignature` test is showing as a failure but it appears unrelated as the same thing is happening on other MRs.

odensc’s picture

odensc
he/him
commented

I rerolled the MR again and made a small change to use array_key_exists instead of isset to fix a rare edge-case where ['select' => null, 'other' => null] which can happen in some complex wizard forms with conditional _other fields.

@liam morland, Appreciate you taking the time to look at this issue earlier. Is there anything else I can do to get it in a mergeable state? Thanks!

nessollo’s picture

nessollo commented

I started to have this ussue after uprading core from 10.2 to 10.3.

Using Webform 6.2.3
Upgrading webform did not solved the problem

InvalidArgumentException: "select" is an invalid render array key. Value should be an array but got a string. in Drupal\Core\Render\Element::children() (linea 97 di /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Element.php).

#0 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(462): Drupal\Core\Render\Element::children()
#1 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#2 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(165): Drupal\Core\Render\Renderer->render()
#3 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}()
#4 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(164): Drupal\Core\Render\Renderer->executeInRenderContext()
#5 /var/www/crm/testing/crmdev.wikimedia.it/web/core/lib/Drupal/Core/Render/Renderer.php(174): Drupal\Core\Render\Renderer->renderInIsolation()
#6 /var/www/crm/testing/crmdev.wikimedia.it/web/modules/contrib/webform/webform.tokens.inc(1077): Drupal\Core\Render\Renderer->renderPlain()
#7 /var/www/crm/testing/crmdev.wikimedia.it/web/modules/contrib/webform/webform.tokens.inc(743): _webform_token_get_submission_value()
#8 [internal function]: webform_tokens()

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented

@#18 Does the patch in the merge request fix it for you?

nessollo’s picture

nessollo commented

Same issue here.
The problem started upgrading core from 10.2 to 10.3+

Upgrading core or webform did not solve the problem.

The issue affect only some form.

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Status: Reviewed & tested by the community » Needs work

Tests are not passing.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

@liam morland the test failure doesn't appear related, is there anyway to be sure that this is not an unrelated test failure (I've been seeing a bunch that I had to fix in my projects). I will re-run the test but I wonder if we can see branch tests too to confirm it's not related.

Webform Element Fieldset (Drupal\Tests\webform\Functional\Element\WebformElementFieldset)
✘ Fieldset
┐
├ UnexpectedValueException: RecursiveDirectoryIterator::__construct(/builds/project/webform/web/sites/simpletest/20218150/files/config_jlGIIYQXrRYiCCtLL3L6hUnoOMsAkNqPvbnQeB8Ff3Z7dmdA3f_Mi6wt8dXzixhMgaWDnJEIjw/sync): Failed to open directory: No such file or directory
│
│ /builds/project/webform/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php:169
│ /builds/project/webform/src/Plugin/WebformElementManager.php:77
│ /builds/project/webform/web/core/lib/Drupal/Component/DependencyInjection/Container.php:259
│ /builds/project/webform/web/core/lib/Drupal/Component/DependencyInjection/Container.php:177
│ /builds/project/webform/web/core/lib/Drupal/Component/DependencyInjection/Container.php:430
│ /builds/project/webform/web/core/lib/Drupal/Component/DependencyInjection/Container.php:463
│ /builds/project/webform/web/core/lib/Drupal/Core/Plugin/CachedDiscoveryClearer.php:55
│ /builds/project/webform/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php:353
│ /builds/project/webform/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php:229
│ /builds/project/webform/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php:83
│ /builds/project/webform/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:511
│ /builds/project/webform/web/core/tests/Drupal/Tests/BrowserTestBase.php:537
│ /builds/project/webform/web/core/tests/Drupal/Tests/BrowserTestBase.php:343
│ /builds/project/webform/tests/src/Functional/WebformBrowserTestBase.php:44
┴

ERRORS!
Tests: 1, Assertions: 0, Errors: 1, PHPUnit Deprecations: 2.

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented

The branch tests are passing now. I just re-ran the test to see if it passes this time.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Needs work » Reviewed & tested by the community

Ah thanks, well let's put this back to RTBC shall we ;) It wouldn't let me do the retest for some reason... maybe too used to the permissions on other modules

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented

I have rebased and tests are passing. The main thing this merge request is doing is creating OptionsBase::getValue(). It also changes OptionsBase::getElementSelectorInputValue() but I don't see anything in the comments on this issue explaining why that change is needed.

odensc’s picture

odensc
he/him
commented
StatusFileSize
new diff.png220.67 KB

Hi @liam morland:

Thanks for rebasing! Here's a description of the change from comment #8:

there was already code to handle a similar bug in OptionsBase::getElementSelectorInputValue, from issue #3000202. I pulled that code out to an overriden getValue function which should fix the bug for all code paths including OptionsBase::formatTextItem/formatHtmlItem mentioned above, which is the source of the error in this issue.

Basically, the change to OptionsBase::getElementSelectorInputValue is just moving some of its code into the new overloaded getValue function. Since getElementSelectorInputValue calls getRawValue which ultimately calls getValue, the behavior is the same.

It doesn't help that GitLab shows the diff a little bit weird by comingling the function headers together. Here's a better visual diff of the actual change:
diff of change

liam morland’s picture

liam morland
Primary language English
Location Ontario, CA 🇨🇦
commented
Status: Reviewed & tested by the community » Fixed

Thanks. That explanation is what was missing in my understanding.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.