Nie mogę się zalogować do mojej witryny wordpress. reauth = 1 pętla przekierowania. Wszelkie pomysły, jak to naprawić?

Mam problem z zalogowaniem się do mojej witryny WordPress. Podczas próby odwiedzenia witryny example.com/wp-admin widzę pustą stronę, a pasek adresu URL zmienia się na:

http://example.com/wp-login.php?redirect_to=http%3A%2F%2Fmysite.com%2Fwp-admin%2F&reauth=1

Jeśli odwiedzę example.com/wp-login.php, widzę tylko pustą białą stronę bez żadnych zmian w adresie URL.

Potwierdziłem, że to nie jest problem z niczym na moim komputerze lokalnym, ponieważ zachowanie występuje w wielu przeglądarkach i urządzeniach.

Znalazłem wiele postów na forum na ten temat, ale żadne nie oferuje zadowalającego rozwiązania.

Proszę o pomoc, ponieważ pilnie potrzebuję zaktualizować zawartość witryny.

Aktualizacja: Włączyłem debugowanie WordPress i widzę następujący błąd

Fatal error: Cannot redeclare check_password_reset_key() 
(previously declared in /home/wordpress/public_html/wp-login.php:281) 
in /home/wordpress/public_html/wp-includes/user.php on line 1637

Wszelkie wskazówki, jak to naprawić, byłyby bardzo mile widziane

Miałem ten sam problem ... usunięcie plików cookie nie rozwiązało problemu.

Co przyniosło lewę , najpierw zalogowałem się w trybie incognito , a potem udało mi się zalogować normalnie.

Istnieje wiele możliwych przyczyn tego problemu. Niektóre mają związek z twoją bazą danych. Spróbuj włączyć WP_DEBUG i zinterpretować komunikaty o błędach.

