[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ic] IC 4.8.9->5.2 upgrade snafus


I've been given the task of moving several stores from one (somewhat flaky) machine (currently running 4.8.9 and 4.9.5) to a new more reliable machine running 5.2. The old machine is running Debian Woody, fairly heavily modified; the new one is Debian Sarge with a custom local non-threaded perl. IC is installed from source in all cases.

The first store to be moved is the most complex; it's had a number of customer modifications added on the catalog side, and receives the most traffic by far of just about any other site (of any kind) that we host. I have not finalized the move yet due to several problems pointed out by the customer on detailed, store-specific testing.

At a glance, the store *seemed* to move easily enough. (To copy the store, I rsync'ed the on-disk catalog tree, and dumped the MySQL database to get loaded on the new machine. I copied the store's webroot (such as it is) and made sure that the CGI binary was from the right version of IC. The locations of files for IC installs on both systems follow our own internal conventions and are the same on both systems.)

There are a few issues with gnupg due to woody->sarge changes in the package that we know about and can allow for. There's something in the determination for shipping costs that may no longer require a hack implemented by the customer, so that's good too. There are also a handful of other oddities that we've got solutions for or leads on fixing.

However, there are a few other glitches that I can't trace: (they may be related to other issues - causing them, or being caused *by* them)

1) Order numbers appeared to have reset themselves somewhere in the move. The customer reported that a few test orders showed up with order numbers that had long since been used, and which effectively mangled those existing orders. I don't know what the reset went to originally, but the live store is showing order numbers in the 33000-34000 range, and the only place I can find where that number might get stored is in etc/order.number in the filesystem catalog data.

2) When an item is deleted from the admin section, an options table error comes up. The customer says they're not using that table for anything and that it shouldn't be referenced in the first place.

3) The customer had set the store subsections menu (category_vertical) on the left-hand side of their page to be cached, and regenerated once per day. Somewhere along the line, the settings the customer has used to cause this seem to be getting ignored or misinterpreted.

Any suggestions on fixing these?

-kgd
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.