Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Right now there's no example on how to accomplish this.
I'm willing to write it as long as I get some guidance as to how it work.
Comments
Comment #1
sea4 CreditAttribution: 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 CreditAttribution: rooby commentedIs this still the case? are we just dealing with submissions here?
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous 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) CreditAttribution: Anonymous 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) CreditAttribution: Anonymous 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 CreditAttribution: 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) CreditAttribution: Anonymous 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 CreditAttribution: 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) CreditAttribution: Anonymous commentedOk, a sandbox is available! https://drupal.org/sandbox/weal/2115619
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous 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 CreditAttribution: solideogloria commentedComment #14
solideogloria CreditAttribution: solideogloria commentedAnd for D7 -> D8, use https://www.drupal.org/project/webform_migrate