Logowanie do WordPressa wraca do formularza. Jak przerwać pętlę logowania?

Login i hasło są poprawne, formularz ich nie odrzuca, a mimo to po kliknięciu „Zaloguj się” na ekranie znów pojawia się ten sam formularz. Bez komunikatu o błędzie, bez wyjaśnienia. To pętla logowania, jedna z bardziej irytujących usterek WordPressa, bo strona dla odwiedzających działa zwykle bez zarzutu, a właściciel nie może wejść do kokpitu i niczego zmienić.

Ten tekst jest dla osób, które prowadzą firmową stronę albo sklep na WordPressie i same nią zarządzają. Nie trzeba być programistą. Wystarczy dostęp do panelu hostingu albo do plików strony przez FTP oraz trochę cierpliwości.

Po lekturze będzie wiadomo, skąd bierze się pętla, jak w kilkanaście minut ustalić, która z przyczyn zachodzi w danym przypadku, jak naprawić każdą z nich i po czym poznać, że naprawa jest trwała. Kolejność sekcji odpowiada kolejności, w jakiej sam sprawdzam taką usterkę: od czynności najprostszych i całkowicie bezpiecznych do tych, które wymagają pracy na plikach i bazie danych.

Po czym rozpoznać pętlę logowania i nie pomylić jej z błędnym hasłem?

Pętla logowania wygląda zawsze podobnie. Po wysłaniu formularza strona na chwilę się przeładowuje i wraca pod adres wp-login.php. Pola są puste, nad formularzem nie ma czerwonej ramki z informacją o złym haśle, a w pasku adresu często widać dopisek zaczynający się od redirect_to= oraz reauth=1.

To ważna różnica. Przy błędnym haśle albo nieistniejącym użytkowniku WordPress wyświetla nad formularzem wyraźny komunikat o błędzie. Jeśli taki komunikat się pojawia, problem dotyczy danych logowania i rozwiązuje go odnośnik „Nie pamiętasz hasła?” pod formularzem, a nie czynności opisane poniżej.

Zdarzają się też odmiany pętli. Przeglądarka może pokazać własny ekran z informacją o zbyt wielu przekierowaniach. Może się też pojawić komunikat WordPressa o tym, że pliki cookie są zablokowane albo nieobsługiwane. Oba przypadki mają te same źródła co klasyczna pętla i naprawia się je tak samo.

Jeśli zamiast formularza widać pustą, białą stronę, to inna usterka. Opisałem ją osobno w tekście o tym, jak przywrócić stronę, gdy nic się nie wyświetla. Komunikat o braku uprawnień z kodem 403 to z kolei blokada po stronie serwera lub wtyczki bezpieczeństwa, a nie pętla.

Dlaczego WordPress odsyła z powrotem do formularza?

Żeby zrozumieć pętlę, wystarczy wiedzieć jedno. WordPress nie pamięta zalogowanej osoby sam z siebie. Po poprawnym podaniu hasła wysyła do przeglądarki pliki cookie, czyli małe pliki z potwierdzeniem logowania. Dokumentacja WordPressa wymienia dwa takie pliki: jeden o nazwie zaczynającej się od wordpress_, ważny tylko w obszarze /wp-admin/, i drugi o nazwie zaczynającej się od wordpress_logged_in_, który informuje resztę serwisu, kto jest zalogowany.

Przy każdym wejściu do kokpitu WordPress pyta przeglądarkę o te pliki. Jeśli ich nie dostanie, uznaje, że nikt się nie zalogował, i odsyła do formularza. Pętla powstaje więc zawsze wtedy, gdy plik cookie nie został zapisany, nie został odesłany albo został odesłany pod inny adres niż ten, dla którego go wystawiono.

Wszystkie przyczyny opisane dalej sprowadzają się do tego jednego mechanizmu. Albo przeglądarka nie przyjmuje lub nie oddaje pliku, albo WordPress ma zapisany inny adres strony niż ten, pod którym naprawdę działa, albo coś po drodze (wtyczka, motyw, plik serwera, pamięć podręczna) psuje wymianę plików cookie lub dokłada własne przekierowanie.

