zc_admin folder and database update?

[jakesee]

Hi,

I used cpanel/fantastico to upgrade my zen cart from 1.3.8 to 1.3.9g but then i got this message:

Your database appears to need patching to a higher level. See Tools->Server Information to review patch levels.

And then there is a new zc_admin folder. May I know what is the zc_admin folder for? Can I delete it or use this as the new admin folder?

Many thanks!

[schoolboy]

This is one of the (many) risks you face when using Fantastico to do upgrades.

You should restore your backup (the one you made before you did the upgrade), and do upgrading manually.

Plenty of advice and help on the forum...

[jakesee]

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.

[gjh42]

A step by step instruction with specific files would not be possible, as each installation might be different depending on what mods have been done. You could go through the changelog and just upload the files in that (checking to see if any of them has a custom template copy), but that one-at-a-time method has an even higher risk of missing or misplacing something.

[jakesee]

@gjh42 I mean if with each new installation, there is a proper list of items to replace then it should be good. So at least I know what is going on behind the "automatic" and if anything goes wrong i can fix those individually instead of deleting and start all over again! And maybe you are right, the changelog could be that list. The other method can be to run a script to append every file with the version number so "manual" users can double check. Just suggesting.

Anyway, thanks for the advice everyone, I managed to get rid of the warning by downloading a copy of 1.3.9g and upload ONLY the zc_install folder then run zc_install/index.php and "upgrade database". I don't know if that fixed the database or merely got rid of the message... since there is (appears to be) no way to confirm it. It's sad that I have learnt to not trust "automatic" updates with zencart/fantastico =(

Thereafter, I got it upgraded to 1.3.9h already, although there are still problems I have with 1.3.9h, albeit different... *sigh*

[DrByte]

You might take a visit into the /docs/ folder of every Zen Cart release zip ... where all the files that are changed between each version are listed.

[schoolboy]

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.