Create Migration to Webform 4.x

status update I talked with tedbow and he is still working on this issue.

Ted,

NOTEWebform 4 token replacement system was re-written to use D7 tokens. As such, you will need to download and install the Token module from Dupal.org otherwise, some tokens will not be rendered. This is a webform issue, but you need to have it for everything to work correctly.

My goal was to test this using the same or very similar method / process that the end user would follow when upgrading. I did this by:

1. Using my install 7.1 version of webform - same page conditional and Webform 7.x-3.18
2. Using the webform form / conditional demo that is on Six Mile Teck's (tedbow) website
3. Downloading and enabling backup_migrate
4. Backing up my database to my Drupal backup directory
5. Backing up the code using git. And yes I realize that this might be overkill. However, being the survivor of other upgrade, I have learned to be paranoid.

• git init
• git add .
• git commit -m "Commit of webform 3 before upgrade"

run update.php,

I received the following message from update.php:

The following updates returned messages
webform module
Update #7401

Your existing webforms have been upgraded to use the global Drupal 7 token system.

Update #7403

6 webforms using conditionals updated to the new conditional system.

webform_conditional module
Update #7201

Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '5-0' for key 'PRIMARY': INSERT INTO {webform_conditional} (nid, rgid, andor, action, target_type, target, weight) 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); Array ( [:db_insert_placeholder_0] => 5 [:db_insert_placeholder_1] => 0 [:db_insert_placeholder_2] => or [:db_insert_placeholder_3] => show [:db_insert_placeholder_4] => component [:db_insert_placeholder_5] => 2 [:db_insert_placeholder_6] => 0 ) in drupal_write_record() (line 7013 of C:\Users\Dennis\Sites\acquia-drupal\includes\common.inc).

take out of maintainance.

delete webform and webform conditional directories
download webform 4
download webform conditional 7.x-2.x via download from project page 7.x-2.x-dev - do this as this is how user will do it.

extract or whatever - download using drush - enable using drush

via drush -
use drush updatedb, clear caches - drush cc all

via brower
run browser - login - and run update.php
run update.php

test it .

if passes, then shut down site.

delete new version of webform and webform condtional
reload old versions
restore data

try other style to update.

Ted,

I repeated the steps I did in comment # 3 and this time everything worked fine. Below are the messages the update generated:
----------------------------------------------------------------------------------------------------
The following updates returned messages
webform module
Update #7401

Your existing webforms have been upgraded to use the global Drupal 7 token system.

Update #7403

5 webforms using conditionals updated to the new conditional system.

webform_conditional module
Update #7201

12 webforms using same page conditionals updated to the new conditional system. You may now uninstall the Webform Conditional Module.
----------------------------------------------------------------------------------------------------

Ok, I guess at this point I should:

1. Take the site out of maintenance mode
2. Disable the webform conditional module
3. Cllick on Home » Administration » Modules » Check Webform_conditional uninstall box and click the Uninstall button

Now that I have uninstalled the Webform_conditional I went back to the Home » Administration » Modules page and the Webform Conditional 7.x-2-x-dev module is still there. I take it I have to manually delete the webform_conditional directory? The uninstall only removes it from Drupal, but does not "un-install" the module from the computer? So I guess I need to remove the directory.

Do we need to document this process?

It worked for me.

+1 for RTBC. I also suggest adding a bit more information about upgrading to webform 7.x-4.x on the module page. Something really basic along the lines of:

1. Update both modules at the same time
2. Run update.php
3. Confirm webforms work as expected and remove Webform Conditionals module.

webform_conditional_update_7201 works for 1.x as well. Here is the patch for 1.x branch. Moving issue to 1.x as it's fixed in 2.x http://cgit.drupalcode.org/webform_conditional/tree/webform_conditional.....

Hello,

I've tried several times to go from 7.x-3.x (latest version) to 7.x-4.x (latest version and 4.0) and get this error:

Update #7403
Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '7-0' for key 'PRIMARY': INSERT INTO {webform_conditional} (nid, rgid, andor, action, target_type, target, weight) 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); Array ( [:db_insert_placeholder_0] => 7 [:db_insert_placeholder_1] => 0 [:db_insert_placeholder_2] => or [:db_insert_placeholder_3] => show [:db_insert_placeholder_4] => component [:db_insert_placeholder_5] => 9 [:db_insert_placeholder_6] => 0 ) in drupal_write_record() (line 7261 of /var/www/includes/common.inc).

I tried disabling all webform modules before hand and it made no difference.

This stops the other DB updates from happening.

My existing forms lose all their components and if I try to create a new one, I don't have a tab to add components.

I replaced drupal_write_record with db_insert since the documentation for drupal_write_record says not to call it during hook_update_N().

Also fixed issue with Integrity constraint violations due to it attempting to reuse 0 for rgid field.

