I haven't spotted any mention of upgrade strategy for the new Drupal eCommerce API - apart from a comment I remember seeing somewhere that there won't be a standard Drupal upgrade facility (using update.php) - so, here's a thought I had earlier on the subject of upgrading...

I was wondering if it would be an idea (considering the massive differences between 3.x and 4.x) to have an ec_catalogue_export.module for version 3.x and an ec_catalogue_import.module for version 4.x. which pulls in a standard XLS/CSV spreadsheet of product listings.

A catalogue_import.module for version 4.x would be incredibly useful as a standalone module...e.g. I know a few projects that are dying to shift from ubercart to drupal ecommerce 4.x because of the quality of the new eCommerce API and there are also those who would like to migrate from oscommerce/other to Drupal.

The export.module for 3.x would generate a standard XLS/CSV spreadsheet of products that could be imported into version 4.x. Which leaves the payment gateways and store settings to be setup manually. It's not ideal, I know, you lose the transaction history, but, because of the significant differences between the versions, a lot of the older modules don't exist anymore and most that do, have been renamed...so a catalogue export/import alternative might be a relatively simple solution for those making the leap from 3.x to Drupal eCommerce API 4.x.

The upside

  • It eases the "pain" of setting up the existing product catalogue from version 3.x
  • It reduces the development workload
  • It eases the "pain" of migrating from other ecommerce solutions to the new Drupal eCommerce API

The main downside is that you lose your payment gateway settings, main store settings and transaction history - which is not good. Losing the transaction history maybe a bit of a showstopper for subscription based sites, but, for standard product sales type sites, it might be worth considering.

Any thoughts?

dub

Comments

burningdog’s picture

burningdog commented

Having the ability to export and import products is a brilliant idea and gets a big +1 from me! It would be awesome to have import capabilities from other e-commerce setups too, like Ubercart, Zen cart and oscommerce.

I'd still like to see an upgrade path from 3.x to 4.x, though - the drupal philosophy is "the drop is always moving" which means that although the new code won't be backwards-compatible, there will always be an upgrade path to reliably preserve your data. Especially for sites that need to preserve their transaction history - having a shiny new e-Commerce 4 option available, but no upgrade path, means that they won't upgrade.

Ideally we'd be at a place that if someone is updating from Drupal 5/e-Commerce 3 to Drupal 6/e-Commerce 4, they simply run update.php. Sure, it's going to be complicated to figure out dependencies now that e-Commerce is now split into core and contrib (and perhaps an upgrade path won't be even possible for people who depend on modules like subproduct and ec_recurring which haven't been updated for 4.x yet) but I'd like to know that the e-Commerce developers are committed to this path, even if it will take a while.

Dublin Drupaller’s picture

Dublin Drupaller commented

re: I'd still like to see an upgrade path from 3.x to 4.x, though - the drupal philosophy is "the drop is always moving" which means that although the new code won't be backwards-compatible, there will always be an upgrade path to reliably preserve your data.

I see your point, but, I don't see the new Drupal eCommerce version 4.x as an "updated" version of 3.x.

It's a complete rewrite of the old ecommerce modules...and is a bit like the way flexinode.module became cck.module. Similar features, but, completely different approach and because it was so different it wasn't possible to use update.php.

A lot of the modules don't exist anymore in the new Drupal eCommerce API, so using update.php is going to be a little tricky. I can see the store.module pulling over some of the settings (many of which are stored in the variables folder), but, beyond that, I think it's better to think of the new Drupal eCommerce API as a cck style project for Drupal. i.e. completely new.

Hence the suggestion of a catalogue import and export module, so when people see the new drupal eCommerce API they can migrate from what they're currently using, such as ubercart, oscommerce....or more importantly, the old ecommerce 3.x.

That's just my 2.0 cents. Perhaps Gordon and the rest of the team already have a strategy in mind.

burningdog’s picture

burningdog commented

I've just chatted with gordon on irc, and he says that Darren Oh was working on an upgrade path, and that since there is 1 module in common between 3.x and 4.x - namely ec_anon - it can do all the renames of the existing modules and then the upgrade will go from there.

gordon is willing to test this upgrade path, but he needs an ec 3.x database to test. Dub, I volunteered you sending him one, since you have a stack of 3.x sites you're using ;)

Dublin Drupaller’s picture

Dublin Drupaller commented

Great to hear that there is an upgrade path been worked on and thanks for volunteering Roger....but, I can't send a clients database out like that. Would you?

burningdog’s picture

burningdog commented

I hear you - no sensitive information needed! What if you make a local backup, strip the database of all sensitive stuff, remove all users (except for a "peon" user and an admin user), reassigned all transactions to the "peon" and then sent it to gordon? We just need some way of testing the upgrade path - I'm not sufficiently familiar with ec3, or I'd set up the database myself. I don't want to miss anything, so it makes more sense to have someone who knows what they expect at the end of the process to supply the database.

Of course, gordon could set up a new 3.x site himself, configure it, add users, put in some dummy transactions etc, and then test the upgrade. It's just a case of that taking a while to get to the point where an upgrade can be tested - and if there's a db out there which can be easily used, then that's easier :)

darren oh’s picture

darren oh
Primary language English
Location Lakeland, Florida
commented
Status: Active » Fixed

Functions for updating from 5.x-3.x existed in 5.x-4.x. They weren't being run in 6.x-4.x because some module names had changed. This was fixed in CVS commit 198402. You can get the updates to run by disabling and re-enabling

  • ec_address
  • ec_cart
  • ec_checkout
  • ec_product
  • ec_store

Then run update.php.

Dublin Drupaller’s picture

Dublin Drupaller commented
Status: Fixed » Active

Sorry Roger..I understand what you're saying, but, no can do. The words hung, drawn and quartered springs to mind. (burningdog added on IRC tarred & feathered).

Besides, no sensitive information means no users, no transactions, no products and no important store settings..i.e. a blank install.

darren oh’s picture

darren oh
Primary language English
Location Lakeland, Florida
commented
Status: Active » Fixed

I believe this was accidentally set to active again. See comment #6.

burningdog’s picture

burningdog commented

Dub: burningdog is me ;) Thanks for the info, Darren Oh. Do we need to add documentation to this effect in the upgrade handbook somewhere?

darren oh’s picture

darren oh
Primary language English
Location Lakeland, Florida
commented

It would be helpful for those who had already upgraded before the updates were added. For others it will happen automatically. Hopefully, no one will be using this on a production site until an official release is made.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.