Jak w kwadrans ustalić, gdzie leży przyczyna?

Zanim zacznie się zmieniać cokolwiek na serwerze, trzeba wykonać kilka prób, które niczego nie psują. Pozwalają one od razu oddzielić problem przeglądarki od problemu strony.

1. Otwarcie formularza logowania w oknie prywatnym przeglądarki (tryb incognito) i próba zalogowania. Okno prywatne nie używa starych plików cookie ani większości rozszerzeń.
2. Próba zalogowania w zupełnie innej przeglądarce, a najlepiej także na innym urządzeniu, na przykład na telefonie korzystającym z sieci komórkowej zamiast firmowego Wi-Fi.
3. Porównanie adresu w pasku przeglądarki przed wysłaniem formularza i po nim. Należy zwrócić uwagę na dwie rzeczy: czy adres zaczyna się od https:// czy http:// oraz czy zawiera www.
4. Przypomnienie sobie, co zmieniło się na stronie tuż przed awarią: aktualizacja wtyczki lub motywu, instalacja certyfikatu SSL, przeniesienie strony na inny hosting, włączenie sieci CDN, nowa wtyczka bezpieczeństwa albo pamięci podręcznej.

Wynik tych prób mówi bardzo dużo. Jeśli w oknie prywatnym albo w innej przeglądarce logowanie działa, strona jest sprawna, a zawiniła przeglądarka: stare pliki cookie, pamięć podręczna albo rozszerzenie. Wystarczy wtedy następna sekcja.

Jeśli logowanie nie działa nigdzie, przyczyna leży po stronie serwisu. Gdy adres zmienia się po wysłaniu formularza (na przykład znika z niego www albo https zamienia się na http), niemal na pewno chodzi o niezgodność adresów zapisanych w WordPressie. Gdy adres pozostaje taki sam, najczęściej winna jest wtyczka, motyw, plik .htaccess albo pamięć podręczna serwera.

Przed jakąkolwiek pracą na plikach i bazie danych radzę zrobić kopię jednego i drugiego. W panelu większości firm hostingowych da się to zrobić kilkoma kliknięciami, a kto nie ma jeszcze ustalonego sposobu, znajdzie go w tekście o tym, jak zrobić i sprawdzić kopię zapasową WordPressa. Pojedyncze pliki, które będą zmieniane, dobrze jest dodatkowo pobrać na komputer w niezmienionej postaci.

Jak wyczyścić pliki cookie i pamięć podręczną przeglądarki?

Oficjalna pomoc WordPressa przy kłopotach z logowaniem zaleca na początek dwie czynności: usunięcie plików cookie i wyczyszczenie pamięci podręcznej przeglądarki. To najczęstsze i najłatwiejsze rozwiązanie, szczególnie po zmianie adresu strony, przejściu na https albo zmianie hostingu, kiedy w przeglądarce zostają pliki wystawione jeszcze dla starej konfiguracji.

W przeglądarce Chrome na komputerze, zgodnie z pomocą Google, wygląda to tak:

1. Po otwarciu Chrome należy kliknąć w prawym górnym rogu „Więcej”, a następnie „Usuń dane przeglądania”.
2. W oknie, które się otworzy, wybiera się zakres czasowy. Przy pętli logowania najlepiej wskazać „Od początku”.
3. Należy zaznaczyć „Pliki cookie i inne dane witryn” oraz pozycję dotyczącą obrazów i plików zapisanych w pamięci podręcznej.
4. Czynność potwierdza się przyciskiem „Usuń dane”.
5. Po zamknięciu i ponownym otwarciu przeglądarki trzeba wejść na formularz logowania, wpisując adres ręcznie, a nie z zakładki ani z historii.

