Going to 1.5.4, will moneybookers still work?

I have 1.5.0 with moneybookers payment module. It's said that the module needs to be reinstalled.

So should I:

• remove the module
• backup my database (then without payment module info)
• install 1.5.4
• make the new database from backup
• upgrade database
• install moneybookers
  and all's well

kalastaja:

I have 1.5.0 with moneybookers payment module. It's said that the module needs to be reinstalled.

So should I:

• remove the module
• backup my database (then without payment module info)
• install 1.5.4
• make the new database from backup
• upgrade database
• install moneybookers
  and all's well

How about just following the guidelines at: http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

If done this way, then your site can remain online as-is while you work out whatever issues might pop up while trying the new version?

So then I don't need to worry about the payment module?

BTW: it's from September 2012 - is it still "state-of-the-art" for 1.5.4?

kalastaja:

So then I don't need to worry about the payment module?

BTW: it's from September 2012 - is it still "state-of-the-art" for 1.5.4?

Worrying about it on the new system as compared to disabling your existing are two different things. Certainly the functionality and coding of the existing payment module should be reviewed for potential upgrade based on the new code/requirements, but that is the case for any software. Besides, the data that will remain in the database assuming that the payment module is not installed after the software upgrade is only taking up some space. And technically the plugin's install/remove process should work regardless. Whether a payment can be processed (securley?) when installed under ZC 1.5.4, now that's the real question.

Ok; I was more worried about possible conflicts in the db versus the code - i.e. the db settings assumes that the module is present, but it's not in the code.

My scenario:
When I install ZenCart 1.5.4 on my 1.5.0 database (copy) I can upgrade it (with the contents) to 1.5.4 - all's well.
I'll then continue the zc_install and install the 1.5.4 code and with my own customizations (see btw below) - all's well.
As the 1.5.0 site is open there are a few new customers, before I can switch to 1.5.4 - not good!
Can I do ONLY a database upgrade - new db 1.5.0 copy to db 1.5.4 - no code installation/upgrade, as only the db contents has changed!

BTW: Which files does the zc_install alter? Can I edit the installation folder (a priori) with my customizations or should I edit the installed files/folders (a posteriori)?

Addition to previous:
The 1.5.0 contains a.o. customized customer info (multiple tables), so I just can't manually sql the table entries to 1.5.4. I need to start from the latest 1.5.0 and upgrade the structure to 1.5.4 leaving all customizations and the corresponding entries (from 1.5.0) intact. Isn't that what the db upgrade chain (1.5.1-1.5.2-1.5.4) does?

If you follow the method described in this article:
http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

... then it will lead you to create a TEMPORARY test site on 1.5.4, so you can sort out all your issues in a safe place. THEN apply the upgrade to your old/REAL LIVE SITE directly, but only after first having done all the testing on the temporary site so that you know what settings you'll need to adjust, what mods you'll need to upgrade, etc, so that the downtime on the old site will be as brief as possible.

That approach ensures none of your database content will be lost: no loss of new customers or new orders, etc. And preserves all custom fields.

Read through it. It'll be helpful.

Ok,

Point 3. Replace all the Zen Cart php files/...
It means delete the old and in with the new!? This takes a while and (?) the site can't handle showing the down-for-maintenance when all the files are gone? This also requires me to change the file permissions for the new files on the website.... (more time)

Point 4....choose database-upgrade
So I can do a database ONLY upgrade (zc_install) - good!

BTW: Which files does the zc_install alter? Can I edit the installation folder (a priori) with my customizations or should I edit the installed files/folders (a posteriori)?
How about the "a priori/posteriori" and in zc_install "Upgrade Cfg files" - what does it actually do?

kalastaja:

Ok,

It means delete the old and in with the new!? This takes a while and (?) the site can't handle showing the down-for-maintenance when all the files are gone? This also requires me to change the file permissions for the new files on the website.... (more time)

So I can do a database ONLY upgrade (zc_install) - good!

How about the "a priori/posteriori" and in zc_install "Upgrade Cfg files" - what does it actually do?

Can't tell if the doc is in parallel providing a response; however: No replace does not mean delete and add new.. It means overwrite, replace, copy over... All of the files never disappear at once, worst case (and this depends on each server method, software, etc...) one file "disappears" momentarily for each file being processed by the server in the upload/replace scenario.. Talking down in the dirt details here, but overall, the site will continue to "function" as this replacement is occurring at least in the grand scheme of things going on..

Database upgrade only yes.
zc_install for a database upgrade situation modifies no php files upon execution. The Upgrade cfg files, I think if I remember correctly simply build configure.php files using the current data which helps for those upgrading from significantly older versions of ZC. It's been a while since I've used/tested that feature as I typically either do the full install or take a known working version of a full install and modify the files as applicable for the site being worked... If I experimented with that feature it might save me a few minutes of editing, but I also have a feeling it won't as I'm guessing I have to still answer all the questions that I already know the answers for and could simply copy and paste as I need to... That said, the suggested route is to use the tools and instructions provided/available on this site as deviating from those can result in unexpected/undesirable situations. Backup/backup/backup...

