NeuBlack Friday – 50 % Rabatt auf die erste Zahlung
WordPress-Fehlerbehebung

404 auf jeder Seite außer der Homepage

Ein sehr spezifisches Muster mit einer sehr kurzen Liste von Ursachen. Ihre Posts existieren immer noch; der Router davor ist kein Routing.

404 Not Found — the requested page could not be found.

Kurzantwort

Die Homepage ist die einzige URL, die keine Rewrite-Regel benötigt, weshalb sie der einzige Überlebende ist. Bestätigen Sie, indem Sie einen Beitrag mit einer Abfragezeichenfolge anstelle des Permalinks anfordern - wenn dieser geladen wird, ist der Inhalt in Ordnung und die Rewrite-Ebene ist das ganze Problem.

Diagnose

Die wahrscheinlichsten Ursachen zuerst.

Gehen Sie die Liste der Reihe nach durch. Prüfen Sie jede Ursache, bevor Sie etwas ändern, da die Lösungen unterschiedlich sind und eine Vermutung mehr Zeit kostet als ein Befehl.

UrsacheSo prüfen Sie esLösung
Stale oder fehlende Rewrite RegelnDie Query-String-Form eines Posts lädt und der hübsche Permalink nicht. Nichts am Inhalt unterscheidet sich zwischen den beiden Requests.Die Permalink-Einstellungen zu speichern, geschieht über die Schnittstelle; auf der Kommandozeile ist es ein einzelner Aufruf.
Der Webserver sendet keine unbekannten Pfade an WordPressDer 404 ist die eigene Seite des Webservers und nicht die des Themes. WordPress lief nie, also kann es ihn nicht produziert haben.Fügen Sie den Frontcontroller-Fallback hinzu, damit jeder Pfad, der keine echte Datei ist, an index.php übergeben wird.
AllowOverride ist ausgeschaltet, also wird .htaccess ignoriertAuf Apache existiert die Datei und ist korrekt und ihre Änderung hat überhaupt keine Auswirkungen.Aktivieren Sie AllowOverride für das Verzeichnis oder verschieben Sie die entsprechenden Regeln in den virtuellen Host, wo sie immer gelesen werden.
Eine Permalink-Struktur, die die Site nicht bedienen kannDas Problem begann unmittelbar nach der Änderung der Permalink-Struktur, und die Rückkehr zu einfachen Permalinks stellt alles wieder her.Eine führende Kategorie oder eine benutzerdefinierte Post-Typ-Basis, die mit einem vorhandenen Seitenpfad kollidiert, ist die übliche Falle.
Anleitung

Schritt für Schritt zur Lösung.

Die Befehle setzen WP-CLI und Shell-Zugriff voraus. Jeder Schritt erklärt, was er tut, damit Sie ihn bei Bedarf im Dashboard oder per SFTP ausführen können.

  1. Beweisen Sie, dass der Inhalt noch da ist

    Wenn dieser geladen wird, geht nichts verloren und der Fix befindet sich vollständig in der Rewrite-Schicht.

    curl -sS -o /dev/null -w '%{http_code}\n' 'https://example.com/?p=1'
  2. Reglementieren Sie die Regeln

    Das erste, was man versuchen sollte, und oft das letzte.

    wp rewrite flush --hard
    wp rewrite list --format=count
  3. Überprüfen Sie, ob der Server tatsächlich auf index.php zurückfällt

    Dies ist die nginx-Form. Ohne sie werden nur Pfade bedient, die auf der Festplatte existieren.

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
  4. Wiederherstellen eines bekannten Gut .htaccess auf Apache

    Wenn das Schreiben nichts ändert, ist AllowOverride deaktiviert und die Datei wird ignoriert.

    # BEGIN WordPress
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    # END WordPress
  5. Bestätigen Sie, dass ein echter Permalink jetzt aufgelöst wird

    Fragen Sie WordPress nach einer URL, die es selbst generiert hat, so dass es keine Chance gibt, einen Pfad zu testen, der nie existiert hat.

    wp post list --post_type=post --posts_per_page=1 --field=url | xargs -I{} curl -sS -o /dev/null -w '%{http_code}\n' {}
Mit MagicWP

Darum kümmert sich die Plattform.

Der Front-Controller-Fallback ist von dem Moment an Teil der nginx-Konfiguration jeder Site, so dass die häufigste Version davon — ein Server, der nur Dateien bedient, die auf der Festplatte vorhanden sind — nicht auftreten kann. Es gibt keinen .htaccess im Anforderungspfad, der ignoriert, von einem Plugin überschrieben oder bei einer Wiederherstellung verloren gehen soll, weil die Regeln in der Server-Konfiguration der Site und nicht in einer Datei innerhalb des Webroots leben.

Häufige Fragen

Häufige Fragen.

Habe ich meine Posts verloren?
Nein. Der Abfrage-String-Test beweist es: Der gleiche Beitrag, den 404s bei seinem Permalink per ID lädt. Nur das Mapping von URL zu Inhalt ist gebrochen.
Warum funktioniert die Homepage noch?
Es ist die Wurzel des Dokuments, also braucht es keine Regel umzuschreiben, um gefunden zu werden. Jede andere URL hängt von dem Regelsatz ab, der fehlt, und genau deshalb hat der Fehler diese Form.
Ich spülte die Regeln und nichts änderte sich. Was nun?
Das weist auf eine Ebene hin: Der Server gibt WordPress überhaupt keine unbekannten Pfade. Flushing schreibt um, was WordPress weiß, was nutzlos ist, wenn die Anforderung es nie erreicht.
Könnte ein Plugin dies verursacht haben?
Ja - alles, was einen benutzerdefinierten posttyp oder eine taxonomie registriert, fügt regeln hinzu, und das hinzufügen eines ohne spülen lässt die neuen urls 404ing, bis die regeln neu erstellt werden.
Verwandte Fehler

War es keiner davon?

Diese Fehler können im Browser ähnlich aussehen.