Usunięcie wszystkich plików cookie wylogowuje z innych serwisów. Kto chce tego uniknąć, może usunąć dane tylko jednej witryny: w ustawieniach prywatności przeglądarki jest lista witryn przechowujących dane, na której wyszukuje się własną domenę i usuwa wyłącznie jej wpisy. W innych przeglądarkach nazwy opcji są trochę inne, ale zasada pozostaje ta sama.

Co jeszcze po stronie przeglądarki potrafi zablokować logowanie?

Jeżeli czyszczenie nie pomogło, a w innej przeglądarce logowanie działa, warto sprawdzić trzy ustawienia. Pierwsze to blokowanie plików cookie: w ustawieniach prywatności nie może być włączona blokada wszystkich plików cookie, a własna domena nie może znajdować się na liście witryn, którym zabroniono ich zapisywania.

Drugie to rozszerzenia. Dodatki blokujące reklamy, skrypty i śledzenie potrafią usuwać pliki cookie zaraz po ich zapisaniu. Wystarczy wyłączyć je na czas próby albo dodać własną domenę do wyjątków. Trzecie to programy ochronne na komputerze. Dokumentacja WordPressa wprost wspomina, że niektóre zapory sieciowe uniemożliwiają logowanie, i zaleca próbę po ich chwilowym wyłączeniu.

Zdarza się też drobiazg, o którym łatwo zapomnieć: zakładka zapisana wiele miesięcy temu prowadzi pod stary adres, na przykład bez https. Logowanie przez taką zakładkę odbywa się pod innym adresem niż ten, dla którego WordPress wystawia plik cookie. Dlatego w próbach adres należy wpisywać ręcznie, dokładnie w tej postaci, w jakiej strona otwiera się odwiedzającym.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: ustalę, co zatrzymuje logowanie, poprawię adresy, pliki lub ustawienia serwera i oddam działający dostęp do kokpitu.

Jak sprawdzić i poprawić adresy strony zapisane w WordPressie?

WordPress przechowuje dwa adresy. W kokpicie, w menu „Ustawienia” i dalej „Ogólne”, noszą one nazwy „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. W bazie danych odpowiadają im wpisy siteurl i home. Pierwszy wskazuje, gdzie leżą pliki WordPressa, drugi określa adres, pod którym stronę widzą odwiedzający.

Pętla pojawia się wtedy, gdy te adresy różnią się od siebie albo od rzeczywistego adresu strony w szczegółach, które na pierwszy rzut oka nie mają znaczenia: jeden ma www, a drugi nie, jeden zaczyna się od http://, a drugi od https://, w jednym została stara domena po przenosinach. Dla przeglądarki są to różne adresy, więc plik cookie wystawiony dla jednego nie zostaje odesłany pod drugi.

Skoro kokpit jest niedostępny, adresów nie da się poprawić w ustawieniach. Dokumentacja WordPressa podaje kilka sposobów ręcznej zmiany. Opisuję dwa, które uważam za najbezpieczniejsze, a o dwóch pozostałych piszę niżej z zastrzeżeniami. Uwaga: dokumentacja zaznacza, że sposoby te dotyczą pojedynczej instalacji. W sieci witryn (WordPress Multisite) adresy poprawia się wyłącznie w bazie danych i lepiej powierzyć to osobie z doświadczeniem.

Wpisanie adresów w pliku wp-config.php

To najszybsza metoda i łatwo ją cofnąć. Plik wp-config.php leży w głównym katalogu WordPressa, zwykle w folderze public_html albo w folderze o nazwie domeny.