Specifically regarding: "a priori/posteriori"... There are no customizations expected to the zc_install folder and sub-files/folders. Beyond that customizations fall into the instructions (link) that were previously provided... Taking one step at a time is the general suggestion, or at least be able to restore back to a known condition... Going from nothing to everything and then finding an "error" could result in a lot of trouble-shooting if backups are not made along the way...

kalastaja:

It means delete the old and in with the new!? This takes a while and (?) the site can't handle showing the down-for-maintenance when all the files are gone? This also requires me to change the file permissions for the new files on the website.... (more time)
There are LOTS of ways to accommodate long-upload times, including something as simple as uploading to a separate directory, and then merely moving it into place when you're ready to make the switch. "Moving" could be as simple as renaming folders, or telling your FTP program to move a folder to a new location. The best approach really depends on the tools you choose. If you don't know what you're doing, then simply choosing to upload /includes/ to /includes_new/ temporarily would suffice, and then when it comes time to go live, rename /includes/ to /includes_old/ and /includes_new/ to /includes/. Repeat similarly for other folders. Pretty simple really.

kalastaja:

So I can do a database ONLY upgrade (zc_install) - good!only after first updating all the PHP files, else you'll have PHP code that doesn't match the database content properly, and will get an error message saying the same. Follow the instructions, in order.

kalastaja:

in zc_install "Upgrade Cfg files" - what does it actually do?
That was for upgrading from v1.1.x to 1.2.x where the configure.php files had a significant change.
Unfortunately, while the 1.5.x config files also had a few notable updates, the zc_install doesn't auto-update your old configure.php files. But the old config files should work fine. Nevertheless, if you wanted to copy the new temporary 1.5.4 configure.php files to your live site after the upgrade, you could do that by hand, and then manually make a small edit to remove your temporary working directory name from any paths that contain it.
If you're stuck with how to do that, then post again here after you've got your complete temporary site up and working and fully tested. Post your new configure.php file contents here (masking only the database password), and we'll help you make the necessary change. It's very simple and brief, and can be done just before you're ready to actually apply the changes to the live site.

only after first updating all the PHP files, else you'll have PHP code that doesn't match the database content properly, and will get an error message saying the same.
So (once and for all) I must first update the code - keeping the site down for maintenance - then update the db and make a few test runs before removing maintenance state!?

My dilemma is that the shop is on root level, so there is really no way of just renaming the test folder! So I'll just copy (/overwrite) the code contents with WinSCP.

PS. Isn't the 1.5.4 db a "1.5.0 and more", whereby I could run it on 1.5.0 code? The 1.5.4 doesn't remove anything does it.

kalastaja:

PS. Isn't the 1.5.4 db a "1.5.0 and more", whereby I could run it on 1.5.0 code? The 1.5.4 doesn't remove anything does it.

Ok, DrByte you've said that 1.5.0 code can't run a 1.5.4 database - but I don't understand why (stupid me)! Doesn't the db upgrade have to be either a superset (1.5.0 and more) or it removes data (my customized data might be lost) - those are the (only?) two options!

BTW: I've read the help-pages suggested and they are straight forward! It's just the theoretical issue above!

kalastaja:

So (once and for all) I must first update the code - keeping the site down for maintenance - then update the db and make a few test runs before removing maintenance state!?

My dilemma is that the shop is on root level, so there is really no way of just renaming the test folder! So I'll just copy (/overwrite) the code contents with WinSCP.

PS. Isn't the 1.5.4 db a "1.5.0 and more", whereby I could run it on 1.5.0 code? The 1.5.4 doesn't remove anything does it.

Updating should not be considered a one step/one-click process... You are running a business or providing a service... Going down the path of working with just your live site files to do the upgrade is like possibly closing a store for a week to change a lightbulb... At least that is what I understand from the above post and believe others would consider following as well.

The files affect the data, the data supports the files. I will say this about updating the database without updating the parallel code. Perhaps it wasn't the right way to code, but there are some plugins that make a decision on how to operate based on various version information. In some cases that code bases the decision on the version of the database because after the initial transition of installing/upgrading the database, they are expected to match or at least be of known values... This is based on the published methods of operation. It is not published to upgrade the database in advance of the software. There is discussion about it and in some cases (unaltered or vanilla install) where no negative effect is seen, but that's somewhat of acting in a vacuum.

