Quote Originally Posted by jakesee View Post
Hi schoolboy,

I am not sure about that... I think both ways it's risky. I never got manual update to work ever. =(

It would be easiet and safest if there's a step by step instruction which says which files to add, delete and edit. That is the best... rather than all the "automatic" update.
The procedure is neither difficult, nor risky, if you follow the "rules".

Rule one:
Use the over-ride system built into zencart when creating custom templates, or when building other add-ons. This ensures that key template, module and language files that are modified, will not be overwritten through an upgrade. For some files (and folders) there is no over-ride system (eg: all of admin, and many module files), so if these are ever changed you should keep a written record of changes made to areas where no over-ride file exists. Most people never have to do such changes.

Rule two:
Before you upgrade (or change files at any stage), create a back-up of the file(s) you are changing. One of the advantages of the over-ride is that (when done properly) the edited files are separated from their core originals. If - after a file edit - your webshop falls apart - simply remove the newly-created override file. This will force zencart to reference the ORIGINAL core file again and the store will continue working. You then go through the file you edited to see where errors may have been made, and then try again.

Rule three:
Use a FILE COMPARISON tool such as WINMERGE to help you establish the updates to files in the new version, compared to their counterpart files in the old version. Dr Byte has indicated that the CHANGELOG will reference all files where changes have been made in a new version, so if you systematically go through these CHANGELOGS, you can soon determine if any of the changed files in the upgrade version affect any CUSTOM files in your installation.

For example...
The changelog may indicate that this file has been altered in the upgrade version:
/includes/languages/english.php

If you have in your installation:
/includes/languages/MY_TEMPLATE/english.php

... then you will need to run BOTH these files through WINMERGE to see what has been changed.

Winmerge will show you the contents of the two files, side-by-side, and will highlight all instances where the code does not match.

Using common sense mostly (and a smattering of php knowledge) you will then need to "copy over" changed lines of code (FROM the upgrade file TO your custom file).

Winmerge allows you to do this quite easily.

Naturally, SOME of the differences highlighted by Winmerge will not be changed. For example, you may have changed a DEFINE for weight units from the core LBS to KGS. The upgrade file will still be in LBS, but obviously you want your weight label to be KGS so you ignore this difference.

You follow this winmerge procedure for ALL files you have (in the past) customised, that also are listed in the changelog.

We do lots of upgrades on the many stores we manage - some are heavily customised - but working with the changelog as our key reference, we seldom take longer than an hour or two to clip out updated code from the new version of a file to paste over its counterpart lines in the old file. Again, common sense tells us that we can ignore many of the changes - particluarly if these are just text strings in DEFINE statements.

ALL the above is done OFF-LINE, on a COPY of the relevant files. (We have a "mirror" of our webshops on a local machine where ALL updating and file esiting is done BEFORE it is FTP'd to the remote server. These "mirrored" webshops maintain the folder and file structures that exist on the remote server. Furthermore, they mirror them in REAL TIME because we make changes to the MIRROR files first... then FTP them to the server. In this way we know that a file on our local machine is always identical to its counterpart on the remote server. We DO NOT directly edit files on the remote server. We ALWAYS edit the mirror file first, and then FTP it to the server).

When we have finished manually "upgrading" relevant files, we take the site through its version upgrade.

Our "house rule" is to first put the store into Maintenance Mode and then make a CLONE of the database.

By putting the store into Maintenance Mode, you prevent all actions that may write data to the database during the upgrade. You don't want a customer to be half-way through placing an order during the upgrade procedure.

So we now have a static site (inactive) and a safe backup (clone) of the database.

Then, using the CHANGELOG as our guide, and the notes we made of files changed through Winmerge, we FTP these files to their revelant folders on the server.

We then FTP the new version's installation folder to the server, and, following the procedures outlined in many tutorials on this forum, we perform the upgrade.

We TEST the site while it is still in maintenance mode.

If all goes well (which it does in 95% of upgrades), we take the store out of maintenance mode and the new, upgraded store goes live.

In a FEW cases, we may have customised the database. This is where our CLONE on the database proves its worth. If the upgrade has affected our database customisations, we use the CLONE as a reference to re-introduce those customisations. This requires MySQL knowledge and so should not be attempted by an amateur.

In most cases, upgrading a site takes us 2 to 3 hours.