1. Otwarcie menedżera plików w panelu hostingu albo połączenie z serwerem przez program FTP i przejście do głównego katalogu strony.
2. Pobranie pliku wp-config.php na komputer jako kopii, a następnie otwarcie go do edycji. Należy użyć prostego edytora tekstu albo edytora wbudowanego w menedżer plików, nigdy programu biurowego.
3. Odnalezienie wiersza z komentarzem informującym, że to koniec edycji (w oryginale zaczyna się on od słów That's all, stop editing!).
4. Wstawienie nad tym komentarzem dwóch wierszy z rzeczywistym adresem strony, z https:// na początku i bez ukośnika na końcu.
5. Zapisanie pliku, usunięcie plików cookie w przeglądarce i ponowna próba logowania.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

W miejscu example.com wpisuje się własną domenę, dokładnie w tej postaci, w jakiej ma działać strona, czyli z www albo bez. Oba wiersze powinny zawierać ten sam adres, chyba że WordPress został celowo zainstalowany w podkatalogu.

Trzeba znać dwie konsekwencje tej metody. Po pierwsze, dokumentacja uprzedza, że adresy wpisane w pliku są ustawione na sztywno i nie da się ich już zmieniać na ekranie ustawień ogólnych. Po drugie, wartości w bazie danych pozostają stare. Plik je tylko przesłania, więc po usunięciu obu wierszy problem wróci. Dlatego po odzyskaniu dostępu radzę poprawić także bazę, a wiersze zostawić albo usunąć według własnego uznania.

Poprawienie adresów w bazie danych przez phpMyAdmin

Ta metoda usuwa przyczynę u źródła. Wymaga dostępu do narzędzia phpMyAdmin, które jest w panelu prawie każdego hostingu, oraz kopii bazy zrobionej tuż przed zmianą.

1. Wykonanie kopii bazy danych i zapisanie jej poza serwerem.
2. Zalogowanie się do phpMyAdmin i wskazanie bazy danych używanej przez WordPressa. Jej nazwę można odczytać z pliku wp-config.php, z wiersza zawierającego DB_NAME.
3. Otwarcie tabeli wp_options. Początek nazwy może być inny, jeśli przy instalacji zmieniono przedrostek tabel.
4. Odnalezienie wierszy, w których kolumna option_name ma wartość siteurl oraz home. Zwykle są to dwa pierwsze wiersze tabeli.
5. Poprawienie w obu wierszach kolumny option_value na właściwy adres i zapisanie zmian.

Zmienia się wyłącznie te dwa wiersze. Tabela zawiera setki innych ustawień i przypadkowa zmiana któregoś z nich może wyłączyć stronę, dlatego niczego poza tymi dwoma polami nie należy dotykać.

Dwie metody z dokumentacji, których używam ostrożnie

Dokumentacja opisuje jeszcze stałą RELOCATE wpisywaną do pliku wp-config.php, która przy wejściu na formularz logowania sama poprawia adres WordPressa. Ta sama dokumentacja ostrzega jednak, że pozostawienie jej w pliku jest niebezpieczne, bo w pewnych konfiguracjach pozwala osobie z zewnątrz zmienić adres strony. Poprawia ona zresztą tylko jeden z dwóch adresów.

Druga metoda polega na dopisaniu do pliku functions.php motywu dwóch poleceń update_option. Działa, ale dokumentacja wyraźnie zaznacza, że kodu tego nie wolno zostawić w pliku. Obie metody są zgodne z zasadami WordPressa, tylko łatwo o nich zapomnieć po naprawie. Uważam, że plik wp-config.php z dwoma wierszami adresów i poprawka w bazie dają ten sam skutek przy mniejszym ryzyku.

Co zrobić, gdy pętla pojawiła się po włączeniu https albo sieci CDN?

Jeżeli logowanie przestało działać zaraz po instalacji certyfikatu SSL, włączeniu sieci CDN albo usługi pośredniczącej, która stoi między odwiedzającym a serwerem, przyczyna jest zwykle jedna. Odwiedzający łączy się z pośrednikiem przez https, ale pośrednik przekazuje ruch do serwera zwykłym http. WordPress widzi wtedy połączenie nieszyfrowane, próbuje przekierować na https, pośrednik znów przekazuje je przez http i koło się zamyka.

Dokumentacja WordPressa opisuje dokładnie ten przypadek: gdy szyfrowanie zapewnia serwer pośredniczący, a sam WordPress działa bez niego, wymuszenie https w kokpicie wprowadza każde żądanie w nieskończoną pętlę przekierowań. Rozwiązania są dwa i najlepiej zastosować oba.

Pierwsze leży po stronie usługi pośredniczącej. W jej panelu trzeba ustawić taki tryb szyfrowania, w którym połączenie między pośrednikiem a serwerem także odbywa się przez https. Wymaga to ważnego certyfikatu na samym serwerze. Jak go zainstalować i przestawić całą stronę, opisałem w tekście o tym, jak przejść na https bez strat.

Drugie to fragment z dokumentacji, który wstawia się do pliku wp-config.php nad komentarzem o końcu edycji. Informuje on WordPressa, że połączenie było szyfrowane, jeśli pośrednik przekazał taką informację w nagłówku:

define( 'FORCE_SSL_ADMIN', true );
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false )
    $_SERVER['HTTPS'] = 'on';

