Login with WP-Password doesn’t work any more after restore

Hi Martin,

To help us work out the cause of your problem, can you please send us a copy of the restoration log?
You can find this log in the ‘wp-content/updraft’ directory of your site via FTP.
The contents will be too long to post here directly, but you can use an online service such as Dropbox or Pastebin, and post the link here.

Best Wishes,
Bryle

Hi Bryle,
unlike backup logfiles, it seems not very comprehensive. I just changed the name of table prefix and domain, so it should be safe too.

0000.004 () Opened log file at time: Sun, 29 Jul 2018 17:19:11 +0000 on https://www.domain.de
0000.004 () UpdraftPlus WordPress backup plugin (https://updraftplus.com): 1.14.11 WP: 4.7.11 PHP: 7.0.24 (cgi-fcgi, Linux zaphod.ispgateway.de 3.14.79-grsec-pvops-xen-x64 #1 SMP Mon May 22 13:12:26 CEST 2017 x86_64) MySQL: 5.6.19 WPLANG: en_US Server: Apache/2.4.29 safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 20M | 22M) multisite: N openssl: OpenSSL 1.0.2l 25 May 2017 mcrypt: Y LANG: ZipArchive::addFile: Y
0000.004 () Free space on disk containing Updraft’s temporary directory: 403006.2 MB
0000.005 () Restore job started. Entities to restore: themes, others, db. Restore options: {“updraft_encryptionphrase”:””,”updraft_restorer_wpcore_includewpconfig”:false,”updraft_incremental_restore_point”:-1}
0000.027 () Will not delete any archives after unpacking them, because there was no cloud storage for this backup
0000.029 () Entity: db
0000.029 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-db.gz, type=db, info=a:0:{}, last_one=)
0000.029 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-db.gz, 0.4 Mb)
0000.031 () Database successfully unpacked
0000.032 () Restoring the database (on a large site this can take a long time – if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)…
0000.032 () Using direct MySQL access; value of use_mysqli is: 1
0000.041 () Tried to raise max_allowed_packet from 16 MB to 32 MB, but failed (Access denied; you need (at least one of) the SUPER privilege(s) for this operation, b:0;)
0000.041 () Max packet size: 16 MB
0000.041 () Entering maintenance mode
0000.041 () Enabling Maintenance mode…
0000.042 () Backup of: https://www.domain.de
0000.044 () Content URL: https://www.domain.de/wp-content
0000.044 () Uploads URL: https://www.domain.de/wp-content/uploads
0000.044 () Old table prefix: prefix_
0000.044 () Site information: multisite=0
0000.048 () New table prefix: prefix_
0000.050 () Processing table (MyISAM): prefix_options
0000.271 () Restoring prior UD configuration (table: prefix_options; keys: 3)
0000.297 () Processing table (MyISAM): prefix_users
0000.308 () Processing table (MyISAM): prefix_usermeta
0000.321 () Processing table (MyISAM): prefix_commentmeta
0000.331 () Processing table (MyISAM): prefix_comments
0000.342 () Processing table (MyISAM): prefix_links
0000.351 () Processing table (MyISAM): prefix_postmeta
0000.486 () Processing table (MyISAM): prefix_posts
0000.604 () Processing table (MyISAM): prefix_term_relationships
0000.617 () Processing table (MyISAM): prefix_term_taxonomy
0000.625 () Processing table (MyISAM): prefix_termmeta
0000.630 () Processing table (MyISAM): prefix_terms
0000.640 () Processing table (MyISAM): prefix_bt_blocks
0000.650 () Processing table (MyISAM): prefix_bt_layout_meta
0000.660 () Processing table (MyISAM): prefix_bt_snapshots
0000.668 () Processing table (MyISAM): prefix_bt_wrappers
0000.675 () Processing table (MyISAM): prefix_duplicator_packages
0000.679 () Database queries processed: 50 in 0.64 seconds
0000.685 () Processing table (MyISAM): prefix_hw_blocks
0000.698 () Processing table (MyISAM): prefix_hw_layout_meta
0000.707 () Processing table (MyISAM): prefix_hw_snapshots
0000.715 () Processing table (MyISAM): prefix_hw_wrappers
0000.722 () Unlocking database and leaving maintenance mode
0000.722 () Disabling Maintenance mode…
0000.722 () Finished: lines processed: 64 in 0.69 seconds
0000.723 () Cleaning up rubbish…
0000.734 () Entity: themes
0000.734 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-themes.zip, type=themes, info=a:2:{s:4:”path”;s:42:”/kunden/auftrag/wpfolder/wp-content/themes”;s:11:”description”;s:6:”Themes”;}, last_one=)
0000.735 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-themes.zip, 6.8 Mb)
0001.345 () Moving old data: filesystem method / updraft_dir is potentially possible
0001.345 () Moving old data: can potentially use wp_filesystem method / -old
0001.345 () Moving old data out of the way…
0003.216 () Top-level entities being moved: headway, bloxtheme, twentyseventeen, index.php
0003.217 () Moving unpacked backup into place…
0004.978 () Top-level entities being moved: headway, bloxtheme, twentyseventeen, index.php
0004.981 () Cleaning up rubbish…
0004.984 () Entity: others
0004.984 () restore_backup(backup_file=backup_2018-07-05-0722_Praxis_cf2aecf72e14-others.zip, type=others, info=a:2:{s:4:”path”;s:35:”/kunden/auftrag/wpfolder/wp-content”;s:11:”description”;s:6:”Others”;}, last_one=1)
0004.985 () Unpacking backup… (backup_2018-07-05-0722_Praxis_cf2aecf72e14-others.zip, 0 Mb)
0004.989 () Cleaning up rubbish…
0005.180 () Restore successful!
0005.180 () Restore successful

