Follow-up for #2880392: Error: Unsupported operand types in Drupal\webform\Entity\Webform->setSettings() (line 739.

@heyyo:

I experienced the similar issue on one of my translated webform, I supposed it's caused by not having any config settings for this webform in the translated language folder.

Error : Unsupported operand types dans Drupal\webform\Entity\Webform->setSettings() (/home/XXXX/XXXX/web/modules/contrib/webform/src/Entity/Webform.php ligne 705) #0

Please find another patch for the method setSettings of the webform class, which resolves my issue.

CommentFileSizeAuthor
unsupported_operand_types-2880392-6.patch695 bytesJeroenT
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JeroenT created an issue. See original summary.

JeroenT’s picture

Title: {Your title should be descriptive and concise} » Error: Unsupported operand types in Drupal\webform\Entity\Webform->setSettings() (line 739
Issue summary: View changes
jrockowitz’s picture

The fact a webform's settings are empty is an indication of a major issue.

What are the steps required to reproduce this issue?

Have you looked at your exported webfrom's config and confirmed that the settings are missing.?

Have you tried executing `drush webfrom-repair` which should restore any missing settings?

jrockowitz’s picture

Status: Needs review » Postponed (maintainer needs more info)
JeroenT’s picture

Not sure how to reproduce this, but for some reason in the translated yml-files the following code was there:

settings: null
jrockowitz’s picture

The settings: null in the webform translation is definitely going to clobber all your webform settings and we need to figure out how to replicate and fix this problem.

Is the settings: null removed when you resave a webform translation?

Or is it removed when you translate any webform setting string?

clairedesbois@gmail.com’s picture

I have exactly the same issue with a old webform after a huge update of the module (pass to webform-beta11 to webform-rc10.

The patch doesn't solve the problem for us. We have the error on the translated version of the webform. When I apply the patch, we have access to the translated version in admin but not in anonymous. With an anonymous user, we have an access denied.

Ironically, we have an other webform, less complicated, which doesn't bug

jrockowitz’s picture

@Calystod Is the source language of the broken webform different than the website's default language.

I am starting to suspect that this is a duplicate issue

@see #2913548: Source element values are replaced with translated values

jrockowitz’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)