Questions on 1.5.7 upgrade

[GoldBuckle]

Trying to upgrade from 1.5.4 to 1.5.7 on a hostmonster server. 1.5.4 in root public_html folder on php 5.6. Backed up database, backed up 1.5.4 site and saved copies to local computer. Created new db and imported backup db into new one. Created new subdomain folder and copied 1.5.4 site to it. Edited both config files to reflect the new db. New test site functioning. Requested hostmonster to turn PHP 7.3 for the new subfolder only as when they previously turned it on for the whole domain it broke the root site. After that I was still getting an .htacess message and a GZIP compressions message. Requested hostmonster to fix that and was escalated to higher support. Got email that they fixed it but it appears they did something to the whole domain as now I can't put the original site in maintenance mode. Anyway, I have downloaded the new 1.5.7 files and extracted them to local computer am ready to ftp the new zencart 1.5.7 files to the test folder and I have a few questions:

1) on my running 1.5.4 site and in the new test directory the admin folder is renamed (i.e. public_html/hiddenadmin/), do I need to change that name back to /admin/ before uploading the new 1.5.7 files or do I need to rename the admin folder in the 1.5.7 files to /hiddenadmin/? The zencart docs to not make that clear.

2) When upgrading from an older version of Zen to 1.5.7 it states to copy your existing files into the test directory (done that). When you upload the new 1.5.7 files to that test directory do you upload all the 1.5.7 files or just the files that have changed?

3) Do I use the dist-config.php files and rename those to config.php or do I use the old config.php files? Does the installer upgrade those automatically?

[mc12345678]

Isn't this a continuation of: https://www.zen-cart.com/showthread....24#post1371824 ?

I believe as somewhat indicated in that thread that this is being made harder than it should be and it has a little to do with interpretation of the intent and expectations behind the "older" instructions that you are following.

But to answer the questions:
1) doesn't matter. If two or more "admin" like directories are identified during the zc_install process to upgrade the database, the installer will identify the presence of two such directories and request to know which is to be updated. Further, generally in the install/upgrade process if something isn't addressed, its because it doesn't need to be addressed and that those things directed are important. For example one really shouldn't try to login to the admin until the database has been upgraded to whatever current version is installed... There is a step that effectively says to get into the admin and there is no reference to logging into the admin before that...

2) Answer this with more of a series of questions: If you upload ZC 1.5.7 files to a directory that contains files from another version, are you really placing just that versions files on the server for access? Aren't those other files part of the old version and not part of the new version? Depending on where in the file structure the files are located, the software may try to load them but they have nothing to do with the current version and may actually cause problems with the load... Before doing this "step" what is it that has been validated? What is this step intended to do?

As to which set of files the entire fileset versus the changed files? Okay, so look at this way. If you never had a previous store, what would you do... Load all of the files correct? (Difference between what you had and what you are going to have is nothing to a full version.) So... If you were to "load" the different files, that includes removal of files doesn't it? If it doesn't exist now in the new fileset, why should it exist after loading the new fileset? You may be able to answer "because" for a few of the files (changes that have been made to the original store)…

3) If you were *really* doing a thorough install to a new version... The first thing that would have been attempted associated with the new version is to see if it would work in the current/new environment... So, if sticking to the "old" instructions, then now that the temp location has the old site working well this means that all of the "internet" triggers are present to support a site operating at this location. Delete the temp site, install the new software to work off of the new temporary location, consider using the default product so that can see operation... This will or is expected to provide/produce new includes/configure.php and YOUR_ADMIN/includes/configure.php files. Again this would be a new install to the same temporary location with the same "temporary" database (not your live store). You could also opt to use the configure.php files that were just there and "functional" to do the "fresh install" of the new version in this temporary location. The zc_install process will recognize that the files are out-of-date and try to write/rewrite the file to what is expected... Now.... Mind you all this great and nifty "auto-rework" that is done by the installer could always be thwarted by a server's configuration that prevents certain operations from being done automatically.. When that is the case, one needs to manually do a setup. I would copy not rename the dist-configure.php files as necessary to obtain a functional store if I had to manually edit a file like that and couldn't use the zc_install process. I have not ever been in a situation though where the zc_install process couldn't auto-create/rewrite the configure.php files...

Anyways, after the files are confirmed functional in such a "base" system, the next thing that can be done is to see if the database from the old store can work in the new store... So the database from the old store is loaded to the new temporary location. At this point new software is pointing to an old database... So need to update the database... Back to zc_install. If the new store's DB_PREFIX aligns with what would effectively be a DB_PREFIX in the new database then you should be presented with an option to upgrade the database... Ie. if includes/configure.php has define('DB_PREFIX', 'bob_'); and you look through the records of the sql file for the old database and you see create table bob_products as an example, then at some point the database represented in that file had a prefix of 'bob_'. But if instead your includes/configure.php file has 'sam_' and you look through the sql file and only find bob_products, then there is a mismatch and the two configure.php files need to be modified to match... Again though of course, using the old configure.php file(s) as part of the first zc_install process should result in the DB_PREFIX being carried over from the old store to the new store...

Whatever you decide to do, keep notes. When something goes wrong and help is requested, you'll be asked questions about the process followed. The more detail, the easier to identify the issue.

Note that the preferred/recommended method of doing an upgrade these days is to upgrade by rebuilding... Install new store software, upgrade copy of old database to new version, incorporate changes that were made to the old store into the new store (where still considered necessary

and noting that even those older changes may need to be updated to retain the operation and capability they offered

).