Hi,

Thank you. The log shows that the restoration was successful (sometimes logging in fails if the database restoration fails at a certain point).

Are you able to use the password reset feature for the site? i.e. the ‘lost your password’ form

Hi DNutbourne,
thanks for your answer.

The log shows that the restoration was successful (sometimes logging in fails if the database restoration fails at a certain point)

I understand. No, the whole process went smoothly, ending with a success message.
But just one or two seconds after the success message WP told me that my session has ended and invited me to login again. Strange for me because my session was very fresh. Since then I cannot login with the WP Password.

Do you had already similar cases, saying from your experience what might be the reason for being thrown out from WP just after restore? Searching in forum doesn’t give me hints.

Not sure if it may be important, but though my site has no SSL/https, I use to work on backend with https by browser exception. So when starting the restore UpdraftPlus gave me a warning (“backup has http, right now there is https”).

Though probably not serious I deleted the browser exception, logged in again (with http) and did the restore then without getting the warning.
But login now fails both with browser-https and with normal http. Deleted cookies tried it often, different browser…

“Lost your password” would probably work, I guess, or may be changing the PW via phpMyAdmin, but I’d like to know the reason of the issue, if possible, because of some future changes.

Hi,

Being asked to log in again after a restoration is normal, as WordPress keeps some session information in the database. Restoring the database loses the current session.

Please could you try the lost password link? Are you able to log in after resetting the password? (This will allow us to narrow down the exact issue)

Hi,
lost Password link worked. I can login now in WP again. Tried it also sucessfully with a different profile in FF and with a different browser (Chrome). The new PW works.

I did the “lost pw link” without SSL-browser-exception, i.e. I deleted it in my browser and used https://…login.php (not https, which my site does not have).
I deleted all cookies before.

Then I deleted the “old” files, like UpdraftPlus recommended in the backend and I made a manual backup with UpdraftPlus.

Hope this helps to find the exact issue or at least narrowing down the possibilities.

Really curious about your opinion now.

Hi,

I believe that the issue was caused by the https/http mismatch.

When attempting to log in, WordPress can enter a loop if the browser redirects to a URL that does not match the site URL. The user is returned to the login screen, because WordPress does not recognise the session.

Hi,
hm… after failing Login with unchanged WP-PW I tried it
– with deleted cookies/cache and https via SSL-exception in browser (Firefox)
– with deleted cookies/cache and also deleted SSL-exception, i.e. with http
– different browser which never had https by SSL-exception

After typing in the PW and “Enter” I always got the same result:
I stayed on the login page, the page was “shaking” two seconds to the left and right and a red vertical line telling me that something is wrong.

Does this sound like the “WP login redirect loop issue”?

Hi,

Apologies for the delay. This does appear to be a different issue to the redirection issue (in that case, the login page reloads).

When changing the database information, did you also change the database encryption salts/security keys in wp-config?

Apologies for the delay. This does appear to be a different issue to the redirection issue (in that case, the login page reloads).

When changing the database information, did you also change the database encryption salts/security keys in wp-config?

Yeah, doesn’t seem to be the “redirect loop”, because it was not just a login page reload. I always got a “red error” and didn’t leave the login page – just like typing the PW wrong.

When changing the database PW I did not change anything else in wp-config. The keys there are still the same since WP installation.

Even if not causing the login redirect issue, is it possible that the https/http-issue can cause the described kind of login failure, even after deleting cache/cookies?

Hi,

It could be possible that https/http issue could cause this issue. Unfortunately, there are a lot of variables that can affect this, which we cannot investigate without access to the site/server and backup, so it is hard to be sure.

I am having a similar problem. I used the Updraft Migrator plug-in to create a staging site.

I migrated the source site to the destination site successfully and it kicked me out when finished like I read it was supposed to do.

When I went to log in with the source credentials on the destination site it didn’t work. I requested a new password. That worked, but then when I went to log in with the same login credentials on the source site it didn’t work (using both new and old password). I had to request a new password again to login to my source site.

I went back to the destination site to see if either logins would work and they did not.

It’s obviously not efficient to keep requesting a new password everytime I want to login to either site.

I was migrating from a https site to a http site. If that’s what is causing this how do I fix it?

Thanks!

I was migrating from a https site to a http site. If that’s what is causing this how do I fix it?

Did you change the WordPress and Site URL in your General settings to https
and did you login then with https?

Hi Martin,
Thank you for responding!

I did not make any changes to the WordPress and Site URL in the General settings of either website (source or destination).

https source url: https://besweetlight.com/
http destination url (staged test site): https://www.allinonetest.besweetlight.com/

I’m not going to add a security certificate to a staged site. Do you think that’s what it’s asking me to do to work properly?

MARTIN!
It worked! I didn’t know if you were suggesting me to try that or not, but I went into the destination site and made it https in the site url settings and that did it. Now I have separate log ins for each and they stick so I can be logged in to both at the same time without having to request new pws everytime. THANK YOU! Maybe they should hire you for support ??