Upgrading database 1.3.9 to 1.5.0 Admin password incorrect

I've seen several post like this one but no solution I've seen for my problem.

I always use DrByte's suggestion for upgrades. I upload all the files to a new directory on the site/server, I create a new database, I make a backup of old store and restore on the new one created for the upgrade, then I run the install.

I'm stock on this last page when the db is patched. I haven't upgrade any 1.3.9 to 1.5 (although I have installed 1.5 before). This database (old store) has 3 users/passwords. I've used the 3 of them without success. I get over and over the message Admin Password required to proceed with upgrade.

At the beginning I got:
-PHP Safe Mode = ON
I don't know if that hast to be with the failure but I'm notifying it. (I will work on this with customer though).

Any idea of what could be wrong here?

The only time I've ever encountered that same problem was when I'd used a different DB_PREFIX setting in the new store, so the upgrade was actually pointing to the new install's database tables, and not the imported data.

The database page:
[IMG]http://img685.imageshack.us/img685/523/50170736.jpg[/IMG]

Settings on patch page:
[IMG]http://img842.imageshack.us/img842/1300/83220814.jpg[/IMG]

As you can see the zen_ is being used on the database. I just rechecked also both config files to see if the prefix was there also written correctly (they were present and correct).

ideasgirl:

I'm stuck on this last page when the db is patched. I haven't upgrade any 1.3.9 to 1.5 (although I have installed 1.5 before). This database (old store) has 3 users/passwords. I've used the 3 of them without success. I get over and over the message Admin Password required to proceed with upgrade.

The users/passwords that you have stored in the database are not suitable for update purposes. The username/password required is the one that you have previously defined in your zencart configuration files.

ideasgirl:

As you can see the zen_ is being used on the database. I just rechecked also both config files to see if the prefix was there also written correctly (they were present and correct).

Are you 100% sure about the 'and correct' part?

The problem here is that we/you are only seeing half the picture... The half we are seeing is what your configuration files have to say. The half that we are are not seeing is the actual name of the DataBase (and its tables). These must match each other precisely. You can't state that the 'zen_' prefix in your configuration files are correct unless you can also state categorically that the database itself also starts with 'zen_'

Hopefully this helps a little?

Cheers
Rod

Rod,

I must respectfully disagree with you.

• The password used when upgrading IS indeed the admin password in the database, NOT from the configure.php files. Any valid administrator username and password is accepted (at least in v1.5.1 and older)
• She did indeed show that the tablename is zen_admin (see the screenshot)
• She did show that the configure.php file is set to use "zen_" as the database prefix (see the screenshot, which quotes the DB information directly from the /includes/configure.php file)

@ideasgirl, But as to why it's rejecting the password, I'm puzzled. I suppose you could comment out the section of code that validates the password and just force it since one would assume that if you're this deep into the code then you're also authorized to do the upgrade.

DrByte:

I must respectfully disagree with you.

I'm much to clever than to argue with you :)

DrByte:

• The password used when upgrading IS indeed the admin password in the database, NOT from the configure.php files. Any valid administrator username and password is accepted (at least in v1.5.1 and older)

I really must try to stay atop of these changes.

DrByte:

• She did indeed show that the tablename is zen_admin (see the screenshot)

She did indeed. How embarrassing.

DrByte:

• She did show that the configure.php file is set to use "zen_" as the database prefix (see the screenshot, which quotes the DB information directly from the /includes/configure.php file)

Hey, at least I saw that one. :)

DrByte:

@ideasgirl, But as to why it's rejecting the password, I'm puzzled. I suppose you could comment out the section of code that validates the password and just force it since one would assume that if you're this deep into the code then you're also authorized to do the upgrade.

I would've bet $$$ on this being a prefix or username/password mismatch. Now I'm stumped.

Cheers
Rod

