Database upgrade/admin credentials fail

[earmsby]

I am in the process of doing an upgrade on a client's store from v. 1.5.1 to 1.5.5. I was at the point of restoring a back of the live shop into the test version for the upgrade and then running zc_install to upgrade the database. I can't seem to get past the admin credentials. I've double checked that the user name and password is correct and is a super user. I even changed the user name and password while logged in to the admin section to make sure I was using the right log in. I've deleted zc_install and verified that I can log in to admin with the log in info several times. But each time I retry to run the db upgrade, I get the message that the credentials are not correct.

Any ideas how to get past this?

[earmsby]

In some further searching, I found Dr. Byte's list of common causes for this problem:

Common causes of "Could not verify the AdminCredentials you provided." include:
- actually using incorrect admin username+password
- admin username being used is not assigned as a superuser and thus doesn't have rights to do major database changes such as an upgrade ... so basically an unauthorized or incorrect admin
- using mismatched DB_PREFIX which therefore tells ZC to look for admincredentials in the wrong admin table in the db
- import of wrong db, or failed import, or import with mismatched prefixes as above
- damaged admin table in db, perhaps with field lengths too short (not properly upgraded) and thus unable to store the newer longer password hashes
- confusion of PHP versions, back and forth between newer-to-older (such as imports from server->local->server), causing passwords to be mangled
- using old PHP versions generally
- needing to reset the admin username+password (see FAQ on how to do that, using phpMyAdmin)

I have eliminated most of these possibilities but I am concerned about the PHP causes. I don't quite understand what is meant by "confusion of PHP versions, back and forth between newer-to-older (such as imports from server->local->server), causing passwords to be mangled." But I suspect that is not the cause in my case as I am working on the upgrade on the same server as the live store - just in a testing directory and the PHP/MYSQL versions are the same.

The main reason for upgrading this ZC installation is because the host plan to upgrade PHP and MYSQL soon. When they do, then the current shop (v.1.5.1) will break. But if I can't now upgrade the database I'm not sure how to proceed without starting over from scratch and losing all the previous customers, products etc.


FWIW:

PHP Version: 5.4.27
Database: MySQL 5.1.73-cll

[earmsby]

Under the category of "the third time is the charm," I tried once more and this time I created a brand new super-user first that was not at all similar to any other admin user. I re-uploaded ZC_install and ran it again using the new log on I created and Voila! it worked.

Just thought I'd post this in case anyone runs into this and needs another solution to try.

[Website Rob]

Good to hear you were able to troubleshoot and solve your problem.

For yourself and those reading in the future, I wanted to clarify that when you created the "test" area or folder and Imported the live database into it, you also renamed the database. You would not want the "test" area to use the same database as the live site.

Also, using Apache password protect on the "test" folder is suggested. It will keep out prying eyes and prevent Search Engines from thinking you have two identical sites and penalizing you for it.

[earmsby]

No, the "test" store is using a copy of the live database which has been restored into a third database. So, I have three databases:

1. actual live store database
2. database with tables created in clean install of v.1.5.5
3. database with restored version of #1

They all have different names. :)

[acmaurer]

In some further searching, I found Dr. Byte's list of common causes for this problem:





I have eliminated most of these possibilities but I am concerned about the PHP causes. I don't quite understand what is meant by "confusion of PHP versions, back and forth between newer-to-older (such as imports from server->local->server), causing passwords to be mangled." But I suspect that is not the cause in my case as I am working on the upgrade on the same server as the live store - just in a testing directory and the PHP/MYSQL versions are the same.

The main reason for upgrading this ZC installation is because the host plan to upgrade PHP and MYSQL soon. When they do, then the current shop (v.1.5.1) will break. But if I can't now upgrade the database I'm not sure how to proceed without starting over from scratch and losing all the previous customers, products etc.


FWIW:

PHP Version: 5.4.27
Database: MySQL 5.1.73-cll

I've run into this problem more than once--although so far apart in time I have to re-learn the issue. In my case, at least, it's the table prefixes.

If you make a copy of the old/existing database to be upgraded, and then run an upgrade, you cna be stuck with a Catch-22:
- don't provide a prefix and zc_install creates a whole new set of tables
- provide a prefix and zc_install prepends that prefix with your existing prefix, i.e., "zen_zen_"

At least the 1.5.6 version no longer requires a prefix so that does simplify things a bit.

However your database tables end up, be sure the two config files contain the correct prefix. Nowhere in the install instructions does it tell you that.

It took me two installs, multiple configure.php file changes and two database creations to get the combination right. Hopefully this just reinforces DO IT ON A TEST COPY when building or rebuilding a site!

[mc12345678]

I've run into this problem more than once--although so far apart in time I have to re-learn the issue. In my case, at least, it's the table prefixes.

If you make a copy of the old/existing database to be upgraded, and then run an upgrade, you cna be stuck with a Catch-22:
- don't provide a prefix and zc_install creates a whole new set of tables
- provide a prefix and zc_install prepends that prefix with your existing prefix, i.e., "zen_zen_"

At least the 1.5.6 version no longer requires a prefix so that does simplify things a bit.

However your database tables end up, be sure the two config files contain the correct prefix. Nowhere in the install instructions does it tell you that.

It took me two installs, multiple configure.php file changes and two database creations to get the combination right. Hopefully this just reinforces DO IT ON A TEST COPY when building or rebuilding a site!

The problems identified above seem unusual. I've never seen that the install *requires* a prefix and when using a prefix I've only ever seen one table that might get created with the prefix provided twice. That double prefix table iwas created to capture information about the install process, but not used for anything in routine operation.

As to the database prefix, while I have not recently reviewed the straight install instruction, the guidance for upgrading does identify the need to match the database prefix for the new install to that of the old: http://www.zen-cart.com/entry.php?3-...d-of-upgrading

Beyond that, one issue that has been identified in trying to use existing admin credentials in a site that has sanitization applied is if the username and/or password has a character that would be sanitized. When/if that occurs, then applying the admin reset sql applicable to the old store's database before attempting the upgrade has been functional: https://www.zen-cart.com/content.php?44