Fragment działa tylko wtedy, gdy pośrednik rzeczywiście wysyła nagłówek X-Forwarded-Proto. Większość popularnych usług to robi, ale w razie wątpliwości najpewniej jest zapytać o to pomoc techniczną hostingu lub dostawcy sieci CDN. Jeśli w pliku jest już wiersz ze stałą FORCE_SSL_ADMIN, nie należy wstawiać go drugi raz.

Jak sprawdzić, czy logowanie blokuje wtyczka albo motyw?

Wtyczki są drugą po adresach najczęstszą przyczyną pętli, która nie znika po zmianie przeglądarki. Podejrzane są przede wszystkim wtyczki bezpieczeństwa, wtyczki zmieniające adres formularza logowania, wtyczki pamięci podręcznej, wtyczki do przekierowań oraz dodatki obsługujące logowanie dwuetapowe. Pętla po aktualizacji którejś z nich to dość typowy scenariusz.

Skoro do ekranu „Wtyczki” nie da się wejść, wyłącza się je z poziomu plików. Dokumentacja WordPressa podaje na to prosty sposób: zmianę nazwy folderu z wtyczkami.

1. W menedżerze plików albo programie FTP należy przejść do folderu wp-content.
2. Nazwę folderu plugins zmienia się na plugins_old. WordPress nie znajdzie wtedy żadnej wtyczki i wszystkie wyłączy.
3. Po usunięciu plików cookie trzeba spróbować się zalogować.
4. Jeśli logowanie działa, folderowi przywraca się nazwę plugins. Wtyczki pojawią się z powrotem na liście, ale pozostaną wyłączone.
5. W kokpicie, na ekranie „Wtyczki”, włącza się je pojedynczo przyciskiem „Włącz”, po każdej wylogowując się i logując ponownie w oknie prywatnym. Wtyczka, po której pętla wraca, jest winowajcą.

Folderu nie wolno usuwać, wystarczy zmiana nazwy. Ustawienia wtyczek są zapisane w bazie danych i po ponownym włączeniu wracają. Jedno zastrzeżenie: w sklepie internetowym wyłączenie wszystkich wtyczek zatrzymuje na ten czas sprzedaż i płatności, dlatego próbę najlepiej przeprowadzić w porze najmniejszego ruchu i trwać w tym stanie jak najkrócej.

Gdy wiadomo już, która wtyczka szkodzi, zostają trzy drogi: aktualizacja do nowszej wersji, zmiana jej ustawień (przy wtyczkach pamięci podręcznej chodzi zwykle o wyłączenie formularza logowania i kokpitu z zapisywania) albo zastąpienie jej inną. Jeśli winna jest wtyczka zmieniająca adres logowania, do czasu naprawy formularz jest dostępny pod standardowym adresem wp-login.php.

A jeśli to motyw?

