Support » Allgemeine Fragen » Migration fehlgeschlagen: Request exceeded the limit of 10 internal redirects

  • Gelöst TiiuK

    (@tiiuk)


    Hallo, ich habe Mist gebaut und mir gleich zwei Websites abgeschossen: Einmal die eigentliche WordPress-Installtion, die im Verzeichnis http://www.meinewebsite.com/landingpage liegt und die Staging-Site unter dem Pfad http://www.meinewebsite.com/landingpage/staging. Ich hatte von der Staging Website ein Backup erstellt und dieses dann auf der Live-Seite (www.meinewebsite.com/landingpage) hochgeladen. Peng, Error 500 auf Live und Staging. Error-Log: „Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‚LimitInternalRecursion‘ to increase the limit if necessary. Use ‚LogLevel debug‘ to get a backtrace.“

    Kein Wunder, ich war ja dumm genug das Backend von einer Website einzuspielen, die unter einem anderen Pfad lag, anders kann ich mir den Fehler jedenfalls nicht erklären. Da mein Provider keinen aktuellen Wiederherstellungspunkt hat, bin ich auf Hilfe angewiesen das irgendwie selbst wieder hinzukriegen. Es sollte ja nichts verloren sein. Wie kann ich wieder Ordnung in die Sache bringen?

Ansicht von 5 Antworten - 1 bis 5 (von insgesamt 5)
  • Wenn ich dich richtig verstanden habe, hast du unter http://www.meinewebsite.com/landingpage eine Website, die durch eine neuere Version abgelöst werden soll, die bisher unter http://www.meinewebsite.com/landingpage/staging lief und dazu hast du in deinem Web-Stammverzeichnis die Dateien unter landingpage/ (mit Ausnahme des Verzeichnisses staging) gelöscht und dann die Dateien von landingpage/staging/ nach landingpage/ verschoben?

    Damit müsste die landingpage/wp-config.php bereits die Zugangsdaten zur Datenbank für die „Staging“-Website enthalten. Die Optionen in der Datenbank verweisen aber auf ein nicht mehr vorhandenes Verzeichnis, erzeugen ein 404, der von WordPress abgefangen werden soll, was wiederum einen Aufruf von WordPress im falschen Verzeichnis zur Folge hat – deshalb der „500 Internal Server Error“.

    Lösung wäre in diesem Fall, in der wp-config.php folgendes einzutragen:
    define( 'RELOCATE', true );
    Danach solltest du dich unter http://www.meinewebsite.com/landingpage/wp-login.php anmelden können. Unter Einstellungen > Allgemein trägst du als Website- und WordPress-URL die neue URL http://www.meinewebsite.com/landingpage ein. Danach kannst du in der wp-config.php den o.g. Eintrag wieder rausnehmen. Um die übrigen Links zu korrigieren, kannst du mit dem Plugin Better Search Replace die URL http://www.meinewebsite.com/landingpage/staging durch http://www.meinewebsite.com/landingpage ersetzen. Das sollte es dann auch schon gewesen sein.

    Backups sind wichtig.

    Thread-Starter TiiuK

    (@tiiuk)

    Hallo Bego, vielen Dank, dass du dir die Zeit nimmst. Eine Korrektur zu deiner Zusammenfassung: Ich habe nichts gelöscht. Ich habe „lediglich“ auf der WordPress-Installation unter landingpage das Backup von landingpage/staging/ eingespielt. Das „Full Backup“ (Datenbank, Plugins, Themes & Uploads) wurde mit Updraft Plus erstellt und erfolgreich abgeschlossen. Über dasselbe Plugin habe ich das Backup dann unter landingpage wieder hochgeladen. Ich habe auch im englischsprachigen Supportforum der Plugin-Autoren geschrieben, erhielt aber bis jetzt noch keine Antwort und denke auch, dass es damit nichts zutun hat. Fortschreitende Verzweiflung spielt auch eine Rolle.

    So oder so: Deinen Vorschlag hatte ich bereits probiert, hat nichts gebracht, ein Zugriff aufs Backend war nicht möglich. Ich war dann auch in phpmyAdmin und habe dort in der Tabelle wp_options siteurl und home auf http://www.meinewebsite.com/landingpage gestellt. Brachte auch nichts. Was mich irritiert ist, dass auch die Staging-Seite nicht mehr erreichbar ist. An der wurde doch nichts geändert?

    Das klingt tatsächlich … verwirrend.

    In solchen Fällen versuche ich, mir erst einmal einen Überblick zu verschaffen. Welche Dateien sind vorhanden? Sind mehrere WordPress-Installationen ineinander verschachtelt (was grundsätzlich fehleranfällig ist)? Was steht in der wp-config.php? Auf welche Datenbank verweist sie? Sind in der Datenbank Tabellen mehrerer WordPress-Installationen (mit unterschiedlichen Tabellen-Präfix)?

    Es passiert nicht selten, dass Anwender Änderungen an der einen Datenbank(-tabelle) vornehmen, die fragliche WordPress-Installation aber auf eine andere Datenbank zugreift. Ich kenne Fälle, bei denen es Stunden gedauert hat, bis der Anwender auf diese Verwechselung aufmerksam wurde. Ich mache dann immer mal eine Runde um den Block – frische Luft hilft.

    Andererseits … Wenn du Backups hast, kannst du damit die Installation neu aufsetzen. Alle Dateien im Web-Stammverzeichnis löschen (vielleicht doch vorher nochmal manuell auf den eigenen PC sichern?), Datenbank löschen (vielleicht doch nochmal …), WordPress neu installieren, Backup-Plugin installieren, Backup wiederherstellen – alles zusammen eine knappe halbe Stunde Aufwand und vielleicht effizienter, als eine (zu) lange forensische Untersuchung?

    Thread-Starter TiiuK

    (@tiiuk)

    Hallo, ich habe mich jetzt zwar eine Weile nicht gemeldet aber dein Posting hat mir an dem Tag etwas Seelenruhe verschafft, das war vielleicht das Wichtigste. Ich habe es dann noch mal mit allem probiert, habe letztlich aber meinen Hoster angeschrieben und auch wenn der Support langatmig ist: Nach viel Trial und Error läuft die Seite nun wieder. Das Ärgerliche: Mir wurde nur gesagt, dass etwas in der .htaccess nicht stimmte und dass es generell problematisch werden könne, wenn WordPress Installationen ineinander verschachtelt wären. Also keine WordPress-Installation in ein Unterverzeichnis einer anderen WP-Installation packen. Die Frage nach dem Warum bleibt. In der .htaccess sehe ich nichts, was ich nicht selbst schon eingetragen hätte, sehr mysteriös das Ganze.
    Das Beste: Nachdem ENDLICH alles wieder lief passte ich die Permalinks an. Zack, wieder alles kaputt. Zum Glück musste ich nur die .htaccess um RewriteEngine on ergänzen.

    Das hört sich jetzt zumindest so an, als ob alles wieder laufen würde?
    Ich markiere den Thread dann mal als gelöst.

Ansicht von 5 Antworten - 1 bis 5 (von insgesamt 5)
  • Das Thema „Migration fehlgeschlagen: Request exceeded the limit of 10 internal redirects“ ist für neue Antworten geschlossen.