forked from fuzionnz/webform_civicrm_migrate
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
17 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
453b0bd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I can't see why those values for no_autofill, hide_fields, filter_relationship_types, filter_relationship_contact, group, tag were changed when I compare against https://github.com/colemanw/webform_civicrm/blame/fe2258884c9c741aed65665cb3cc8bc73fd75248/src/Plugin/WebformElement/CivicrmContact.php#L50 they are set that way there.
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.
The skip definitely makes sense. Do you want to pull the first and last change in a PR or 2 and we'll merge those in the children I think I want to figure out more about that - can you give me some steps to create a webform that will cause this problem? What elements do I need in d7 ?
453b0bd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stesi561 I can make some separate PRs.
In this commit bc15309 to this module it went from being
[]
to['' => '']
. So it seems like a mistake to me.In regards to the children. I think the code assumes children arrays always have hashes, but an element with an
#options
array can contain items that don't start with a hash. For example, I saw something like this:That should be enough I think to recreate the bug.