Motyw sprawdza się tak samo. W folderze wp-content/themes zmienia się nazwę folderu aktywnego motywu, na przykład przez dopisanie _old. WordPress przełączy się wtedy na jeden z motywów domyślnych, o ile jest zainstalowany. Jeżeli w folderze nie ma żadnego motywu domyślnego, trzeba go najpierw wgrać, bo inaczej strona przestanie się wyświetlać.

Jeśli po tej zmianie logowanie działa, przyczyna tkwi w motywie, najczęściej w pliku functions.php. Do czasu naprawy strona będzie wyglądała inaczej, więc i tę próbę warto wykonać szybko, a nazwę folderu przywrócić zaraz po ustaleniu wyniku.

Jak wykluczyć uszkodzony plik .htaccess i pamięć podręczną serwera?

Plik .htaccess w głównym katalogu strony steruje przekierowaniami na serwerach Apache i LiteSpeed. Reguły dopisane przez wtyczki, ręczne przekierowania na https lub na adres z www, a także pozostałości po usuniętych wtyczkach potrafią się wzajemnie wykluczać i odsyłać formularz logowania w kółko.

Sprawdzenie polega na chwilowym odłożeniu pliku na bok. Dokumentacja WordPressa zaleca zmianę jego nazwy na .htaccess_old. Plik zaczyna się od kropki, więc w menedżerze plików trzeba czasem włączyć pokazywanie plików ukrytych. Po zmianie nazwy i usunięciu plików cookie należy spróbować się zalogować.

Jeśli logowanie działa, w kokpicie trzeba od razu otworzyć „Ustawienia”, następnie „Bezpośrednie odnośniki” i bez żadnych zmian kliknąć „Zapisz zmiany”. WordPress utworzy wtedy nowy, czysty plik .htaccess. Bez tego kroku podstrony i wpisy będą zwracały błąd 404. Własne przekierowania ze starego pliku przenosi się potem pojedynczo, sprawdzając logowanie po każdym z nich. Jak pisać takie reguły, żeby się nie zapętlały, pokazałem w tekście o przekierowaniu 301 w pliku .htaccess.

Pamięć podręczna po stronie serwera i sieci CDN

Formularz logowania i kokpit nigdy nie powinny być zapisywane w pamięci podręcznej. Jeśli serwer, sieć CDN albo wtyczka zapisze odpowiedź z formularza i poda ją kolejnej osobie, przeglądarka dostaje starą stronę bez świeżego pliku cookie i logowanie się nie udaje.

W panelu hostingu i w panelu sieci CDN należy wyczyścić całą pamięć podręczną, a następnie sprawdzić w ustawieniach, czy adresy zawierające wp-login.php i /wp-admin/ są wyłączone z zapisywania. Na czas szukania przyczyny pamięć podręczną serwera można po prostu wyłączyć, jeśli panel na to pozwala. Strona będzie działała wolniej, ale wynik próby będzie jednoznaczny.

Jak odczytać z dziennika błędów, co psuje plik cookie?

Jest jeszcze jedna przyczyna, której nie widać gołym okiem. Plik cookie jest przesyłany w nagłówkach odpowiedzi, czyli zanim do przeglądarki trafi jakakolwiek treść strony. Jeśli któryś plik PHP wyśle choćby jeden znak za wcześnie, nagłówków nie da się już wysłać i plik cookie przepada. W dzienniku błędów pojawia się wtedy wpis zawierający słowa headers already sent.

Najczęściej winna jest pusta linia albo spacja przed otwierającym <?php lub po zamykającym ?> w pliku wp-config.php albo functions.php, zwykle po ręcznej edycji. Żeby to potwierdzić, włącza się zapisywanie błędów do pliku. Dokumentacja podaje na to trzy wiersze, które wstawia się do wp-config.php nad komentarzem o końcu edycji:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Jeśli w pliku jest już wiersz ze stałą WP_DEBUG ustawioną na false, należy go zastąpić, a nie dublować. Po zapisaniu trzeba raz spróbować się zalogować, a potem otworzyć plik debug.log w folderze wp-content. Wpis o nagłówkach podaje nazwę pliku i numer wiersza, w którym zaczęło się przedwczesne wysyłanie treści. To tam trzeba usunąć zbędną spację lub pustą linię, a jeśli wskazany plik należy do wtyczki, wyłączyć ją sposobem opisanym wyżej.

