Component import is not working

I only done some quick tests on D7, but it was working on the test environment. What version of Drupal and Webform are you using?

No, but I'm wondering if there is an issue with the different versions. I'll try and have a look at this tonight (~8 hours)

K. I'll still look into this at some stage :)

This was a bit that I didn't test. The default settings are coming through when saved in the content type settings under the publishing options fieldset.

The internal structure of the webform module has changed. I would have to mimic every component insertion manually and maybe other features too. This is something that I do not want to do.

Ie: I would have to implement private webform functions, and these could change at any time.

I've implemented this and appears to be working fine in 4.x branch after this patch is applied.

Has this patch been applied to one of the downloadable branches yet? I've tried both 1.2 and 1.2+0-dev and I'm having similar issues. I have multiple page breaks for a given webform and multiple fieldsets per page break and I'm getting all page breaks and fieldsets, but none of the components that are nested within fieldsets. I do get components that are not in fieldsets.

Webform 3.x or 4.x?

I was getting all sort of strange behaviours, but this was against an existing content type that was latter tagged onto the Webform 3.x module. After upgrading to Webform 4.x, these issues appeared to go away.

Note that imports should be against their corresponding counterparts, 7.x-4.x to 7.x-4.x, 7.x-3.x to 7.x-3.x, 6.x-3.x to 6.x-3.x.

If you try 4.x, make sure you do so on a test site first, it is fairly new, but we have had no issues to date.

But yes this was committed in b4ee7e6.

Webform 7.x-3.18 with Webform Conditional 7.x-1.0-beta1.

Yep, I can see where the code is going wrong. I will need to find some time to investigate fully and write the update.

I wonder if this also effects other similar modules, the components when inserted which are nested will depend on the cloned parental ID. These will be wrong in this case, as the module handles merging, and two components can not share the same integer id, so these will never map.

I think that this requires:

Mapping a tree of the components based on the component string id (form id field) and then manually inserting or updating each. Much more than I wanted to handle, but the actual interface to webform API would be limited to just two functions... On the cards but on hold.

In relation to the insert, this should work. The webform defaults are pasted into the Publishing setting of the content types vertical tabs. It would require a small hack, that I will need to test properly before committing:

Near the bottom of webform_share.module, delete the line

  $node->webform['components'][$index]['pid'] = 0;

This should be the only reference to pid in the code. Sorry for delays here, been super busy on other projects and work.

In a pinch I was able to import a webform with fieldsets as follows:

1. create a new webform node
2. import a webform without any fieldsets (e.g. one textfield)
3. re-import a webform with fieldsets (with "update components" and "keep existing components" checked)

Essentially, don't use a webform with fieldsets as your initial import. Hope that helps as a workaround in the meantime.

Alan, if you can provide some details of "where the code is going wrong", I can have a crack at making this work.

Without investigating, I think that the issue is this:

Webform components have the component id (cid) and parent component id (pid). So during the import the relationship between these could does break as it checks the form field "machine name" (best available option) to compare, and if this doesn't exist, the component is added, possibly with a different cid from the import code (i.e. importing into an existing form where cid 1 to 10 are for other fields not in the import).

So I think that the module needs to map the components into the real structure during import and regenerate the cid-pid relationship before passing these onto the webform module to save.

So for a new type, maybe leave all cid/pid untouched, but for imports & resets we need to get our hands dirty :(

This may need some additional checks to ensure that the data integrity of the webform database tables, I have hit some strange bugs that appear to be from corrupt data. These occurred when I converted a content only type to a webform type. This was inconsistent and unrelated to this module, i.e. I could not replicate the steps to do this and happened prior to enabling this module. Webform 4.x was still in alpha at that stage - and still is

I am hoping this will work , but I haven't looked into it at all yet.

My out of work time is being sucked up with an external job so not sure when I will be able to get back to this.

I can also confirm that fieldsets are not properly being imported, but a double import as chris_five suggests seems to resolve this.

As a follow-up, I am now able to import forms with fieldsets to and from two site instances(?!). Other than some fields being located in the wrong fieldsets, all of the fields seem to have come through. I have no idea why...

One thing I did notice is that on my earlier unsuccessful imports, a record was not being created in the "webform" table, even though the "webform_component" table was properly populated. I was able to get around that by simply creating a dummy textfield on the form and the formerly invisible fields were displayed.

FTR I am using webform_share with webform_template, importing into the latter.

Marked #1831098: Not able to import all fields when using field groups and #1831102: Cannot import when"Update components only " is unchecked as duplicates.

I have the same problem. A double import as listed above seems to allow the components to be imported OK, but if I uncheck "Update components only" , I get a SQL integrity constraint violation:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '616-1' for key 'PRIMARY': INSERT INTO {webform_emails} (nid, eid, email, subject, from_name, from_address, template, excluded_components, html, attachments) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 616 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => jlowe@2gb.com [:db_insert_placeholder_3] => default [:db_insert_placeholder_4] => default [:db_insert_placeholder_5] => default [:db_insert_placeholder_6] => default [:db_insert_placeholder_7] => 13 [:db_insert_placeholder_8] => 0 [:db_insert_placeholder_9] => 0 ) in drupal_write_record() (line 7251 of /Users/phildodd/Sites/2chshop.com/includes/common.inc).

webform 7.x-4.0-alpha6

I have the same situation. If I uncheck the "Update components only" (I want to do that to create a new webform), I caught the same PDOException as in #19 and the site displays the "Unknown Error" error message. The import works only if I keep that "Update components only" checked.

We're having the same issue with webform components inside of fieldsets not being properly imported. The fieldset is being imported, components outside of the fieldset are being imported, but nothing inside any of our fieldsets.

Thanks,
-mike

Please try the patch posted here:
https://drupal.org/node/1956622#comment-7528387

Seems to be duplicates of a couple of the other issues just committed.

Let me know if dev version is running ok, and open new issues for any bugs found (this thread contains multiple issues).

Setting fixed as per the original commit / issue