W moim przypadku (tak właśnie natknąłem się na twoje pytanie tutaj) problem polegał na zapisaniu tokena sesji w usermeta. Poszedłem do PhpMyAdmin> wp_usermeta> i usunąłem meta_value dla session_token. (Szczegółowa historia tutaj https://wordpress.org/support/topic/possible-fix-for-sudden-redirect-loop-at-wp-login-with-reauth1 )

Może to być spowodowane awarią tabeli Wordpress. Ustawienie zdefiniuj („WP_DEBUG”, prawda); w wp-config.php pokaże dokładnie, która tabela uległa awarii, jeśli tak jest.

Rozwiązałem ten problem, definiując klucze bezpieczeństwa w wp-config.php:

define('AUTH_KEY',         '');
define('SECURE_AUTH_KEY',  '');
define('LOGGED_IN_KEY',    '');
define('NONCE_KEY',        '');
define('AUTH_SALT',        '');
define('SECURE_AUTH_SALT', '');
define('LOGGED_IN_SALT',   '');
define('NONCE_SALT',       '');

Z jakiegoś powodu były puste ... Zamień puste ciągi na niektóre wygenerowane tutaj: https://api.wordpress.org/secret-key/1.1/salt/ (dzięki Josh Rodgers)

Za każdym razem masz do przodu od http://mysitecelu http://mysite/, to musiało się stać. W moim przypadku mam uruchomiony proces zarządzania httpd, który ma kilka wirtualnych hostów. Jeden został skonfigurowany w następujący sposób:

<VirtualHost *:*>
    ServerName mysite.com
    ProxyPass "/blog" "http://bloghtml/blog/"
    ProxyPreserveHost On
</VirtualHost>

Zmiana "/blog"na "/blog/"naprawia problem.

Miałem również ten problem, ale miałem inną wiadomość. Po przejrzeniu niezliczonej liczby poprawek: htaccess, wtyczki o zmienionej nazwie, motyw o zmienionej nazwie, sprawdzone pod kątem pustego miejsca w wp-config.php nadal się zacinałem.

Logując się do PHPMyAdmin Próbowałem zoptymalizować tabele, ale dostałem błąd odmowy użytkownika. Okazało się, że sama baza danych jest zbyt duża, a następnie „blokowana” przez dzielony hosting. Po znalezieniu głównego winowajcy (tabeli dziennika Wordfence) obciąłem to, odczekałem 30 minut i hej presto, wszystko znów działało.

Pomyślałem, że może to pomóc komuś całkowicie utknąć po wypróbowaniu każdej innej sugerowanej opcji!

Właśnie przeszedłem przez to samo. Brak powodzenia w czyszczeniu pamięci podręcznej, .htaccess, czyszczeniu sesji DB, wyłączaniu wtyczek ftp itp. Mogłem zalogować się w incognito w Chrome. Potem nadal nie byłem w stanie zalogować się normalnie. Sam bufor przeglądarki nie działał, musiałem specjalnie usunąć wszystkie pliki cookie związane z domeną.

Ustawienia> Pokaż ustawienia zaawansowane> Ustawienia treści>

W obszarze Ustawienia prywatności kliknij przycisk „Ustawienia treści”

W obszarze Pliki cookie kliknij przycisk „Wszystkie pliki cookie i dane witryny”

Następnie wyszukaj witrynę za pomocą słowa kluczowego w polu wyszukiwania: Podświetl swoją stronę i kliknij Usuń na klawiaturze.

Kliknij przycisk Gotowe i spróbuj ponownie zalogować się na swojej stronie (w trybie normalnym .. tzn. Po prostu wyjdź z trybu incognito, zamykając okno)

Jeśli witryna była już otwarta w innej karcie, pojawi się błąd pliku cookie. zamknij wszystkie karty, otwórz ponownie, zaloguj się i ciesz się

Żadne z powyższych nie działało dla mnie.

Po włączeniu trybu debugowania:

define('WP_DEBUG', true);

w wp-config.php

Witryna informowała mnie o problemach z uprawnieniami użytkownika bazy danych ...

Dla mnie zadziałało przywrócenie użytkownika root do bazy danych (zamiast użytkownika „internetowego” z mniejszymi uprawnieniami).

Oczywiście nie jest to rozwiązanie długoterminowe, ale daje ci coś innego do wypróbowania, co może Ci pomóc.

Chciałbym przyczynić się do społeczności, a także ponieważ ten problem był bardzo denerwujący. Żadne z rozwiązań nie działało dla mnie. Nie zainstalowałem żadnych wtyczek, zanim to się stało, więc zdecydowanie myślę, że to błąd Wordpress!

Moje dokładne błędy: za pośrednictwem debugera WP. Po zalogowaniu pojawił się biały ekran z tym błędem.

 Fatal error: Class 'PasswordHash' not found in /var/www/public_html/example.net/wp-includes/pluggable.php on line 2079

Poprzez dziennik błędów Apache.

PHP Fatal error:  Class 'PasswordHash' not found in /var/www/public_html/example.net/wp-includes/pluggable.php on line 2138, referer: http://example.net/wp-login.php?redirect_to=http%3A%2F%2Fexample.net%2Fwp-admin%2F&reauth=1

Jak rozwiązałem problem. 1. W DB zmodyfikowałem hasło administratora do hasła w postaci zwykłego tekstu. 2. Dodano te wiersze kodu do pluggable.php. Zasadniczo teraz WP rozpoznaje hasła nieszyfrowane. Oto edytowane fragmenty pliku pluggable.php

function wp_check_password($password, $hash, $user_id = '') {
<------>global $wp_hasher;

<------>//20170713 Added by Stefan
<------>$check=($hash==$password);
<------>return apply_filters('check_password', $check, $password, $hash, $user_id);

... i trochę niżej

function wp_set_password( $password, $user_id ) {
<------>global $wpdb;

<------>//$hash = wp_hash_password( $password );
<------>//20170713 Changed by Stefan
<------>$hash=$password;

Mam nadzieję, że to komuś pomaga, bo googling mi nie pomógł.

Miałem ten sam problem, ale nie mogłem się oderwać po spędzeniu zbyt dużo czasu, otrzymałem tę odpowiedź stąd http://www.wpbeginner.com/wp-tutorials/how-to-fix-wordpress-login-page-refreshing-and -redirecting-issue / więc to tylko problem z ciasteczkami, musimy wyczyścić ciasteczka z przeglądarki i włączyć je ponownie i to wszystko.

Naprawiam to za pomocą https: // dostępu do mojej witryny zamiast http: // w ten sposób nie otrzymałem żadnego przekierowania. https://my_website.com/admin Możesz również zmienić wartości „siteurl” i „home” w tabeli opcji za pomocą phpmyadmin w panelu, aby wskazywać na https. Jestem spostrzegawczy, że może to być problem z nieprawidłowym przekierowaniem ssl.

Problem ten wystąpił po migracji mojej witryny z jednego serwera na inny. Po zaimportowaniu bazy danych na nowy serwer nie mogłem się zalogować. Na nowym serwerze nie miałem jeszcze strony bezpiecznej za pomocą protokołu SSL, więc musiałem zmienić stronę i adres w bazie danych.

Naprawić

• Naprawiłem to, przechodząc do bazy danych i zmieniając siteurl i home z wewnątrz https://do http://wewnątrz wp_options.

To może pomóc innym.

Spróbuj usunąć kwerendę w adresie URL („?” I wszystko za nim) - to znaczy: bezpośrednio odwiedź wp-login.php. To zadziałało dla mnie. Próbowałem zmienić hasło, zmienić sole, wyczyścić meta_value dla session_tokens w wp_usermeta. Nic z tego nie działało.

Przykro mi, wiem, że to ci nie pomaga, ponieważ mówisz, że ekran wp-login.php jest biały, ale może pomóc komuś, kto taki jak ja, został przyciągnięty tutaj przez nagłówek.

tak się stało, kiedy zaktualizowałem moją witrynę do wersji php 7.4. obniżenie wersji do php 7.3 rozwiązało to. Niestety nie wiem, jak zachować wersję i rozwiązać problem. Mamy nadzieję, że wkrótce programiści WP naprawią ten problem.

Zdarzyło mi po zmianie adresu URL witryny, ale zapomniałem zmienić site_urlw wp_sitemeta. Następnie zmieniłem wartość na nowy adres URL i problem został rozwiązany.

Rozwiązałem problem, zastępując plik wp-login.php inną witryną, na której działa logowanie.

mój błąd był spowodowany poniższą dyrektywą w pliku konfesjonału nginx

location ~ \.php$ {

               #fastcgi_hide_header "Set-Cookie"; # Cache page with cookie