Ya, I'm stumped too. I can't recreate the problem despite trying all manner of odd things.
Makes me lean back again to the more obvious thing: username/password mismatch ... but ideasgirl insists she entered them correctly.

I suppose the other possibility is that the password contains multibyte characters and the database export-then-import has mangled those characters due to encoding conflicts.

One thing I'd try before hacking any code is to simply insert the Admin/admin password from the Password Reset FAQ at http://www.zen-cart.com/content.php?44-how-do-i-change-or-reset-my-admin-password (only do the INSERT statement, the others aren't needed in your case) and use that for your credentials in the upgrader. If that works then the username/password from the db import got mangled, and that raises an alarm for you to inspect other possible data corruption problems.

DrByte:

Ya, I'm stumped too. I can't recreate the problem despite trying all manner of odd things.
Makes me lean back again to the more obvious thing: username/password mismatch ... but ideasgirl insists she entered them correctly.

I suppose the other possibility is that the password contains multibyte characters and the database export-then-import has mangled those characters due to encoding conflicts.

One thing I'd try before hacking any code is to simply insert the Admin/admin password from the Password Reset FAQ at http://www.zen-cart.com/content.php?44-how-do-i-change-or-reset-my-admin-password (only do the INSERT statement, the others aren't needed in your case) and use that for your credentials in the upgrader. If that works then the username/password from the db import got mangled, and that raises an alarm for you to inspect other possible data corruption problems.
THANKS! :hug: Worked like a charm.... You are a genius! :smartalec:

ideasgirl:

THANKS! :hug: Worked like a charm.... You are a genius! :smartalec:

I tried to tell DrByte that just the other day. He fobbed it of as 'experience' (he lied). :)

Cheers
Rod

Hahaha! Yeah, I know Rod.

DrByte, try to replicate this issue when the admin ID is NOT "1". Which is the only thing possible I can think about. The user level was "0" and I changed it later to "1" to see if that was the problem but didn't work. So the only thing (besides your explanation of possible mangled pass) that I can think of is that if the ID is not 1 could be an issue? :blink:

Dr. Byte, I am running into the same issue I think. ( I posted specifics earlier today here on this forum). First I am upgrading OK to 1.5.1 but the data does not show. I am changing the suffix to "zen_" in both configure.php files. The customer data and such shows up now, but I have to update the database to 1.5.1. At this point the admin password stops working, can not get the update done :-(

Similar issue. I've installed/upgraded from 1.3.9 to 1.5, 1.54, 1.55f, 1.56c and every time I have this password issue. I also do create via SQL in the new database the Admin user with password. Copy and pasting the SQL. I can see the admin user is created with admin privileges. That new username password is still not accepted. I also tried copying the encoded password in the field from the old database to the new database field via phpMyadmin. Still refuses to log in.

I don't see any evidence that the password is actually being checked in the upgraded database.
All the dates in all admin column database date fields are 0001-01-01 00:00:00. pwd_last_change_date, last_modified, last_login_date and last_failed_attempt. It's as though the form on the upgrade page is not actually checking the password in the database. If it were and it were failing, at least the date of last_failed_attempt would have a valid date. The dates never change.

I never use a database prefix. I've checked and triple checked to see if the script added a prefix after converting my old configure.php files. Prefix is blank. No database tables have a prefix.

According to the upgrade script animation, the database is being upgraded from 1.3.9 to 1.5, then to 1.5.1... all the way to the end, 1.5.5 or 1.5.6, which every I'm trying at the moment. At the last one no matter what version I try upgrading to, the last password check always fails. If the database is really being upgraded in all those steps, what happens at the last one that breaks checking the password?
I have nothing else to try except install from scratch. What else can I do???

Why would the first login check work and the last one fail?
I have no idea how to bypass the last password check. As you say, I'm this far in the upgrade, I obviously have rights to the files and database. How do I get past this???

Take a look at the similar threads and also post #8 of this thread. There was a change in creation method somewhere in the middle there.