[ic] IC 4.8.9->5.2 upgrade snafus
Kris Deugau
kdeugau at vianet.ca
Wed Jan 25 13:37:40 EST 2006
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
More information about the interchange-users
mailing list