Upgrading database 1.3.9 to 1.5.0 Admin password incorrect

[ideasgirl]

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?

[DrByte]

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.

[ideasgirl]

The database page:



Settings on patch page:


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).

[RodG]

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.

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

[DrByte]

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.

[RodG]

I must respectfully disagree with you.

I'm much to clever than to argue 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)

I really must try to stay atop of these changes.

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

She did indeed. How embarrassing.

- 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. :)

@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

[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?...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.

[ideasgirl]

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?...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! Worked like a charm.... You are a genius!

[RodG]

THANKS! Worked like a charm.... You are a genius!

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

Cheers
Rod

[ideasgirl]

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?