Closed (outdated)
Project:
Migrate Extras
Version:
7.x-2.x-dev
Component:
Documentation
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
9 Mar 2012 at 23:02 UTC
Updated:
30 Jan 2023 at 19:04 UTC
Jump to comment: Most recent
Comments
Comment #1
sea4 commentedthis would be great!
Comment #2
mikeryanWell, I recently had my first shot at migrating webform submissions (note there is no migration path currently implemented for webforms themselves, I manually rebuilt them). Here's a class derived from migrate_d2d's DrupalMigration (this was a D6-to-D7 deal), scrubbed of some customer-specific stuff, with extra comments for the general audience. It's key to note that this is the migration for the submissions to a single webform.
Ain't that pretty, but it works.
Comment #3
rooby commentedIs this still the case? are we just dealing with submissions here?
Comment #4
Anonymous (not verified) commentedI'm attempting to migrate some webforms that must be done programmatically so I'm going to create some classes to deal with the components and settings. I was able to create a node migration using the migrate_d2d docs, but upon doing so I need to ask a question about the code sample above:
$this->addFieldMapping('data_new_1346960272729', 'username');Where exactly does that $DEST field get defined? I haven't seen this format in use on any migrate modules. Assuming it is probably a temporary variable but I'm not sure.
In any case, what I'm going to do for my environment is the following:
Anything I'm missing here? It looks like webform_emails, webform_roles, webform_submitted_data and webform_last_download can probably be skipped?
Comment #5
vlad.dancerHi, Ryan Weal.
You can simply debug this if you inspect MigrateDestinationWebformSubmission, because addFieldMapping() always is about destination object, so MigrateDestinationWebformSubmission has override for
public function __construct, here method adds 'data_' prefix to the destination field name.Comment #6
Anonymous (not verified) commented@vlad.dancer thanks. I guess it is specific to this component then!
I was able to setup my node migration using migrate_d2d syntax, and I have a custom class that uses MigrateDestinationTable that brings all of the components from the D6 site.
Currently the code is in my custom module package but I may rework it for migrate_extras if people want it. In a few days I will work on the settings migration.
Comment #7
Anonymous (not verified) commentedNoticed that note a bit late... going to have to rewrite that migration it seems. It looks like I'll likely roll a new module to contain my migrations for webform.
I also added a WebformEmails and have now written the WebformSettings migration to the code I'm working on. More to come!
Comment #8
rooby commented@Ryan Weal:
You just need to have a separate migration for each webform, same as you might do for dirfferent node types or different field collections etc. They can still be all together in the same module.
My last migration was just users from a spreadsheet and it required about a dozen migrations to get it all in due to profile2, field collection etc.
Comment #9
Anonymous (not verified) commented@rooby now I have it all done now following the strategy I outlined above. I'm planning to take out the non-generic code this weekend and post the module. It will autodiscover what node types have webforms enabled, migrate all the nodes (with the default D6 fields), all the configuration*, the form components, email destinations, submissions and associated submission data, in addition to any validation configuration you have (from webform_validation module). It grabs the "last downloaded" data too, in case your users were downloading sequential batches since the last time they were on the site. I did it in 3 business days, it has been epic. I really need some sleep.
*for the configuration I didn't get much into converting the tokens beyond ONE example (user email) and if you use others it will warn you and give you an easy path to fix it (either a link directly to where you can update it to the new value, or a request for a patch and a nice switch statement to make that easy).
It does not yet look for tokens embedded in the body text. However, I have code for that from another migration... so feature request.
I'm considering adding a switch in the configuration to allow preserving nodes/component/submission_ids. Right now it allows both after today's updates.
Comment #10
rooby commentedWow, that sounds fantastic and will be great for the migrate suite.
Thanks for the work, I'm sure it will make my life easier at some point.
Comment #11
Anonymous (not verified) commentedOk, a sandbox is available! https://drupal.org/sandbox/weal/2115619
Comment #12
Anonymous (not verified) commentedOk, it is a real module now: https://drupal.org/project/migrate_webform
You will need to configure a secondary DB in settings.php, go to "migrate webform config", put the key of the db there, then go to migrate > config page and "re-register statically-defined classes" to get it to work.
Config is pretty rough and mostly borrowed from commerce_migrate_ubercart which I have a big patch ready to support the 2.6 branch of migrate. Maybe I can figure out how to get it working within the migrate_d2d wizard eventually...
Comment #13
solideogloria commentedComment #14
solideogloria commentedAnd for D7 -> D8, use https://www.drupal.org/project/webform_migrate