Po zakończeniu pracy trzy wiersze należy usunąć albo przywrócić wartość false, a plik debug.log usunąć z serwera. Dziennik zawiera szczegóły techniczne strony i nie powinien leżeć w publicznie dostępnym folderze dłużej, niż to potrzebne.

Rzadsze przyczyny, o których dobrze wiedzieć

W pliku wp-config.php może znajdować się stała COOKIE_DOMAIN ze starą albo błędnie wpisaną domeną. Dokumentacja przewiduje ją dla nietypowych konfiguracji domen i radzi nie ustawiać stałych dotyczących plików cookie, dopóki nie wypróbowano innych metod. Jeśli taki wiersz został po przenosinach strony, trzeba poprawić w nim domenę albo go usunąć.

Po czym poznać, że naprawa zadziałała, i co zrobić, gdy nie?

Samo wejście do kokpitu to jeszcze nie koniec. Pętla potrafi wrócić po wylogowaniu, po wyczyszczeniu pamięci podręcznej albo na innym urządzeniu, dlatego naprawę trzeba sprawdzić w kilku krokach.

1. Wylogowanie się i ponowne zalogowanie w oknie prywatnym, a potem w drugiej przeglądarce lub na telefonie.
2. Przejście po kilku ekranach kokpitu, na przykład „Wpisy”, „Media” i „Wtyczki”. Żaden z nich nie może odsyłać do formularza.
3. Otwarcie „Ustawienia”, następnie „Ogólne” i porównanie pól „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Oba mają zaczynać się od https:// i zgadzać się co do www.
4. Otwarcie strony głównej i dowolnego wpisu jako zwykły odwiedzający, żeby upewnić się, że naprawa nie zepsuła niczego na zewnątrz.
5. Usunięcie wszystkiego, co było tymczasowe: wierszy włączających dziennik błędów, pliku debug.log, stałej RELOCATE i poleceń update_option, jeżeli zostały użyte, oraz niepotrzebnych już folderów i plików z dopiskiem _old.

Co zrobić, gdy żadna z metod nie pomogła?

Jeżeli pętla nadal trwa, a wszystkie opisane próby zostały wykonane, przyczyna leży najpewniej w konfiguracji serwera, do której właściciel strony nie ma dostępu: w zaporze hostingu, w ustawieniach PHP albo w regułach serwera pośredniczącego. Wtedy najskuteczniejsze jest zgłoszenie do pomocy technicznej hostingu, napisane konkretnie.

Zgłoszenie może brzmieć tak: „Po poprawnym zalogowaniu do WordPressa pod adresem [adres strony]/wp-login.php strona wraca do formularza logowania bez komunikatu o błędzie. Problem występuje w różnych przeglądarkach i na różnych urządzeniach. Sprawdzone zostały: pliki cookie przeglądarki, adresy siteurl i home, wtyczki, motyw oraz plik .htaccess. Proszę o sprawdzenie dziennika błędów serwera, zapory, pamięci podręcznej serwera oraz limitów konta dla tej domeny.”

Ostatnią drogą jest przywrócenie kopii zapasowej sprzed awarii. To skuteczne, gdy pętla pojawiła się po konkretnej zmianie, ale oznacza utratę wszystkiego, co powstało później: zamówień, wpisów, zgłoszeń z formularzy. W sklepie internetowym radzę sięgać po kopię dopiero wtedy, gdy inne drogi zawiodły, i zawsze po zrobieniu kopii stanu bieżącego.

Jakich błędów unikać przy naprawie pętli logowania?

Większość szkód przy tej usterce powstaje nie przez samą pętlę, lecz przez pospieszną naprawę. Oto błędy, które widuję najczęściej:

