Paypal -- 1054 Unknown column 'zen_order_id'

just upgraded to 1.3.8 from 1.3.7 and added security patch, moved admin. All seemed well after test purchase except paypal would not return order to cart. (it would take the money) :cry:

got error:

1054 Unknown column 'zen_order_id' in 'where clause'
in:
[select * from zenpaypal where zen_order_id = 'XXXXXX' order by paypal_ipn_id DESC LIMIT 1]

on page under admin >customer >paypal

and on any customer page with a previous paypal purchase the error was:

1054 Unknown column 'p.zen_order_id' in 'on clause'
in:
[select count(*) as total from zenpaypal as p left join zenorders as o on o.orders_id = p.zen_order_id]

**FIX: in SQL renamed table zenpaypal order_id to zen_order_id **

and it all works again - orders and paypal payment show, orders are returned to cart again. :clap:

If there is any reason the fix is a bad idea or there is something else I need to know please tell me! :D

realized I left out a very important part... here is the REAL post...
just upgraded to 1.3.8 from 1.3.7 and added security patch, moved admin.

Got the following error:

Fatal error: Cannot redeclare class language in /xxx/xxx/xxx/xxx/xxx/includes/classes/language.php on line 111

So I have a bajillion mods and none of them point to this... I am reconfiguring a new cart with mods installed one at a time to track it down.

In the meantime I went back to my original cart install but alas I had already run the database upgrade... I was not sure if the old install (1.3.7 - the one with all of my mods) would still work.

All seemed well after test purchase except paypal would not return order to cart. (it would take the money) :cry:

got error:

1054 Unknown column 'zen_order_id' in 'where clause'
in:
[select * from zenpaypal where zen_order_id = 'XXXXXX' order by paypal_ipn_id DESC LIMIT 1]

on page under admin >customer >paypal

and on any customer page with a previous paypal purchase the error was:

1054 Unknown column 'p.zen_order_id' in 'on clause'
in:
[select count(*) as total from zenpaypal as p left join zenorders as o on o.orders_id = p.zen_order_id]

**FIX: in SQL renamed table zenpaypal order_id to zen_order_id **

and it all works again - orders and paypal payment show, orders are returned to cart again. :clap:

So right now I am running a 1.3.7 cart on a 1.3.8 datasbase... with a new install in the works. If there is any reason the above fix is a bad idea or there is something else I need to know please tell me! :D

That "fix" will buy you a bit of time until you re-do the upgrade again.
It's never a good idea to use different/mixed versions of code vs database, so I recommend getting your upgrade working asap.

Remember, staging your upgrade in a test environment (different folder+database on the server is most common) allows you to sort out the glitches before you touch the live store.

Thanks for letting me know, I was hoping there was not some hidden mess I was making that I would learn of next week!!!

DrByte:

Remember, staging your upgrade in a test environment (different folder+database on the server is most common) allows you to sort out the glitches before you touch the live store.

Yeah, a good reminder. I did that, but not with a full database and full set of mods... and it seemed to work just fine, so onward I plunged. A testament to the zen-cart, it has just always 'worked' for me... when I factor out user-error... LOL

Also time to note that it seemed like a pain to keep two stores going (full mods on both) but it would have saved a lot of time this time around!

FWIW -- for other learners out there... I did keep a backup of the 1.3.7 store AND the database... and when I put he store back on-line it seemed to be working. When I switched it back on-line two orders came in, so I opted not to restore the 1.3.7 database. In retrospect I SHOULD have just printed out and manually re-entered those two orders in the restored database... but I thought I could sort it out right away... and the orders kept coming in... Live and Learn!

redheads:

Also time to note that it seemed like a pain to keep two stores going (full mods on both) but it would have saved a lot of time ...You don't have to keep the two going for very long ... just long enough to do the upgrade. Then delete the staging area version until you need it again, then make it fresh again. No need to do double-maintenance constantly unless you have other reasons for it, such as other ongoing changes you might be testing.

redheads:

FWIW -- for other learners out there... I did keep a backup of the 1.3.7 store AND the database... and when I put he store back on-line it seemed to be working. When I switched it back on-line two orders came in, so I opted not to restore the 1.3.7 database. In retrospect I SHOULD have just printed out and manually re-entered those two orders in the restored database... but I thought I could sort it out right away... and the orders kept coming in... Live and Learn!If you didn't have a staging area, yes, that might have been a handy alternate approach. I still strongly advise the separate staging/testing area as a safer and simpler approach. Makes it easier to go backwards if needed, and very quick to go-live with an update when ready.