$child_element - sometimes it's trying to treat a string as an array

[herbdool]

I need to investigate this further:

TypeError: Cannot access offset of type string on string in Drupal\webform_civicrm_migrate\EventSubscriber\WebformCivicrmMigrateSubscriber->migrateWebformElement() (line 414 of /app/httpdocs/modules/contrib/webform_civicrm_migrate/src/EventSubscriber/WebformCivicrmMigrateSubscriber.php).

This is where it happens:

        $child_element = $element[$key];
        $child_element['#form_key'] = $new_key;

In the source webform I guess there some cases where the "child element" is not really an element even if it doesn't have a hash. But I'm going to try to find out why.

[herbdool]

I think the problem is that getChildren() only skips keys that are blank or start with a hash. But I found some cases which don't match that, such as #options children and #states children. So I tested with checking that the child is an array.

I can start submitting PRs if that helps.

[stesi561]

I feel like the reason I had those empty strings in arrays was either copied from webform_civicrm or potentially I was comparing the result of exporting a migrated webform with generating one, or even opening and saving and ensuring hte config didn't change.

[herbdool]

@stesi561 you said:

For the fix for the children I believe I adapted the methodology from webform/src/Utility/WebformElementHelper.php hasChildren I think we are probably better updating the getChildKeys function to not return non arrays - but perhaps it should otherwise that would be an easier test. Might need some more digging here. I guess we also need to think about do those attributes that are not children need migration? Or is there a reason they don't start with a hash.

I guess I'm not entirely clear what the method does. If we skip over some elements I figured they would still be there since they're not being unset further down. I've been mostly focused on squashing fatal errors on the migration so I'd need to think about it more.