I had a brief discussion with mglaman in Slack, about supporting more common use cases with ubercart d6, such as pulling in the billing phone number, even though Drupal doesn't have a field to store it in by default. What came out of it was this initial suggestion from mglaman:
"Maybe there should be submodules.. like `commerce_migrate_uc` which adds some of the “expected” fields"
I really like this idea. For any source that you want a "full" migration from, there could be a submodule that does things like sets up fields and other configuration, and could make other assumptions about the environment based on the platform being migrated from.
The initial and most obvious use case for this, in my opinion, is to add a phone number field to profiles and then include the billing_phone field from ubercart when creating a profile.
Comments
Comment #2
quietone commentedI get the idea but I'm not sure I understand what is meant by adding fields. It almost sounds like this will be some setup done before the migration. It just sounds odd, but then I've had my head in node derivers and fields lately. And I don't know the what the source data looks like (yet).
Comment #3
replicaobscuraI do think this would essentially be setup done before the migration starts, in a standard way. In my example, there is no phone field in profiles in D8 by default, but people migrating from D6 Ubercart would very likely want to migrate the phone field from their D6 profiles.
The challenge is figuring out how to allow that to happen in a standard way so that a user wouldn't have to both extend a class and copy a yml file for such a basic use case of wanting to migrate a default Ubercart profile field.
These submodules, such as commerce_migrate_uc, could perform environment setup to create fields or other configuration required to allow all relevant Ubercart data to be migrated. It might not make sense to create a standard phone field in profiles for migrating from other e-commerce systems (but maybe it would so maybe that's not the best example), so a module that could be enabled to say "set Drupal up to migrate everything from Ubercart" seems like it'd be valuable for the new user experience of people trying to migrate over by eliminating quite a number of steps and allowing the migration to make more assumptions about the Drupal environment than just what's available already when you first install Commerce.
However, if that's overkill, I do think it would at least make sense to add the extra common fields from other systems to the query so that they're available for mapping, even if there's nowhere by default to map them to. This would at least make it so someone only has to copy the yml template and doesn't also have to extend or modify the query to pull in a common field.
Comment #4
quietone commentedWoocommerce migration has started as a sub module. #2876446: WooCommerce Migration
Add a start at moving ubercart to a sub module, #2890311: Add phone number field for billing profile and migrate
Comment #5
replicaobscuraOh, awesome! Thanks for the heads up!
Comment #6
quietone commentedIn #2894123: Move commerce to submodule @heddn made some suggestions (that I like) on how to organize this module. #12 and #13.
Comment #7
quietone commentedThe existing ubercart and commerce work has been moved to submodules, see the child issues. Now that the pattern of sub modules is established it seems time to close this.