Class registration for Migrate 2.5 or later

Thanks Mike !

Looking on that.

Attached is a patch that declares all migration classes in the hook_migrate_api() implementation.

#3: While the patch applied correctly, none of the classes registered as it did previously with Migrate 2.4 (tested using migrate-7.x-2.6-rc1).

related issue: #1943420: Not seeing any ubercart migration options

With the rewrites necessary to make this Migrate 2.5+ compatible, would it make sense to leverage migrate_d2d in say, a 2.x branch of commerce_migrate_ubercart?

Looking forward to this -- right now it's incompatible with the latest version of Commerce Kickstart.

@Ryan Weal -- thanks for your work on this. the patch doesn't apply for me because of the missing commerce_migrate_ubercart.migrate.inc file. could you reroll so it will apply or submit your patched module?

1832736-support-migrate-2-5d.patch:101: trailing whitespace.
    if (isset($target_types[$type])) {
1832736-support-migrate-2-5d.patch:198: trailing whitespace.

Checking patch commerce_migrate_ubercart.info...
Checking patch commerce_migrate_ubercart.install...
Checking patch commerce_migrate_ubercart.migrate.inc...
error: commerce_migrate_ubercart.migrate.inc: No such file or directory
Checking patch commerce_migrate_ubercart.module...
Checking patch customer_billing_profile.inc...
Checking patch line_item.inc...
Checking patch order.inc...
Checking patch product.inc...
Checking patch product_node.inc...
Checking patch product_type.inc...

awesome! #9 applies cleanly as of http://drupalcode.org/project/commerce_migrate_ubercart.git/commit/d23f2...

i'll get to testing and let you know what i find.

@Ryan Weal re:#9 --

I tested a D6 Ubercart to D7 Commerce migration and had the following experiences:

- commerce migrate ubercart options for ubercart images are gone at admin/content/migrate/ubercart_migration_options
- CommerceMigrateUbercartProductType

• dynamic migration not working, must first create product types (opposite of http://commerceguys.com/blog/first-look-commerce-migrate-ubercart-screen...)

- CommerceMigrateUbercartCustomerBillingProfile

• billing_street2 and delivery_street2 missing as source field (fixed in #15)
• country missing as destination field in migrate_ui but hardcoded with prepare() function
• Missing bundle property on entity of type commerce_customer_profile: must define default_value for destination field [type] = commerce_customer_billing (for commerce_kickstart)

- CommerceMigrateUbercartProductFoo

• on migration view -
  "product_id" was used as source field in the "" mapping but is not in list of source fields
  "path" was used as source field in the "" mapping but is not in list of source fields
• status missing as source field

- CommerceMigrateUbercartNodeFoo

• on migration view - "path" was used as source field in the "path" mapping but is not in list of source fields
• status missing as source field
• initial Source Migration incorrect when there are multiple product types, references

- CommerceMigrateUbercartProductBar

• migration successful unless you edit, save, and import a node - SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column 'uid' at row 1: UPDATE {node_revision} SET timestamp=:db_update_placeholder_0, uid=:db_update_placeholder_1 WHERE (vid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => 1333819456 [:db_update_placeholder_1] => [:db_condition_placeholder_0] => 609 )
• can't rollback node migrations for which there are errors

- CommerceMigrateUbercartOrder
- CommerceMigrateUbercartLineItem

• Source Migration incorrect when there are multiple product types, references CommerceMigrateUbercartProductBar
• Missing bundle property on entity of type commerce_line_item: must define default_value for destination field [type] = commerce_line_items (for commerce_kickstart)

Regarding the first two points, the removal of ProductType and Images are intentional. Images can be handled by using D2D to build a files migration and you can map it to your fields that way. All of the images-related stuff needed to be completely refactored to use the new API and I simply don't have any sites that even use that field. Since there is a way to get it to work using the UI I think that is fine.

I figured this was intentional, but thought I'd note it just in case. Thanks for the clarification.

For ProductTypes, it should alert you if one is missing. This is better than the old way - which was to fail completely unless you deleted a default setting before installing. This is easily doable in the UI by a novice in just a few clicks but probably won't be needed if people were running with the defaults.

My experience was that the alerts weren't entirely friendly. In my test cast, I had three product types and it nicely alerted me about one of them. It wasn't until I went into the migration group that it threw a nasty SQL error about missing migration classes for the other two product types.

Path module is supported but must be enabled on the site I think... that functionality is probably the same as the original. Maybe someone could add some detection code for this... personally I always use path.

path was enabled on both destination and source. path was available as a destination field, but not a source field.

I don't know what you mean by this: "edit, save, and import a node" ... are you saying you are editing and re-importing? Were you running this with mirage 2.5 or 2.6? I haven't seen any rollbacks fail yet on any of the sites I've tried. It could be a problem with the date handler... and I know the date module was not up-to-date with their migration includes until recently so it might be that. Could also try migrate_extras, I can't recall if it has a specific date handler or not.

Yeah, this was a bit of a weird one as it only happened for one node type. And, it just so happened that it was the one node type I made manual changes to the migration mapping. Even after reverting all the fields to the same as an OOTB node migration, I still got this error. It seemed to me that it wasn't storing the default uid properly on edit, but to be frank, I didn't spend much time on this error.

Anyways, thanks again for making strides on this. I'll try to make some time and dig through the code to make some improvements. Marking back as needs work for now.

I got the low[est] hanging fruit. This patch adds in billing_street2 and delivery_street2 to customer_billing_profile.inc while bundling all your changes in #9.

After further digging wrt customer_billing_profile.inc, country does get migrated properly during the migration as its hardcoded in the prepare($profile, stdClass $row) function. There just aren't options to change this in migrate_ui, though I doubt its needed for nearly all use cases.

Also, the commerce_migrate_ubercart.migrate.inc file was missing from the patch in #15 again ;-)

One other thing - you don't need to add commerce_migrate_ubercart.module to the info files[] list.

I'm looking through it while manually writing scripts to finish a site converted using some custom scripts (yeah, I know).

I noticed the order statuses needed some review. The Ubercart v6.x-2.something version this particular site runs has seven statuses:

• canceled
• completed
• in_checkout
• payment_received
• paypal_pending
• pending
• processing

Commerce Order, on the other hand, has the following:

• cart
• pending
• canceled
• checkout_checkout
• completed
• processing
• checkout_shipping
• checkout_review
• checkout_payment
• checkout_complete

I'm trying out the following mapping:

  $statuses = array(
    'canceled' => 'canceled',
    'completed' => 'completed',
    'in_checkout' => 'checkout_checkout',
    'payment_received' => 'pending',
    'paypal_pending' => 'pending',
    'pending' => 'pending',
    'processing' => 'processing',
  );

Is that correct?

Good call Damien. As it currently stands in the module, the only manually adjusted order status is payment_received => checkout_payment with the note that @todo Revisit this, these two statuses are not really the same.

My opinion is that payment_received => processing.

  function prepare($order, stdClass $row) {
    // Most order statuses (pending, cancelled, completed) are the same
    // between the two systems. However, some are not.
    if ($order->status == 'payment_received') {
      $order->status = 'processing';
    }
    if ($order->status == 'in_checkout') {
      $order->status = 'checkout_checkout';
    }
    if ($order->status == 'paypal_pending') {
      $order->status = 'pending';
    }
  }

Another note, if you want to use the "User ownership should be mapped" option, you can use migrate_ui + #2105037: is_new: can't map destination uid/nid for users/nodes in migrate_ui to maintain uid. This keeps all the Customer Billing Profiles intact.

I'll go ahead and reroll the patch with changes from #23 for further testing/refinement.

Also, @Ryan, do you want to create a 2.x branch so we can tag this and other issues to it specifically?

Nice nice nice!!

git clone --branch 7.x-2.x http://git.drupal.org/project/commerce_migrate_ubercart.git works perfectly.

And its browseable at http://drupalcode.org/project/commerce_migrate_ubercart.git/shortlog/ref...

I am trying to migrate from an Ubercart 6 store using version 2. With some code modifications (that I hope to share here as a patch when finished), CustomerBillingProfile was successful but I don't understand how to migrate Product.

I first deleted the default Product type.

After doing so, the following warnings appear at 'admin/content/migrate/groups/commerce_ubercart/Product':

"commerce_price" was used as destination field in "sell_price" mapping but is not in list of destination fields
"commerce_price:currency_code" was used as destination field in "" mapping but is not in list of destination fields

Using the module to migrate with no product types defined, results in a successful migration of the product 'SKU', 'Title' and 'Status' fields. 'Type' is empty. The price and currency code are not created and migrated.

I know Drupal Commerce but have not used the Migrate module. Is there something I should be doing that I am not?

I'd like to point out that the commit mentioned in #27 (from #25) doesn't include the new commerce_migrate_ubercart.migrate.inc file. Thus, no migrations appear in the UI.

Here's the missing commerce_migrate_ubercart.migrate.inc file (note that I had to use .txt to upload it, but you'll change it to .inc in your module). This is from one of the patches in #20. If you put this in your module, and then click "Register statically-defined classes" at admin/content/migrate/configure, you'll see the Commerce Migrate Ubercart migration group on the Migrate dashboard.

This should be committed to the repo.

dang, sorry joel -- that was totally my fault. i was pushing to get a commit and rushed the patch.

@Ryan would you mind committing in commerce_migrate_ubercart.migrate.inc when you get a sec? I can roll a new patch if thats easiest.

adds missing commerce_migrate_ubercart.migrate.inc

Thanks!

@Ryan Weal -- Thanks for making this happen