resetting admin password fail

[soxophoneplayer]

zc 1.5.5a

I mucked up my test site again. Password expired/new password required - no matter what new password I used it keeps rejecting.

Tried this from faq, with error as noted:

Error

SQL query:

INSERT INTO zen_admin (admin_name, admin_email, admin_pass, admin_profile) VALUES ('Admin', 'admin@localhost', '351683ea4e19efe34874b501fdbf9792:9b', 1)

MySQL said: Documentation
#1292 - Incorrect datetime value: '0000-00-00 00:00:00' for column 'pwd_last_change_date' at row 1

Is it possible this is because I have had use this solution within past year?

There was another db edit I found online that I tried - copying a code into the password field to change password to Admin. Also had used successfully within past year, and also now rejected.

As an aside, I wish there was a way to turn this password off on test sites.

Email is not set up on test site so can't click the password forgotten link on login box.

Any other ways to re-set password when can't login?

[carlwhat]

the fact that you used this in the last year should not affect anything. i tried this exact SQL statement twice on my test sever with no problems.

the problem is related to the structure of the table and the data that is already in it.

what happens when you try:

select * from zen_admin

does that also error out? or does the sql command successfully execute?

i would try the following command to see if it works:

update zen_admin set pwd_last_change_date = '0001-01-01 00:00:00' where pwd_last_change_date = '0000-00-00 00:00:00';

if that command successfully runs, then i would try your SQL statement again.

i'm operating on a v155; i have not looked to see if the table changed in v155a.

good luck!

[DrByte]

Two issues:

a) as for broken passwords: If you've been changing PHP versions between 5.2 and 5.3 and 5.4-or-newer then you might have mangled the encryption of those passwords, thus preventing login. (Moving to newer PHP is not a problem, but then moving to older again can wreck them, even if you move forward again.)

b) as for the datetime issue, it appears your "admin" table has 0000-00-00 as defaults on its datetime fields. A fresh install of v155a uses 0001-01-01 (on all datetime fields in all tables) to avoid MySQL 5.7 strict no-zero-date rules.

[carlwhat]

Two issues:

a) as for broken passwords: If you've been changing PHP versions between 5.2 and 5.3 and 5.4-or-newer then you might have mangled the encryption of those passwords, thus preventing login. (Moving to newer PHP is not a problem, but then moving to older again can wreck them, even if you move forward again.)

b) as for the datetime issue, it appears your "admin" table has 0000-00-00 as defaults on its datetime fields. A fresh install of v155a uses 0001-01-01 (on all datetime fields in all tables) to avoid MySQL 5.7 strict no-zero-date rules.

you can try your SQL statement as follows:

INSERT INTO zen_admin (admin_name, admin_email, admin_pass, admin_profile, pwd_last_change_date) VALUES ('Admin', 'admin@localhost', '351683ea4e19efe34874b501fdbf9792:9b', 1, now())

i suppose it will be nice when servers are running mysql versions >= 5.6.5 and the default can be the current_timestamp. makes that date info so much easier to maintain.

[soxophoneplayer]

Two issues:

a) as for broken passwords: If you've been changing PHP versions between 5.2 and 5.3 and 5.4-or-newer then you might have mangled the encryption of those passwords, thus preventing login. (Moving to newer PHP is not a problem, but then moving to older again can wreck them, even if you move forward again.)

b) as for the datetime issue, it appears your "admin" table has 0000-00-00 as defaults on its datetime fields. A fresh install of v155a uses 0001-01-01 (on all datetime fields in all tables) to avoid MySQL 5.7 strict no-zero-date rules.

My WAMP server is php 5.6.15 For some forgotten reason I wasn't able to install 5.7. My Live server (Camelot) is 5.5.3.
When I got mangled I had added the 1.5.5a files to both test and live sites and was fiddling with test site to try and get matchHeight happening. In the middle of fiddling I got the 'new password required' event. My fiddling included uninstalling and reinstalling mods to test for conflict with matchHeight. I had just uninstalled IH4 when trouble hit.

I tried fixes as prev noted to no avail, as well as suggestions from carlwhat on this thread. Also tried using my backup shop files and back up db - both backed up after 1.5.5a changes but before myfiddling. Also tried using several backups prior to the 1.5.5 changes.

I tried to add the 1.5.5a zc_install and run it, but it said database was up to date and only option was a clean install so I abandon that.

In the end I downloaded live database, merged it with the failed 1.5.5.a test version - only to change config settings for the test site version of wordpress4zen mod, and that worked (with existing live site user/password).

Something ironic about recusing a test site with a live site ;o)