Hi all can i upgrade this beta 2 from the first beta or i need to do a new install? its on my host.
Hi there,
Yess you can upgrade.
You have to make a backup from your database (to be sure). Do not compress the database please, just a sql- file (compressing is an option in the backend).
You can copy all files from the new beta 2 Except for the config.php. You have to keep your own config.php and after you copied all the new files, copy you öld"config.php to the standard directory.
Rgds
Daniel
Frustrated about no upgrade from 2.0.1 to 2.0.2, I set out to do an actual upgrade, not just something that “would work”.
The attached tar archive contains 3 files:
upgrade_readme.txt - instructions
list.2.0.2.rm - a list of files to be removed after installation
upgrade.sh - the script that does the work.
The readme.txt file is as follows. There is no implied fitness for use, but this did work for me and has has a pretty fair amount of testing. But USE AT YOUR OWN RISK.
Have fun…
tony
upgrade_readme.txt:
It is probably best to have upgrade.sh and list.2.0.2.rm in a separate directory than your document root.
It is recommended to run this from the document root as “
list.2.0.2.rm contains a list of files (not directories) that were in 2.0.1 but not in 2.0.2.
Changes you may need to make to the script:
-
Verify that the 'archive' variable points to where your 2.0.2 archive lives.
-
Verify that the 'remove_list' variable points to where you installed list.2.0.2.rm
upgrade.sh does the following:
1) checks whether it thinks an upgrade has already been done by the presense of
core/fn.common.php (it was named core/common.fn.php in 2.0.1)
2) Determines whether it's being run from the document root or from another directory.
If running from another directory, you must give the full path to the document root as
the only arguement to upgrade.sh. I.e. "upgrade.sh /home/foo/public_html". Otherwise
upgrade.sh will assume that you're in the document root and use "." instead.
3) Displays a list of config variables that it found in the old config.php. DB name, user, password, etc.
are determined from what it find. If this is incorrect, DO NOT CONTINUE.
4) Backup both the current document root and the database. The backup files are named backup.2.0.1.tar and
backup..sql respectively.
5) upgrade.sh then goes and changes any directories it finds named 'include' to 'controllers'. If you have
added directories named 'include', you may have to manually change these back.
6) It then removes all the files (not directories) contained in 2.0.1 but not in 2.0.2. The file naming
convention changed between 2.0.1 and 2.0.2.
7) It then installs the new archive referenced by the 'archive' variable in the script.
8) It then updates the DB with the changes from 2.0.1 to 2.0.2. These changes are briefly:
1) Added column order_id to cscart_gift_certificates_log and creates a new index on order_id
2) changes the primary key for cscart_polls_answers to key on multiple fields
3) Removes all of the cscart_rev* tables.
9) It then updates the variables in config.local.php from what it found in the old config.php
10) The script then tries to identify any files in the skins/basic directory that are different
than var/skins_repository/base. It does NOT modify these files. Instead, if it finds differences
the filename will be printed to the screen and the file ./skin_differences.txt will contain the list
of files that are different. Your mileage may vary so there's not attempt to fix anything it finds there.
11) Finally, it removes var/cache and var/compiled to prevent any conflicts between the versions.
12) There is an area at the end where you can add any local changes you want to do. Mine are in there
but are conditional.
There is no implied fitness for use or guarantee that this will work for you. It works for me and I hope it will
be useful to you.
If anyone wants to fix up the sed editor command for parsing the config.php names, I'm all ears. But this one works
so I moved along!
Tony Birnseth
EZ Merchant Solutions
Frustrated about no upgrade from 2.0.1 to 2.0.2, I set out to do an actual upgrade, not just something that “would work”. You might have to re-load your logos when done if they were uploaded from your ‘local’ machine.
1/2/09 - defect discovered in javascript block manager code. If you have a block_id in the blocks_manifest/area.tpl file that is unknown, it will exponentially recreate the blocks contained in the template file. You might need to “fix” the template file manually. – tb
I posted this briefly yesterday, but ran into a problem where old files in the admin skins directory were causing javascript failures. I resolved this by recreating the skins directory from the 2.0.2 distribution and saving the old skins directory for reference.
The attached tar archive contains 3 files:
upgrade_readme.txt - instructions
list.2.0.2.rm - a list of files to be removed after installation
upgrade.sh - the script that does the work.
The readme.txt file is as follows. There is no implied fitness for use, but this did work
for me and has has a pretty fair amount of testing. But USE AT YOUR OWN RISK.
Have fun…
tony
upgrade_readme.txt:
It is probably best to have upgrade.sh and list.2.0.2.rm in a separate directory than your
document root.
It is recommended to run this from the document root as “
list.2.0.2.rm contains a list of files (not directories) that were in 2.0.1 but not in 2.0.2.
Changes you may need to make to the script:
-
Verify that the 'archive' variable points to where your 2.0.2 archive lives.
-
Verify that the 'remove_list' variable points to where you installed list.2.0.2.rm
upgrade.sh does the following:
1) checks whether it thinks an upgrade has already been done by the presense of
core/fn.common.php (it was named core/common.fn.php in 2.0.1)
2) Determines whether it's being run from the document root or from another directory.
If running from another directory, you must give the full path to the document root as
the only arguement to upgrade.sh. I.e. "upgrade.sh /home/foo/public_html". Otherwise
upgrade.sh will assume that you're in the document root and use "." instead.
3) Displays a list of config variables that it found in the old config.php. DB name,
user, password, etc.
are determined from what it find. If this is incorrect, DO NOT CONTINUE.
4) Backup both the current document root and the database. The backup files are named backup.2.0.1.tar and
backup..sql respectively.
5) upgrade.sh then goes and changes any directories it finds named 'include' to
'controllers'. If you have
added directories named 'include', you may have to manually change these back.
6) It then removes all the files (not directories) contained in 2.0.1 but not in 2.0.2.
The file naming
convention changed between 2.0.1 and 2.0.2. Note: this may miss files that were
previously
in 'include' directories which are now in 'controllers'.
7) It then installs the new archive referenced by the 'archive' variable in the script.
8) It then updates the DB with the changes from 2.0.1 to 2.0.2. These changes are
briefly:
1) Added column order_id to cscart_gift_certificates_log and creates a new
index on order_id
2) changes the primary key for cscart_polls_answers to key on multiple fields
3) Removes all of the cscart_rev* tables.
9) It then updates the variables in config.local.php from what it found in the old
config.php
10) It then copies your old skins directory to saved.skins_2.0.1_2.0.2 and then recreates the skins directory
with all skins that were distributed in 2.0.2. Note: the skins//mainfest
file is restored
as is the skins//customer/block_manifest directory.
11) Finally, it removes var/cache and var/compiled to prevent any conflicts between the
versions.
12) There is an area at the end where you can add any local changes you want to do. Mine are in there
but are conditional.
There is no implied fitness for use or guarantee that this will work for you. It works for
me and I hope it will
be useful to you.
If anyone wants to fix up the sed editor command for parsing the config.php names, I'm all
ears. But this one works
so I moved along!
Tony Birnseth
EZ Merchant Solutions