• Wielokrotne próby logowania raz za razem. Wtyczki bezpieczeństwa i zapory hostingu potrafią po serii prób zablokować adres IP i do pętli dochodzi druga blokada.
• Resetowanie hasła. Pętla nie ma nic wspólnego z hasłem, a jego zmiana niczego nie naprawi.
• Edycja plików samego WordPressa, na przykład wp-login.php. Zmiany w plikach systemu znikają przy pierwszej aktualizacji i mogą otworzyć lukę w zabezpieczeniach.
• Usuwanie folderu wtyczek zamiast zmiany jego nazwy.
• Zmiany w bazie danych bez kopii zrobionej chwilę wcześniej.
• Kilka zmian wprowadzonych jednocześnie. Po każdej zmianie powinna nastąpić jedna próba logowania, inaczej nie będzie wiadomo, co pomogło.
• Pozostawienie w plikach tymczasowych poprawek i włączonego dziennika błędów.

Najczęstsze pytania

Czy pętla logowania oznacza, że na stronę ktoś się włamał?

Zwykle nie. Najczęściej chodzi o pliki cookie, adresy strony albo wtyczkę. Włamanie warto brać pod uwagę dopiero wtedy, gdy pętli towarzyszą inne objawy: nieznani użytkownicy, obce pliki na serwerze, przekierowania odwiedzających na cudze strony albo ostrzeżenia przeglądarki.

Czy zmiana hasła przerwie pętlę?

Nie. Przy pętli WordPress przyjmuje hasło jako poprawne, tylko nie potrafi utrzymać sesji. Nowe hasło zostanie przyjęte tak samo jak stare i formularz wróci dokładnie w ten sam sposób.

Czy przy tych naprawach można stracić treści strony?

Zmiana nazwy folderu wtyczek, motywu i pliku .htaccess oraz wiersze dopisane do wp-config.php niczego nie usuwają i dają się cofnąć. Ryzyko niesie praca w bazie danych oraz przywracanie kopii zapasowej, dlatego przed nimi zawsze robi się kopię stanu bieżącego.

Dlaczego logowanie działa na telefonie, a na komputerze nie?

To znak, że strona jest sprawna, a kłopot dotyczy przeglądarki na komputerze: starych plików cookie, pamięci podręcznej, rozszerzenia albo programu ochronnego. Wystarczy usunąć dane witryny w tej przeglądarce i wyłączyć rozszerzenia na czas próby.

Po dopisaniu adresów do wp-config.php pola w ustawieniach są nieaktywne. Czy to błąd?

Nie, tak działa ta metoda. Adresy wpisane w pliku mają pierwszeństwo przed bazą danych i nie da się ich zmieniać w kokpicie. Żeby pola znów były aktywne, trzeba poprawić adresy w bazie danych i usunąć oba wiersze z pliku.

Czy pętla może wrócić po naprawie?

Może, jeśli usunięto tylko objaw. Typowy przykład to wyczyszczenie plików cookie przy nadal niezgodnych adresach strony albo wyłączenie wtyczki pamięci podręcznej bez poprawienia jej ustawień. Dlatego po naprawie trzeba wykonać próby w oknie prywatnym i na drugim urządzeniu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Rozumiem to dobrze. Praca na plikach serwera i bazie danych bywa stresująca, zwłaszcza gdy strona zarabia, a każda godzina bez dostępu do kokpitu oznacza odłożone zamówienia i nieopublikowane treści. Mogę zająć się tym od początku do końca: zrobię kopię strony, ustalę, dlaczego logowanie wraca do formularza, usunę przyczynę, sprawdzę logowanie na kilku urządzeniach i uporządkuję pliki, tak żeby po naprawie nie został żaden tymczasowy ślad. Na koniec opiszę prostymi słowami, co się stało i co zrobić, żeby usterka nie wróciła.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co dzieje się po kliknięciu przycisku logowania. Odpowiem, czego potrzebuję, żeby zacząć.