Kein Login ins Backend in WordPress
Noch etwas schlaftrunken steuert man am Morgen wie gewohnt die WordPress-Login-Seite an, gibt den richtigen Benutzernamen und das dazugehörige Passwort ein, aber da tut sich nichts. Was gestern funktioniert hat, ist nun vergebene Klickmühe. WordPress leitet einen zurück auf die Anmelde-Seite. Das Backend, die Adminseite von WordPress (Dashboard) wird nicht geöffnet. Da kann man jetzt stundenlang klicken, in den seltensten Fällen wird dies von Erfolg gekrönt sein. 
Der Weg zurück ins Backend
(How to Fix WordPress Login Page Refreshing and Redirecting Issue)
So nah und manchmal unerreichbar
Unabhängig von der WordPress-Version, die installiert ist, kann es immer mal wieder zu Login Problemen kommen. Schön ist, wenn einem WordPress mitteilt, wo es klemmt, was in der Regel der Fall ist. Aber WordPress kann auch anders und eisern schweigen. Dies ist dann der Fall, wenn das Login-Redirect Problem auftritt. Man kommt nicht ins Backend.
Tipp 1: Ruhe bewahren (auch wenn die Login-Fehlversuche an den Nerven zehren)
Ich gebe zu, in einer anderen Zeit hatte ich im Gegensatz zu heute nicht die Ruhe bei einem derartigen Problem weg. Denn das Backend ist die Schaltzentrale eines WordPress-Blogs. Und, wenn die es trifft … Aber im Alter wird man auch ruhiger. Und in Anbetracht der weltweiten Meldungen über Hacks und anderes, habe ich meine eigene Wertigkeit im Netz heruntergeschraubt, denn es gibt schlimmeres. Den Seelentod zum Beispiel. Von daher: Auf geht es mit einer Tasse Kaffee zur Fehlersuche. 
Tipp 2: Was habe ich zuletzt gemacht?
An einem WordPress-Arbeitstag kann einiges anstehen. Updates von Plugins, Themes, Tests selbiger, vielleicht Links korrigiert, neue Grafiken den Artikeln zugewiesen und vieles anderes. Von Vorteil ist, wenn man sich Eingriffe notiert, das erspart viel Grübelei. Dazu zählen unter anderem was man an Dateien geändert hat. Ob es die .htaccess-Datei oder eine Zeile im Theme oder anderswo ist, man logt sich aus, alles ist gut und drei Tage später sieht die Sache anders aus. Mithilfe der Liste ist es dann möglich, das Problem einzugrenzen. Und nicht zu viel auf einmal ändern, ohne die Funktionalität zu testen.
Tipp 3: Fehlerquellen ausmerzen
Wenn Änderungen vorgenommen wurden:
Bei Überprüfung den kompletten Cache leeren! GANZ WICHTIG.
Die neumodischen Browser halten gerne alles fest. Egal ob rechter Mausklick “neu laden” oder in der Menüleiste der Knopf gedrückt wird, der Browser bedient sich weiterhin aus dem Cache. Und das ist dann für den WordPress’ler und sein Werk “tödlich”. Bearbeitet man hingegen mit einem Arbeitsprofil WordPress, kann man den Browser so einstellen, dass beim Beenden vom Cache bis Cookies alles gelöscht wird. Ich habe damit gute Erfahrungen gemacht.
Der ftp-Client – dein Freund und Helfer
Hat man keine manuellen Änderungen an der .htaccess vorgenommen, kann die htaccess-Datei über den ftp-Client gelöscht werden, sofern man eine Ersatzdatei mit dem WordPress-Eintrag hat. Ansonsten das hinzugefügte löschen. Sollte eine Einwahl nun möglich sein, dann WordPress im Backend unter Einstellungen > Permalinks und den Klick auf “Änderungen übernehmen” eine neue htaccess schreiben lassen.
Kein Erfolg? Dann sich die wp-config vornehmen. In der Regel kann man dort mit dem Eintrag define( 'WP_DEBUG', true ); WordPress veranlassen, ein wenig mehr zu erzählen (von false auf true setzen). Funktioniert in unserem Fall leider nicht.
Hier kann vielleicht ein zusätzlicher Eintrag das vermisste Backend aufrufen:define('WP_HOME','https://deine-url.de');define('WP_SITEURL','https://deine-url.de');
Und wenn ihr Dateien ändert, dann nur mit einem tauglichen Editor wie Notepad++. Fragt lieber vorher im Forum von WordPress nach, bevor ihr irgendwelche Schnipsel einsetzt und auf die Welt loslässt.
Manchmal sind es auch Plugins, die uns gerne übel mitspielen. In der Regel erzählt WordPress mit einer PHP-Fehlerzeile des Plugins,auch beim login, wo es klemmt. Aber der Teufel will’s… Mit einer Umbenennung des Plugins-Ordners kann man alle Plugins auf einen Schlag deaktivieren (Beispiel von wp-content/plugins nach wp-content/plugins_sleep).
Ist nun eine Einwahl möglich, man kommt ganz normal mit seinen Login-Einwahldaten ins Backend, dann ist der Übeltäter dort zu finden. Den Ordner wieder umbenennen und mit gezieltem deaktivieren-aktivieren dem Übeltäter beikommen. Ebenso ist mit dem Ordner Themes zu verfahren. Man sollte generell immer noch das aktuelle Standardtheme im Theme-Ordner bunkern.
Ebenfalls ist in Erwägung zu ziehen, dass man das aktuelle WordPress neu aufsetzt oder die Ordner wp-admin und wp-includes neu aufspielt. Nicht die Dateien über den ftp-Zugang ersetzen, sondern auf dem Server löschen und neu übertragen. So werden Übertragungsfehler durch “ersetzen” ausgeklammert. Wie da vorzugehen ist, das mögen andere erzählen. 
Hinter dem “Horizont” ist auch noch WordPress
Es gibt aber noch andere Möglichkeiten herauszufinden was den login-Zugang ins Backend blockiert, der uns im reload uns verzweifeln läßt. So kann z.B. eine php-Version uns übel mitspielen. Ältere php-Versionen sollte man sowieso nicht einsetzen. Die Allerneuste nicht unbedingt. So kann es mit php 7.3 keine Probleme geben, aber mit php 7.4. So war es in meinem Fall. Der schweigende Login-Loop ist frei Haus geliefert worden.
Davon abgesehen: PhpMyAdmin und MySQL sollten nur mit Wissen um diese bedient werden. Der totale Crash sitzt dann ziemlich nah bei einem und grinst recht teuflisch vor sich hin.