The "delimna" of the store being in the root directory is truly a non-issue. There are directions provided on moving a store from a sub-directory up a level. In fact there have been others that basically suggest that this would be an opportune time to make future upgrades easier for you. Without all the hub-bub of knowing the full path of your files, let's just say your current store is located in pub_html. Your upgrade store is is located in pub_html/new. Your web address is www[dot]mystore[dot]com, so your upgrade site is www[dot]mystore[dot]com/new.

Once you have things figured out on your new store, and everything works, you are able to upgrade/update the data in your sleep. You could in effect change the file location to which www[dot]mystore[dot]com points (this assumes that the host offers that type of control over the urls.) So, www[dot]mystore[dot]com could take a guest to the file location public_html/new which is where your files for your store reside... Okay, so didn't go over some of the other details, but these things are covered in various FAQs and wiki posts...

Comes down to, if you choose to do/start an inplace upgrade, best of luck to you as you are likely to have your store in maintenance mode until it is done... Think of thebusiness that is done, the visitors thaat check out your site, how many of those are going to see the construction sign and go elsewhere. If they happen to have/find your email address, what will be your response to the question: when will you be online again?

Yeah, it can take a while to externally ftp files from one location to another, if you must transfer in that method and your only development location is your live server, then without using some of the more advanced tools, you could ftp to your local computer, then ftp to your live site. Lots. Of opportunity for things to go wrong, but...3eally, cpanel filemanager type method would serve somewhat better, just have the local server copy from the sub-directory to the root directory...suggested outage reporting time: 30 minutes to transfer and test. I personally prefer a reported short outage time over a potentially buggy usage while files are being transferred. Though thesite could remain fully active while the upgraded file were transferred. Whatever. Floats your boat on that one I think. :)

kalastaja:

Ok, DrByte you've said that 1.5.0 code can't run a 1.5.4 database - but I don't understand why (stupid me)! Doesn't the db upgrade have to be either a superset (1.5.0 and more) or it removes data (my customized data might be lost) - those are the (only?) two options!
There are a number of things taking place in the database upgrade beyond what you're considering, including:
v1.5.3 changed the way passwords are stored, so using older code against the newer database (or vice-versa) will make login impossible.
v1.5.2 added extra fields for country enable/disable, so mixed versions will give SQL errors
and a handful more.

I don't understand why this is an issue ... running zc_install to update the database takes just a few seconds, and preserves all existing data intact.

mc12345678:

Yeah, it can take a while to externally ftp files from one location to another, if you must transfer in that method and your only development location is your live server, then without using some of the more advanced tools, you could ftp to your local computer, then ftp to your live site. Lots. Of opportunity for things to go wrong, but...3eally, cpanel filemanager type method would serve somewhat better, just have the local server copy from the sub-directory to the root directory...suggested outage reporting time: 30 minutes to transfer and test. I personally prefer a reported short outage time over a potentially buggy usage while files are being transferred. Though thesite could remain fully active while the upgraded file were transferred. Whatever. Floats your boat on that one I think. :)
And one can put the files into a subdirectory, and then merely "move" them using the FTP program.

kalastaja:

Ok, DrByte you've said that 1.5.0 code can't run a 1.5.4 database - but I don't understand why (stupid me)! Doesn't the db upgrade have to be either a superset (1.5.0 and more) or it removes data (my customized data might be lost) - those are the (only?) two options!

BTW: I've read the help-pages suggested and they are straight forward! It's just the theoretical issue above!

One thing that sticks out in my mind related to specific database differences of ZC versions is password security... Passwords are maintained in the database, upgrading the database in a way modifies the passwords, older code, doesn't know how to interact with newer style passwords...

As for "removing" something... First of all, you make backups, what is to be lost if you can restore data that you backed up... Second of all, testing... Input/output what changed? The specific process(es) performed bythe zc_install code makes changes (if any are needed) only to the specific tables and fields that require changes. If there is a field to be removed (which can't say I've seen that, usually at worst it is moved/renmaed) it would be published in the "instructions" or writeup of the specific version and it's changes... But it doesn't go: oh look a table I didn't create let's delete it... ZC is not an over controlling animal... It's open source which generally means written to allow anyone to do anything with it... Not to lay claim and force others to submit. I kind of look at it as: there's what works properly and there's everything else. :)

Thanks for your patience - slowly I get it....

Is there any simple list for db-changes as there is for changed files?

kalastaja:

Thanks for your patience - slowly I get it....

Is there any simple list for db-changes as there is for changed files?

"Simplest" list I know of is the information in the sql files themselves. Located in the zc_install folder... Every database change made to go from way back when to now is covered...

kalastaja:

Is there any simple list for db-changes as there is for changed files?
Why are you asking? If you properly use zc_install to do the database upgrade, it will NOT LOSE ANY OF YOUR DATA, so spending time focused on db changes IS NOT THE BEST USE OF YOUR TIME while trying to do an upgrade.

OK, sorry!