Support » Themes » ERR_TOO_MANY_REDIRECTS – Fehler auf einer Seite

  • lebrochet

    (@lebrochet)


    hallo @pixolin und @hage

    hab auf einer BETA-BETA-Seite noch ein paar kleine Errors:

    auf https://f-s-j.de

    anm: die Seite ist – da noch kpl im BETA-Moduls mit einer eingeschränkten Seitentzugang ausgestattet – ( restricted site-Access )


    wenn ich sie direkt aufrufe dann erhalte ich das folgende:


    Diese Seite funktioniert nicht mysite.de hat Sie zu oft weitergeleitet.
    Löschen Sie Ihre Cookies.
    ERR_TOO_MANY_REDIRECTS

    während hingegen:
    login geht:
    https://f-s-j.de/wp-login.php?redirect_to=https%3A%2F%2Ff-s-j.de%2Fwp-admin%2Fabout.php&reauth=1


    Dann – also wenn ich direkt das so eingebe, dann geht es:

    denke mal, dass ein verfolgter Trace von wget oder curl :: ich muss mal alles in den Chrome-Entwicklertoools ansehen. Denke, hier hilft wohl auch der Entwickler-Modus des Browsers.

    Grundsätzlich sieht das wie ein Paradebeispiel für diesen Fehler aus – m.a.W. daß eine Seite auf eine zweite Seite weiterleitet und diese dann wieder zurück auf die erste.

    Was meint ihr denn hierzu!?

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 22)
  • Hallo,
    vielleicht hilft eine der folgenden Lösungsmöglichkeiten in dieser Anleitung

    Bitte lösche auch nochmal per FTP die Datei .htaccess in deinem Web-Stammverzeichnis (du kannst sie auch vorsichtshalber einfach umbenennen). Geh anschließend in Einstellungen > Permalinks und wähle eine URL-Struktur aus. Die .htaccess wird dabei neu erstellt.

    Viele Grüße
    Hans-Gerd

    Moderator Bego Mario Garde

    (@pixolin)

    die Seite ist – da noch kpl im BETA-Moduls mit einer eingeschränkten Seitentzugang ausgestattet – ( restricted site-Access )

    Kann ich nicht reproduzieren – die Anmeldeseite wird ohne Einschränkungen angezeigt.

    Bei der Startseite erhalte ich allerdings eine Weiterleitung zu https://f…j.de/index.php/myaccount/, was eher ungewöhnlich ist. Die Linkstruktur mit index.php wird wohl bei einem Webhosting bei der Telekom benötigt, sonst eher nicht.

    Die REST-API ist gesperrt. Dadurch kann ich bestimmte Daten nicht abrufen.

    Übrigens gibt es hier noch andere aktiv Teilnehmende außer Hans-Gerd und mir.

    Thread-Starter lebrochet

    (@lebrochet)

    Hallo Hans-Gerd, hallo Mario, vielen Dank für Eure Rückmeldung. Freue mich sehr von Euch zu hoeren.

    Also – ich hab gleich mal nachgesehen – und geguckt wie es der .htaccess geht – und ja: da ist in diesem webroot keine htaccess drinne.

    Sehr merkwürdig würde ich mal sagen. Das ist doch auffällig. Hab noch eine zweite Seite auf dem Server – da ist eine .htaccess dabei.

    @pixolin – ist auf einem Rootserver drauf – das Backend macht mein Freund der sich mit Linux ganz gut auskennt.

    sollte ich eine .htaccess da nun einbringen!?

    Freu mich von Euch zu hoeren.

    Viele Grüße
    Lebrochet;)

    Moderator Bego Mario Garde

    (@pixolin)

    ist auf einem Rootserver drauf – das Backend macht mein Freund der sich mit Linux ganz gut auskennt.

    Outch.

    Die Administration eines Webservers sollte nicht als Freundschaftsdienst „nebenbei“ betrieben werden. Das setzt viel Kenntnisse zur Abwehr von Angriffen aller Art voraus und erfordert laufende Aktualisierungen, im Zweifelsfall täglich.

    Was ist denn bei Permalinks eingestellt? Ich würde die zuerst auf „Einfach“ stellen und schauen, wie sich die Website verhält. Danach kannst du prüfen, ob der Server mod_rewriteunterstützt und einen Permalink „Beitragsname“ einrichten, wobei dann automatisch eine .htaccess erstellt werden sollte. Oder geht die Anmeldung im Backend gar nicht?

    Thread-Starter lebrochet

    (@lebrochet)

    hi danke fuers Ruckmelden.

    so sind im Moment die settings im Bereich Permalink

    Moderator Bego Mario Garde

    (@pixolin)

    Welcher Teil an „Ich würde die zuerst auf „Einfach“ stellen und schauen, wie sich die Website verhält.“ war jetzt irgendwie missverständlich? 😛

    Thread-Starter lebrochet

    (@lebrochet)

    hallo und guten Abend
    vielen Dank!!!
    also – ich glaub dass das nun besser geworden ist. Das sieht m.E. besser aus. BTW – denke dass es hier auch (immer noch) darauf ankommt die cookies zu loeschen. – bzw. dass von anderen Browsern aus, das Verhalten ohnehin besser ist.
    ‚Also ich werd am Wochenende das mal näher noch untersuchen.

    Euch beiden schon jetzt vielen vielen Dank!! Euer Support hier ist einfach unglauglich toll und sucht seinesgleichen im Netzt.

    Viele Grüße
    lebrochet. 😉

    Euch beiden schon jetzt vielen vielen Dank!! Euer Support hier ist einfach unglauglich toll und sucht seinesgleichen im Netzt.

    danke 😊
    Wir freuen uns auf deine Rückmeldung.

    Moderator Bego Mario Garde

    (@pixolin)

    Allerdings funktioniert die Website immer noch nicht …

    ¯\_(ツ)_/¯

    Thread-Starter lebrochet

    (@lebrochet)

    hi und guten Abend,

    also ich hab dann und wann noch diesen Error.

    f-s-j.de hat Sie zu oft weitergeleitet.
    Löschen Sie Ihre Cookies.
    ERR_TOO_MANY_REDIRECTS
    Thread-Starter lebrochet

    (@lebrochet)

    Also die .htaccess ist nicht drinne gewesen.

    Also es ist so, wenn man diese Seite (wenn man sie mit https anspricht) ständig selbst auf /?page_id=66 weiterleitet (HTTP 302), in
    der von mir bereits angesprochenen Endlosschleife. Nach etwa 20 Versuchen geben die Browser dann auf und spucken die Fehlermeldung aus.

    Probiert man’s mit http, gibt’s HTTP 403 Forbidden. Wenn man eine Datei anspricht, die es nicht gibt (z.B. /sowieso_sowieso.php) bekommt man eine echte Antwort mit „access denied“.
    Das glaube ich, das liegt an der Permalink-Einstellung die ich vorgenommen habe. Was meint ihr denn!?

    btw: das dauernde “ Zurückfallen auf dei page_id=66 – das ist die Account-Seite

    Account — My Account Page
    https://f-s-j.de/wp-admin/post.php?post=66&action=edit

    koennten die Errors dggf damit zusammmenhängen – dass das immer wieder auf die Ammeldeseite “ zurückfälll“

    Freue mich von Euch zu hören

    vg

    Moderator Bego Mario Garde

    (@pixolin)

    Das glaube ich, das liegt an der Permalink-Einstellung die ich vorgenommen habe. Was meint ihr denn!?

    Ich meine, dass das anhand deiner Beschreibung kaum nachvollziehbar ist. Wir kennen die Serverkonfiguration nicht und es ich auch nicht klar, wieso du keine .htaccess verwendest, wie der Virtual Host aufgesetzt ist und so weiter … Ohne Website-Bericht spielen wir hier sowieso Blinde-Kuh. → Status des Threads auf „keine Support-Frage“ geändert.

    Thread-Starter lebrochet

    (@lebrochet)

    hallo und guten Morgen
    vorweg: bin zur Zeit (berufl.) unterwegs im Ausland u. hab immer nur ganz begrenzt Zeit zu Recherchen, Kontrollen u.s.w.

    Sorry also für die vllt. spährlichen Infos zum Thema, zu Details u.s.w. Nächste Woche zurück in D. kann ich hier viel viel mehr Daten liefern. Sorry also dass das für eine ordentliche, korrekte Frage im Moment nicht reicht.
    Für mich sind die Threads hier – dieser u. andere – immer(!!!) sehr sehr hilfreich.
    Also – euch nochmals vielen vielen Dank u. euch einen schönen Tag,
    ‚melde mich spätestens kommende Woche mit mehr Infos, Daten u.sw.

    viele Grüße LeBrochet

    Thread-Starter lebrochet

    (@lebrochet)

    hallo u. guten Tag,

    bin wieder @home – und kann mich nun stärker darum kümmern:
    hier ein paar weitere Daten zur Serverkonfiguration u.s.w. usf.

    Permalink structure: gewählt:
    Plain: https://f-s-j.de/?p=123

    zum Setup des Servers hier ein paar Details:

    PHP Version 7.4.28

    Loaded Modules:

    core mod_so http_core mod_authn_file mod_authn_core mod_authz_host mod_authz_groupfile
    mod_authz_user mod_authz_core mod_access_compat mod_auth_basic mod_auth_digest mod_socache_shmcb
    mod_watchdog mod_ratelimit mod_reqtimeout mod_filter mod_deflate mod_mime mod_log_config mod_env
    mod_mime_magic mod_expires mod_headers mod_usertrack mod_setenvif mod_version mod_session
    mod_session_cookie mod_ssl prefork mod_unixd mod_status mod_autoindex mod_dir mod_alias
    mod_rewrite mod_php7

    die .htaccess fehlt leider immer noch:

    Hmm – iwie siehts für mich so aus als würde der Index fehlen oder der Index
    findet diese page_id nicht:

    Und dann am Ende weiß alles sich nicht anders zu helfen, als mit
    einem Redirect auf die dann immer noch nicht vorhandene page_id 66 zu verweisen.

    hmm – bin im Mom. nicht sicher was tun – ggf. nochmals gucken ob das tatsächlich mit der page_id 66 zu tun hat!?

    GGF sollt ich einfach alles nochmals frisch aufsetzen.. !?

    WordPress speichert die Inhalte deiner Beiträge und Seiten in der Datenbank, wobei jeder „post“ eine eigene Datenbank-ID erhält. Mit Aufruf der URL mit einem GET-Parameter wird WordPress mitgeteilt, welcher post aus der Datenbank abgerufen werden soll, z.B. https://example.com/?p=42 für einen post mit der Datenbank-ID 42.

    Da sich Menschen Zahlen schlechter merken können, als aussagefähige Begriffe, gibt es die Möglichkeit, „Pretty Permalinks“ („sprechende Permalinks“) einzurichten. Hier wird anstelle eines GET-Parameters der Domain eine Bezeichnung („Slug“) angehängt, nach der WordPress in der Datenbank suchen soll. Zu einer URL https://example.com/ueber-mich wird die Datenbank-ID eines Beitrags mit dem Slug ueber-mich herausgesucht und dann die Webseite ausgegeben.

    Eigenlich wäre ueber-mich aber ein Verzeichnisname und der Webserver würde eine Fehlermeldung ausgeben, da es ein Verzeichnis ueber-mich nicht gibt. Deshalb braucht es bei der Nutzung von Pretty Permalinks eine Weiterleitungsregeln, die auf Apache-Webservers in einer .htaccess angelegt wird. Teil dieser Weiterleitungsregeln sind die folgenden Zeilen:

    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    Umgangssprachlich ausgedrückt bedeutet das:

    • Wird die index.php direkt aufgerufen, öffne diese Datei.
    • Wird ein Verzeichnispfad oder ein Dateiname aufgerufen und das Verzeichnis oder die Datei existiert nicht, öffne ebenfalls die index.php.

    Das sorgt dafür, dass du bei Aufruf von https://example.com/readme.html die tatsächlich vorhandenen Datei readme.html (mit einer kurzen Begrüßung zu WordPress) angezeigt bekommst, ansonsten aber der Slug an WordPress übergeben wird, um den passenden post rauszusuchen und als Webseite auszugeben.

    Änderst du unter Einstellungen die Permalinks z.B. auf Beitragsname, sollte WordPress eigenständig eine .htaccesseinrichten. Geht das nicht, weil z.B. die Dateiberechtigungen falsch gesetzt sind, wirst du darauf hingewiesen und aufgefordert, den notwendigen Code selber als .htaccess abzuspeichern.

    Damit Pretty Permalinks funktionieren muss der Webserver das Modul mod_rewrite geladen haben. Es reicht nicht, dass das Modul vorhanden ist; es muss vom Systemadministrator mit a2enmod mod_rewrite aktiviert werden und der Webserver muss mit systemctl restart apache2 neu gestartet werden. Anderenfalls kommt es nur zu Fehlermeldungen „404 – File not found“, weil der Slug nur als fehlendes Verzeichnis interpretiert wird.

    Die Aussage

    … Und dann am Ende weiß alles sich nicht anders zu helfen, als mit
    einem Redirect auf die dann immer noch nicht vorhandene page_id 66 zu verweisen.

    stellt die Funktion von Permalinks auf den Kopf. Ich weiß nicht, was du damit bewirken möchtest.
    Wenn es einen post mit der ID 66 gibt, sollte https://example.com/?p=66 den Beitrag/die Seite anzeigen. (In WordPress werden alle Inhalte – Seiten und Beiträge – in der Datenbank-Tabelle wp_posts gespeichert und als „post“ bezeichnet. Für die Abfrage mit GET-Paramater ist es egal, ob es sich um eine Seite oder einen Beitrag handelt.)

    Hast du Pretty Permalinks eingerichtet und der post mit der ID 66 hat z.B. einen Slug impressum, müsste der Beitrag/die Seite sowohl mit https://example.com/?p=66, als auch mit https://example.com/impressum abrufbar sein.

    Übrigens wird PHP 7.4 nicht mehr mit Sicherheitsupdates versorgt und sollte deshalb nicht mehr genutzt werden. Der Server sollte auf die Nutzung von PHP 8.x umgestellt werden.

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 22)
  • Das Thema „ERR_TOO_MANY_REDIRECTS – Fehler auf einer Seite“ ist für neue Antworten geschlossen.