+++ b/webform_conditional.install
@@ -211,10 +223,22 @@ function webform_conditional_update_7001(&$sandbox) {
-            drupal_write_record('webform_conditional', $conditional);
...
-              drupal_write_record('webform_conditional_rules', $rule);

Just for the record you can always use drupal_write_record as long as you are not messing with the schema of that table on which you are using drupal_write_record.

Patch looks good to me.

When there are more than 100 webforms it is stuck in an endless loop because you don't fill $sandbox['last_nid_processed']

it will always be -1 and thus it will always select the first 100(or whatever amount of the batch is) webforms.

Fixed if you add $sandbox['last_nid_processed'] = $nid; in the foreach loop

Just leaving a patch for 2.x, which doesn't use drupal_write_record and adding update-dependencies. You'll need this if you update webform accross multiple versions, because webform changes some table stuff.

With the patch the update 7021 of webform_conditionals will run between 7402 and 7403 of Webform.

In webform_update_7423 the webform_conditional_actions is introduces and the webform_conditional table is missing some fields, which aren't in hook_schema anymore ... why drupal_write_record doesn't work anymore.

Also fixed the "last_nid" thing mentioned in #14

It appears from this issue - https://www.drupal.org/node/2664888 - that updating to Webform 4.x and this module to 2.x-dev at the same time doesn't work.

Can anyone advise as to the correct upgrade process to move to Webform 4.x with conditionals in place and working?

#15 got this working for us too.

Attached is a patch for the situation where you first performed all webform updates and then find out that the webform conditionals are broken. This update hook creates a conditonal state that is conform the webform state after update webform_update_7424 is run.

I had a couple of problems with #15..

1. The update hook ordering - Webform 7403 isn't expecting nodes which may already have conditionals inserted. Our update hook can deal with conditionals already added by Webform, so should run after 7403.

2. Bug when Webform added a single conditional rule with rgid 0, which is treated as though there are no conditionals due to misuse of empty(), causing an insert conflict from rgid re-use.

Updated patch attached.

One more issue. Rules to show a component when conditional value is 0 were not being migrated.

Just a quick message: we just ran this update on a site that had more than 100 webforms and the latest hook_update did not complete. The finished-condition somehow was never met. We had the patch in #18 applied.

I haven't looked into the issue any further than just increasing the variable (so it would update all webforms in 1 pass).

Also not having much luck with the patches above or any combination of patches. We have too many 3.x forms with conditional logic to just be able to uninstall the webform_conditional module.

I can confirm patch 20 works.

dsrikanth which versions of Webform and Webform Conditional did it work against? Was #20 the only patch applied?

It looked like the upgrade worked, except that the batch never reaches its finished state (thus becomes an endless loop)
Other than that endless loop, it worked fine for us too. As a temporary work-around, you can set the batch-size variable to a number greater than the number of webforms it needs to update.

This patch uses drupal_write_record in spite of the warning in the documentation of that function:

Do not use drupal_write_record() within hook_update_N() functions, since the database schema cannot be relied upon when a user is running a series of updates. Instead, use db_insert() or db_update() to save the record.

But I don't believe that is the issue here.

Recent versions of the webform 4 module use a separate table for storing actions (like show/hide/require). The migration in the 2.x-dev version of webform_conditional doesn't account for that. I've attached a new patch fixing the issue.

I propose to apply the patch to the 2.x-dev version of this module.

For me #15, #18 and #20 don't work on Webform > 7.x-4.7. This is because Webform moved the action to a separate table, allowing multiple actions per condition. Looks like #27 tries to address that, but it doesn't address any of the previous issues. I didn't try #27 on its own.

The upgrade process that seems to have worked for me is:

1. Download Webform 7.x-4.7
2. Download Webform Conditional 7.x-2.x-dev
3. Apply patch in #20
4. Download updates to any other webform related module, e.g. webform_validation.
5. Run update.php (via drush)
6. Check conditionals are still working
7. Disable and uninstall Webform Conditional
8. Download Webform 7.x-4.14
9. Run update.php (via drush)

I didn't try #27 on its own.

The patch in #27 worked for me, and I am using webform 7.x-4.14. Update process used:

1. Update to webform to 7.x-4.14
2. Database updates
3. Update webform_conditional to 7.x-2.x-dev
4. Database updates
5. Disable and uninstall webform_conditional

One thing to note is that the webform_conditional table, the webform_conditional_actions table, and the webform_conditional_rules table must be empty before running webform_conditional update 7201. Otherwise, the update will fail silently and you will need to run the webform_conditional_update_7201 function manually after truncating those tables.

Want to thank everyone - I got through this today and my steps looked like this:

1. removed Webform 3.x and Webform_conditional from /modules/
2. add Webform 4.15 and the Webform_conditional-7.x-2.x-dev
3. add new Commerce Webform commerce_coupon-7.x-2.x-dev // I use this
4. run update.php
5. uninstalled and removed Webform_conditional-7.x-2.x-dev

I got no errors , 33 some updates and all seems to be working - great work to you all.

I know this is quite an old issue and not many people will have to go through a Webform 3.x to 4.x + Webform Conditional upgrade but I just had to do it now in order to be able to migrate more than 100 webforms from D7 to D8 and the two patches from #20 and #27 greatly helped.

Patch #20 doesn't work directly with recent webform 4.x version (I'm on 4.23 at time of writing, but #27 fixes that issue so had to combine them to get it working.
Added patch #27 to #20 and removed the columns that no longer exist in table 'webform_conditional' as they've been moved to the separate table 'webform_conditional_actions' which is covered in patch #27.

Afterwards the database update webform_conditional_update_7201 applied correctly and converted all my conditionals ok.

And in case this matters the steps i took are basically the ones from #29, mainly because I didn't realise I had to upgrade webform_conditional too so I only did webform at first:
1. Update to webform to 7.x-4.x (4.23 for me)
2. Database updates
3. Update webform_conditional to 7.x-2.x-dev
4. Database updates