Geänderte Kerndateien? So stellen Sie WordPress-Kerndateien sicher wieder her

Sie sehen einen weißen Bildschirm, wo früher Ihre Homepage war. Vielleicht ist es stattdessen ein 500er-Fehler, oder eine Sicherheits-Plugin-Meldung, die Ihnen mitteilt, dass WordPress-Kerndateien modifiziert wurden.

Ich habe Kerndateien auf Websites ersetzt, die ich selbst kaputt gemacht habe, und auf Websites, die bereits kaputt ankamen. Was auch immer Sie hierher gebracht hat, die Lösung ist dieselbe und weniger zerstörerisch, als es klingt.

Das Wiederherstellen von WordPress-Kerndateien bedeutet, die eigenen Programmdateien von WordPress (die in wp-admin, wp-includes und Ihrem Stammverzeichnis) durch saubere Kopien von WordPress.org auszutauschen. Ihre Beiträge, Seiten, Medien, Themes, Plugins und Einstellungen werden nicht verschoben. Sie leben woanders.

Zwei Dinge gehen schief, wenn Leute dies selbst versuchen.

Das erste ist das Löschen von wp-content zusammen mit den Kernordnern, was eine 20-minütige Reparatur in einen vollständigen Neuaufbau verwandelt. Das zweite ist das Herunterladen der neuesten Version von WordPress, wenn die Website eine ältere Version verwendet, was einen Versionssprung auf eine bereits instabile Website erzwingt.

In diesem Beitrag zeige ich Ihnen, wie Sie überprüfen, ob Core-Dateien das Problem sind, bevor Sie etwas löschen, drei Möglichkeiten, sie zu ersetzen, und was zu tun ist, wenn das Ersetzen nicht die eigentliche Lösung ist.

Schnelle Erkenntnisse:

• Überprüfen Sie, bevor Sie etwas löschen: wp core verify-checksums beantwortet mit einem einzigen Befehl, ob Core-Dateien das Problem sind. Ein sauberer Durchlauf bedeutet, dass Sie Dateien ersetzen würden, die nie defekt waren.
• Passen Sie Ihre Version an, anstatt die neueste zu nehmen: Die Installation des neuesten WordPress auf einer älteren Website erzwingt ein ungeplantes Haupt-Upgrade und eine Änderung des Datenbankschemas auf einer bereits instabilen Website.
• Sie haben drei Möglichkeiten: die Schaltfläche Version X.X.X neu installieren, wenn Sie sich anmelden können, ein WP-CLI-Befehl, wenn Sie SSH haben, und ein manueller FTP-Austausch, wenn Sie beides nicht haben.
• Löschen Sie die Kernordner, anstatt sie zu überschreiben: Beim Überschreiben bleiben vom Angreifer hinzugefügte Dateien in wp-admin und wp-includes sitzen, da nichts im offiziellen Build eine Datei ersetzt, die nicht Teil davon ist.
• Saubere Core-Dateien bereinigen keine gehackte Website: Backdoors in wp-content/uploads, bösartige mu-Plugins und injizierte Datenbankzeilen überleben alle, was der Punkt ist, an dem eine vollständige Wiederherstellung eine dateibasierte Reparatur übertrifft.

Inhaltsverzeichnis

Welche Dateien sind WordPress-Kerndateien?

Bevor Sie etwas löschen, müssen Sie wissen, welche Ordner als WordPress-Kern-Dateien gelten und welche Ihnen gehören. Dies falsch zu machen, ist der teuerste Fehler im gesamten Prozess.

Hier ist, was als Kern-Datei gilt:

• Alles in wp-admin. Dies ist das Admin-Dashboard selbst, jeder Bildschirm, in den Sie sich einloggen.
• Alles in wp-includes. Dies sind die Bibliotheken, auf denen WordPress läuft. Es ist der größte Ordner nach Dateianzahl und derjenige, der am wahrscheinlichsten als modifiziert markiert wird.
• Die einzelnen PHP-Dateien in Ihrem Stammverzeichnis. Dateien wie index.php, wp-login.php, wp-settings.php und wp-cron.php befinden sich neben Ihren Ordnern und werden ebenfalls ersetzt.

Welche WordPress-Dateien sollten Sie nicht ersetzen?

Hier ist, was Sie in Ruhe lassen sollten:

• wp-content. Es enthält websitespezifische Uploads, installierte Plugins, Themes, mu-Plugins und manchmal Artefakte des Hosts oder der Bereitstellung. WordPress liefert eine Kopie dieses Ordners, aber Ihrer ist einzigartig.
• wp-config.php. Dies enthält Ihre Datenbankanmeldeinformationen. Wenn Sie es überschreiben, kann Ihre Website ihre eigenen Inhalte nicht finden.
• .htaccess. Es ist keine Kern-Datei, aber WordPress schreibt hinein. Speichern Sie eine Kopie und lassen Sie das Original an Ort und Stelle.
• Alles, was Ihr Host oder Ihr Entwickler hinzugefügt hat. Domain-Verifizierungsdateien, benutzerdefinierte Skripte, eine manuell bearbeitete robots.txt. Wenn es nicht im WordPress-Download enthalten war, bleibt es.

Wenn Sie wp-content löschen, stellen Sie keine Kern-Dateien mehr wieder her. Sie bauen Ihre Website von Grund auf neu.

Wann müssen Sie WordPress-Kerndateien wiederherstellen?

Kern-Dateien bleiben monatelang unberührt. Wenn sie kaputtgehen, liegt es fast immer an einer von wenigen Ursachen. Zu wissen, welche davon Sie gerade erleben, ändert, wie Sie die anschließende Bereinigung durchführen.

Hier ist, wann das Ersetzen von Kern-Dateien die richtige Entscheidung ist:

• Ein Kern-Update ist fehlgeschlagen. Die Verbindung wurde unterbrochen, der Server hat das Zeitlimit überschritten oder PHP hat sein Speicherlimit erreicht. Sie bleiben mit einigen Dateien der alten Version und einigen der neuen Version zurück, und WordPress hat keine Möglichkeit, die beiden zu versöhnen.
• Ein Scan hat gemeldet, dass Kern-WordPress-Dateien modifiziert wurden. Wordfence, Sucuri und viele Managed Hosts vergleichen Ihre Dateien mit den offiziellen Versionen von WordPress.org. Eine modifizierte Kern-Datei bedeutet, dass etwas am Code geändert wurde, den niemand bearbeiten sollte.
• Ihre Website wurde gehackt. Angreifer injizieren Code in Kern-Dateien, weil diese Dateien bei jeder einzelnen Anfrage geladen werden. Das Ersetzen dieser Dateien löscht den injizierten Code (es löscht nicht den Rest der Infektion, dazu komme ich später).
• Dateien wurden während einer Übertragung beschädigt. Eine abgebrochene FTP-Sitzung oder eine halb abgeschlossene Migration hinterlässt unvollständige Dateien. Sie sehen in einer Dateiliste normal aus und schlagen fehl, sobald PHP versucht, sie auszuführen.
• Ein weißer Bildschirm oder ein 500-Fehler hat grundlegende Fehlerbehebungen überlebt. Wenn Sie jedes Plugin deaktiviert, zu einem Standard-Theme gewechselt haben und der Fehler nicht behoben wurde, sind die Kern-Dateien der nächste Ort, an dem Sie suchen sollten.
• Jemand hat absichtlich eine Kern-Datei bearbeitet. Das passiert öfter, als Sie denken. Die Bearbeitung bleibt bestehen, bis ein Update sie überschreibt oder die Datei nicht mehr mit dem übereinstimmt, was WordPress erwartet.

Es gibt eine Situation, in der das Wiederherstellen von Kern-Dateien Ihnen überhaupt nicht hilft: ein defektes Plugin oder Theme. Dieser Vorgang berührt wp-content nicht. Wenn das also das eigentliche Problem ist, werden Sie die ganze Arbeit machen und denselben Fehler erhalten. Schritt 1 zeigt Ihnen, wie Sie das herausfinden, bevor Sie eine Stunde damit verbringen.

Was Sie vor dem Start benötigen

Hier ist, was Sie bereithalten sollten, bevor Sie Kern-WordPress-Dateien wiederherstellen:

• Ein vollständiges Backup, das Sie jetzt erstellen. Speichern Sie es irgendwo getrennt vom Server, den Sie gleich ändern werden (ich empfehle Duplicator Cloud). Wenn Sie Duplicator Pro verwenden, ist dies das, was einen schlechten Nachmittag in eine Ein-Klick-Wiederherstellung verwandelt.
• Zugriff über mindestens eine der folgenden Möglichkeiten: Das WordPress-Dashboard, SFTP oder FTP (FileZilla ist kostenlos und erledigt die Aufgabe), der Dateimanager Ihres Hosts oder SSH. Sie benötigen nur eine davon, und welche Sie haben, bestimmt Ihre Methode in Schritt 4.
• Ihre genaue WordPress-Versionsnummer, aufgeschrieben. Wenn das Dashboard nicht erreichbar ist, öffnen Sie wp-includes/version.php über FTP und lesen Sie die Zeile $wp_version ganz oben.
• Lokale Kopien von wp-config.php und .htaccess. Laden Sie beide herunter, bevor Sie etwas anfassen.
• 15 bis 30 Minuten, abhängig davon, welche Methode Sie letztendlich verwenden.

Wenn Ihre Website echten Traffic hat, machen Sie dies während einer ruhigen Stunde. Sie wird teilweise kaputt sein, während der Upload läuft.

So stellen Sie WordPress-Kerndateien wieder her

Der Prozess läuft in sechs Schritten ab. Drei davon sind immer gleich, und in Schritt 4 wählst du einen Pfad basierend auf dem verbleibenden Zugriff aus.

So stellst du deine WordPress-Core-Dateien wieder her:

• Schritt 1: Bestätige, dass die Core-Dateien das Problem sind. Ein Checksummen-Scan sagt dir, ob du das Richtige reparierst, bevor du etwas löschst, das du nicht rückgängig machen kannst.
• Schritt 2: Sichere die Website, bevor du etwas ersetzt. Eine Übertragung, die mitten im Austausch abbricht, kann die gesamte Website lahmlegen, und dieser Schritt macht sie wiederherstellbar.
• Schritt 3: Wähle die WordPress-Version, die du wiederherstellst. Das Herunterladen der falschen Version macht aus einer Reparatur ein ungeplantes Upgrade auf einer defekten Website.
• Schritt 4: Ersetze die Core-Dateien. Wähle das Dashboard, WP-CLI oder FTP basierend auf deinem Zugriff und führe nur eine der drei Optionen aus.
• Schritt 5: Führe das Datenbank-Upgrade durch und lösche die Überbleibsel. Neuer Code gegen ein altes Schema, eine hängende .maintenance-Datei und veraltete Caches werden als „immer noch kaputt“ angezeigt, wenn die Dateien bereits in Ordnung sind.
• Schritt 6: Überprüfe, ob die Wiederherstellung funktioniert hat. Eine geladene Website ist kein Beweis für irgendetwas, ein zweiter sauberer Checksummen-Durchlauf schon.

Schritt 1: Bestätigen Sie, dass die Kerndateien das Problem sind

Wenn du diesen Schritt überspringst, kannst du eine Stunde damit verbringen, Dateien zu ersetzen, die nie kaputt waren. Ich habe es getan. Eine beschädigte Core-Datei und ein fataler Plugin-Fehler sehen von außen identisch aus.

WP-CLI löst die Frage mit einem Befehl.

WP-CLI ist das Kommandozeilen-Tool von WordPress, und du führst es über SSH aus (eine Terminalverbindung zu deinem Server). Die meisten Managed Hosts haben es bereits installiert, also prüfe, bevor du annimmst, dass es nicht verfügbar ist.

Verbinde dich über SSH, wechsle in dein WordPress-Verzeichnis und führe aus:

wp core verify-checksums

WordPress.org veröffentlicht für jede Datei in jeder Version eine Checksumme, einen kurzen Fingerabdruck des Inhalts dieser Datei. Der Befehl ruft die Liste für deine Version ab und vergleicht sie mit dem, was auf deinem Server liegt.

Eine saubere Installation gibt eine einzelne Erfolgsmeldung zurück. Eine beschädigte benennt jede Datei, die sie nicht verifizieren kann:

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

Ein Ergebnis ist ein Fehlalarm, der es wert ist, erkannt zu werden. readme.html schlägt ständig fehl, weil Hosts sie ändern oder löschen. Der Befehl erkennt die Sprache deiner Installation automatisch, sodass du nur das Flag --locale benötigst (z. B. wp core verify-checksums --locale=de_DE), wenn er falsch rät.

Führe ihn dann erneut mit --include-root aus:

wp core verify-checksums --include-root

Dieses Flag warnt dich vor Dateien in deinem Stammverzeichnis, die überhaupt nicht zu WordPress gehören. Auf einer gehackten Website findest du dort oft die Ursache des Problems.

Wenn du keinen SSH-Zugriff hast, gibt es drei weitere Möglichkeiten zur Überprüfung:

• Führe einen Wordfence-Scan durch. Sein Vergleich der Core-Dateien erledigt die gleiche Aufgabe vom Dashboard aus und zeigt dir genau, was sich in jeder Datei geändert hat.
• Verwende das Dateintegritäts-Tool deines Hosts. Die meisten Managed Hosts haben eines, normalerweise unter einer Sicherheits- oder Tools-Registerkarte.
• Vergleichen Sie manuell. Laden Sie eine frische Kopie Ihrer WordPress-Version herunter, öffnen Sie die verdächtige Datei aus beiden Kopien und lesen Sie sie nebeneinander.

Lesen Sie nun Ihre Ergebnisse ehrlich durch, bevor Sie weitergehen. Wenn die Prüfsummen sauber sind, sind Ihre Kerndateien in Ordnung und Ihr Problem liegt bei einem Plugin, einem Theme oder Ihrer Datenbank.

Das Ersetzen von Kerndateien wird keines davon beheben.

Sie sind bereit für Schritt 2, wenn Sie entweder eine Liste spezifischer Dateien haben, die die Überprüfung nicht bestanden haben, oder eine saubere Bestätigung, die Ihnen sagt, dass Sie woanders suchen sollen.

Schritt 2: Sichern Sie die Website, bevor Sie etwas ersetzen

Sie sind dabei, zwei Ordner zu löschen, die WordPress zum Ausführen benötigt. Wenn der Upload, der sie ersetzt, auf halbem Weg abbricht, wird Ihre Website von kaputt zu verschwunden.

Das ist ein schlimmeres Problem als das, das Sie jetzt haben.

Erstellen Sie ein vollständiges Backup, das sowohl Ihre Dateien als auch die Datenbank umfasst. Stellen Sie sicher, dass Sie eine Kopie irgendwo anders als auf dem Server speichern, den Sie bearbeiten möchten. Eine Kopie außerhalb des Standorts ist die einzige, die einen Serverausfall überlebt.

Duplicator ist mein Lieblingstool dafür. Gehen Sie zu Duplicator Pro » Backups und klicken Sie auf Add New.

Wählen Sie die Full Site Backup-Voreinstellung und wählen Sie mindestens zwei Speicherorte (ich verwende gerne Local und Duplicator Cloud).

Sie werden mit zwei Dateien enden: dem Archiv, das Ihre komprimierte Website und Datenbank enthält, und dem Installer, dem PHP-Skript, das alles wiederherstellt.

Wenn während des Dateiwiederherstellungsprozesses etwas schief geht, laden Sie diese Dateien erneut auf Ihren Server hoch und starten Sie den Duplicator-Installer.

Wenn Sie Duplicator nicht verwenden, erstellen Sie ein manuelles Backup. Hier ist das absolute Minimum für diesen Schritt:

• Laden Sie wp-content, wp-config.php und .htaccess über FTP auf Ihren Computer herunter.
• Exportieren Sie Ihre Datenbank aus phpMyAdmin als .sql-Datei.

Sie sind bereit, fortzufahren, wenn Sie wissen, wo sich Ihr Backup befindet und wie Sie es wiederherstellen würden.

Schritt 3: Passen Sie die wiederherzustellende WordPress-Version an

Jedes Tutorial zu diesem Thema sagt Ihnen, dass Sie die neueste Version von WordPress herunterladen sollen. Das ist ein guter Rat, wenn Ihre Website bereits die neueste Version verwendet. Es ist eine Falle, wenn dies nicht der Fall ist.

Angenommen, Sie sind zwei Hauptversionen zurück. Sie fügen die neuesten Kerndateien ein und haben noch nichts repariert. Was Sie getan haben, ist, ein Hauptversions-Upgrade plus eine Datenbank-Schemaänderung auf eine instabile Website mitten im Notfall ohne Tests zu erzwingen.

Stellen Sie die Version wieder her, die Sie gerade verwenden. Führen Sie später absichtlich ein Upgrade durch, sobald die Website wieder stabil ist.

Hier erfahren Sie, wie Sie Ihre Versionsnummer finden:

• Vom Dashboard aus: Gehen Sie zu Dashboard » Updates. Die von Ihnen verwendete Version wird oben auf dem Bildschirm angezeigt.
• Über FTP: Öffnen Sie wp-includes/version.php und lesen Sie die Zeile $wp_version nahe dem Anfang der Datei. Dies funktioniert, wenn nichts anderes geht.
• Über SSH: Führen Sie wp core version aus, und die Nummer wird ausgegeben.

Laden Sie nun diesen genauen Build aus dem WordPress Release-Archiv herunter, anstatt von der Hauptdownloadseite. Die Hauptseite liefert nur die aktuelle Version.

Der Download der WordPress-Core-Dateien ist ein einzelnes Zip-Archiv, das wp-admin, wp-includes, wp-content und die losen Stammverzeichnisse enthält. Stimmen Sie die vollständige Versionszeichenfolge ab, nicht nur die Hauptnummer. Ein Punkt-Release-Unterschied bedeutet immer noch einen anderen Dateisatz.

Wenn Sie den WP-CLI-Weg wählen, können Sie den Download komplett überspringen. Der Befehl in Methode 2 unten liest Ihre Version und lädt die passenden Dateien in einem einzigen Schritt herunter.

Sie sind bereit für Schritt 4, wenn Sie ein WordPress-Zip auf Ihrem Computer haben, das Ihrer Website entspricht, oder ein Terminal geöffnet und bereit haben.

Schritt 4: Ersetzen Sie die Kerndateien

Dies ist der Schritt, bei dem die beschädigten Dateien entfernt und saubere Dateien eingefügt werden. Es gibt drei Möglichkeiten, dies zu tun, und alle ersetzen die Programmdateien von WordPress durch verifizierte Kopien von WordPress.org, während Ihre Inhalte und Einstellungen unverändert bleiben.

Welche Sie verwenden, hängt vom Zugriff ab, den Sie haben:

• Methode 1: Der Dashboard-Button. Verwenden Sie diese, wenn Sie sich noch bei WordPress anmelden können. Sie ist mit Abstand die schnellste.
• Methode 2: WP-CLI. Verwenden Sie diese, wenn Sie SSH haben. Sie ist die präziseste und die einzige, die Ihre Version im selben Befehl festlegt.
• Methode 3: Manuelles FTP. Verwenden Sie diese, wenn Sie keines von beiden haben. Sie funktioniert auf jedem Host und hat die meisten Möglichkeiten, schiefzugehen.

Methode 1: Verwenden Sie die Schaltfläche "Neu installieren" im Dashboard

Wenn wp-admin noch geladen wird, beginnen Sie hier. Es ist der schnellste Weg, WordPress-Core neu zu installieren, und Sie müssen keine einzige Datei anfassen.

Gehen Sie zu Dashboard » Updates. Wenn Sie bereits auf der aktuellen Version sind, teilt Ihnen WordPress dies mit und bietet an, diese Version für Sie neu zu installieren, mit einem Button Version X.X.X neu installieren.

Klicken Sie darauf. WordPress lädt das Update herunter, entpackt das Core-Update, überprüft die entpackten Dateien, installiert die neueste Version und aktualisiert die Datenbank. Es schließt mit einer Erfolgsmeldung auf demselben Bildschirm ab.

Kennen Sie eine Einschränkung, bevor Sie beginnen. Dies installiert die Version neu, auf der WordPress Sie haben sollte, daher kann es Sie nicht zurücksetzen. Wenn ein schlechtes Update Ihre Website beschädigt hat, wird dieser Button es nicht rückgängig machen.

Es überschreibt auch Dateien, anstatt Ordner zu löschen, und das tut Methode 2 auch. Alles, was ein Angreifer in wp-admin oder wp-includes hinzugefügt hat, bleibt erhalten. Wenn Sie einen Hack bereinigen, verwenden Sie Methode 3 oder bestätigen Sie anschließend mit einem Checksummen-Scan, dass nichts Zusätzliches übrig geblieben ist.

Einige Hosts unterbrechen den Prozess mit einem Dialogfeld Verbindungsinformationen, das nach FTP-Anmeldeinformationen fragt. Das ist ein Problem mit dem Dateibesitz, und der Abschnitt zur Fehlerbehebung unten behandelt die Lösung.

Methode 2: Verwenden Sie WP-CLI

WP-CLI ist mein Werkzeug der Wahl, wann immer ich Terminalzugriff habe. Verbinden Sie sich über SSH, wechseln Sie in Ihr WordPress-Verzeichnis und führen Sie aus:

wp core download --version=$(wp core version) --force --skip-content

Hier ist, was jedes Teil tut:

• --version=$(wp core version) liest die Version, die Ihre Website verwendet, und lädt diese exakte Version herunter.
• --force überschreibt die vorhandenen Dateien. Ohne diese weigert sich WP-CLI, ein Verzeichnis anzufassen, das bereits WordPress enthält.
• --skip-content lässt wp-content komplett aus dem Download aus, sodass Ihre Themes, Plugins und Uploads niemals überschrieben werden.

Greifen Sie hier nicht zu wp core install, auch wenn der Name richtig klingt. Dieser Befehl führt die WordPress-Installationsroutine auf einer neuen Website aus und ist das falsche Werkzeug für eine bereits vorhandene Website.

Bevor Sie Enter drücken, sollten Sie wissen, dass --force keine Bestätigung verlangt. Wenn jemand absichtlich eine Kerndatei auf dieser Website bearbeitet hat, verschwindet diese Bearbeitung in dem Moment, in dem der Befehl ausgeführt wird. Normalerweise ist das der Sinn der Sache, aber fragen Sie denjenigen, der die Website erstellt hat, wenn Sie sich nicht sicher sind.

Bestätigen Sie dann das Ergebnis:

wp core verify-checksums

Ein sauberer Durchlauf bedeutet, dass die Dateihälfte Ihres Problems gelöst ist.

Methode 3: Ersetzen Sie die Dateien manuell über FTP

Wenn Sie nicht auf das Dashboard zugreifen können und keinen SSH-Zugang haben, erledigen Sie dieselbe Aufgabe von Hand: Nehmen Sie die beiden Kernordner vom Server und ersetzen Sie sie durch neue.

Keine der einzelnen Schritte ist schwierig. Die Reihenfolge schützt die Dateien, die Sie behalten müssen, daher lohnt es sich, sie in der richtigen Reihenfolge zu befolgen.

1. Deaktivieren Sie Ihre Plugins, wenn Sie noch auf das Dashboard zugreifen können. Überspringen Sie diesen Schritt, wenn Sie es nicht können. Dies ist eine Vorsichtsmaßnahme, keine Anforderung.
2. Entpacken Sie den WordPress-Download auf Ihrem Computer. Sie sehen wp-admin, wp-includes, wp-content und eine Handvoll loser Dateien.
3. Löschen Sie wp-admin und wp-includes auf dem Server. Beide Ordner, vollständig. Lassen Sie alles andere genau dort, wo es ist.
4. Laden Sie die neuen wp-admin und wp-includes aus Ihrer entpackten Kopie an denselben Ort hoch.
5. Laden Sie die losen Root-Dateien aus dem neuen Build hoch und überschreiben Sie die alten. Löschen Sie nicht zuerst Ihren Root-Ordner. Sie würden wp-config.php und .htaccess damit mitnehmen.
6. Kopieren Sie die Dateien aus dem neuen wp-content in Ihr bestehendes wp-content. Kopieren Sie hinein. Ersetzen Sie es niemals.
7. Bestätigen Sie, dass wp-config.php und .htaccess noch in Ihrem Root-Verzeichnis vorhanden sind. Wenn eine davon fehlt, laden Sie die zuvor gespeicherte Kopie hoch.

Schritt 3 in dieser Liste ist der Punkt, an dem die Leute zögern, da das Löschen riskanter erscheint als das Überschreiben. Es ist das Gegenteil.

Das Überschreiben ersetzt nur Dateien, die in beiden Kopien vorhanden sind. Alles, was ein Angreifer in wp-admin oder wp-includes abgelegt hat, ist kein Teil des offiziellen Builds, daher überschreibt nichts davon, und es durchläuft Ihre gesamte Bereinigung unberührt. Das vorherige Löschen der Ordner macht dies zu einer echten Lösung und nicht nur zu einer kosmetischen.

Setzen Sie auch Ihre Erwartungen an die Zeit. wp-includes allein enthält über tausend Dateien, und FTP bewegt sie einzeln. Zwanzig Minuten sind bei einer langsamen Verbindung normal, und Übertragungsabbrüche können vorkommen.

Wenn der Upload weiterhin fehlschlägt, senden Sie die ZIP-Datei als einzelne Datei an Ihren Server und entpacken Sie sie dort mit dem Dateimanager Ihres Hosters. Eine große Übertragung ist weitaus zuverlässiger als tausend kleine.

Sie haben diesen Schritt abgeschlossen, wenn Ihre Ordnerstruktur mit der neuen Kopie übereinstimmt, wp-config.php intakt ist und die Website geladen wird, auch wenn Sie mit einer Aufforderung zur Datenbankaktualisierung begrüßt werden.

Schritt 5: Führen Sie das Datenbank-Upgrade durch und löschen Sie die Reste

Ihre Dateien sind jetzt sauber, aber WordPress befindet sich möglicherweise noch in dem Zustand, in dem das fehlgeschlagene Update es hinterlassen hat. Drei kleine Bereinigungen erledigen den Rest.

Beginnen Sie mit dem Besuch von /wp-admin. Möglicherweise werden Sie aufgefordert, sich erneut anzumelden, was normal ist.

Wenn WordPress erkennt, dass Ihre Datenbank mit dem Code Schritt halten muss, wird ein Bildschirm Datenbank-Update erforderlich mit einer Schaltfläche WordPress-Datenbank aktualisieren angezeigt. Klicken Sie darauf und lassen Sie es laufen.

Tun Sie dies sofort, denn bis dahin läuft Ihre Website mit neuem Code gegen ein altes Schema.

Suchen Sie als Nächstes in Ihrem Stammverzeichnis nach einer Datei namens .maintenance und löschen Sie sie, falls sie vorhanden ist. WordPress erstellt diese Datei zu Beginn eines Updates und entfernt sie, wenn das Update abgeschlossen ist. Wenn ein Update auf halbem Weg fehlschlägt, bleibt die Datei zurück und Besucher sehen die Wartungsnachricht.

Es ist eine versteckte Datei, daher wird sie in Ihrer Dateiliste nicht angezeigt, bis Sie versteckte Dateien aktivieren. In FileZilla ist dies Server » Versteckte Dateien erzwingen, und in den meisten Host-Dateimanagern ist es eine Checkbox Versteckte Dateien anzeigen in den Einstellungen.

Leeren Sie dann jeden Cache, den Sie haben: Ihr Caching-Plugin, den Server-Cache Ihres Hosts, Ihr CDN und Ihren eigenen Browser. Überspringen Sie dies, und Sie können 20 Minuten damit verbringen, eine Seite zu debuggen, die bereits behoben wurde.

Reaktivieren Sie Ihre Plugins, wenn Sie sie während Methode 3 deaktiviert haben.

Hier sind Sie fertig, wenn das Dashboard geladen wird, die Update-Aufforderung verschwunden ist und Ihr Frontend gerendert wird.

Schritt 6: Überprüfen Sie, ob die Wiederherstellung funktioniert hat

Eine Website, die lädt, ist nicht dasselbe wie eine Website, die behoben ist. Bevor Sie den Tab schließen, gehen Sie diese Liste durch.

Hier ist, was Sie überprüfen sollten:

• Führen Sie wp core verify-checksums erneut aus. Ein fehlerfreier Durchlauf ist der einzige definitive Beweis dafür, dass Ihre Kerndateien mit der offiziellen Version übereinstimmen.
• Laden Sie Ihr Frontend als abgemeldeter Benutzer in einem privaten Browsing-Fenster. Ansichten für angemeldete Benutzer verbergen Caching-Probleme und Berechtigungsfehler.
• Klicken Sie sich durch die wichtigen Seiten. Ihre Homepage, ein einzelner Beitrag, ein Kategorie-Archiv, die Anmeldeseite und jedes Formular oder jeder Checkout, auf den Sie angewiesen sind.
• Speichern Sie Ihre Permalinks erneut. Gehen Sie zu Einstellungen » Permalinks und klicken Sie auf Änderungen speichern, ohne etwas zu ändern. Dies generiert Ihre Rewrite-Regeln neu, was der übliche Grund dafür ist, dass Beiträge nach einem Dateiaustausch 404er zurückgeben.
• Bestätigen Sie Ihre URLs. Überprüfen Sie unter Einstellungen » Allgemein, ob WordPress-Adresse (URL) und Website-Adresse (URL) genau das anzeigen, was sie zuvor getan haben.
• Lesen Sie Ihr Fehlerprotokoll. Alles Neue darin ist es wert, jetzt behandelt zu werden, solange Sie sich noch erinnern, was Sie geändert haben.

Machen Sie dann noch ein Backup. Ihre Website befindet sich in diesem genauen Moment in einem bekannten guten Zustand, und dieser Zustand ist es wert, festgehalten zu werden. Es ist eine weitaus nützlichere Kopie als die Notfallkopie aus Schritt 2.

Was tun, wenn das Ersetzen von Kerndateien das Problem nicht behebt?

Manchmal arbeiten Sie alle Schritte durch, die Prüfsummen sind sauber, und die Website ist immer noch fehlerhaft. Wenn das passiert, waren die beschädigten Kerndateien ein Symptom und nicht die Ursache.

Drei Szenarien erklären die meisten dieser Fälle:

• Die Website wurde gehackt. Das Ersetzen von Kerncodedateien entfernt nur den injizierten Code aus den Kerncodedateien und nichts anderes. Eine Hintertür in wp-content/uploads, eine modifizierte Theme-Funktionsdatei oder etwas, das in mu-plugins versteckt ist, überlebt dies alles. Das deutlichste Anzeichen sind PHP-Dateien in Ihrem Upload-Ordner, in dem sich nur Medien befinden sollten.
• Die Datenbank wurde ebenfalls beschädigt. Ihre Dateien sind in Ordnung und Ihr Inhalt auch. Spam-Links, die in die Posts-Tabelle injiziert wurden, eine umgeschriebene siteurl in der Options-Tabelle und unbekannte Admin-Konten überleben alle eine Kernwiederherstellung.
• Prüfsummen sind in Ordnung und die Website gibt immer noch Fehler aus. Das deutet auf ein Plugin, ein Theme oder eine Inkompatibilität der PHP-Version hin. Schritt 1 hat Sie auf den richtigen Weg gebracht; die Kerncodedateien waren nie das Problem.

In allen drei Fällen ist die Wiederherstellung der gesamten Website aus einem Backup, dem Sie vertrauen, besser, als sie Datei für Datei zu untersuchen. Sie hören auf zu raten, was sauber ist.

Finden Sie in Duplicator Pro ein Backup von vor Beginn der Probleme und stellen Sie es wieder her.

Wenn dieses Backup in Google Drive, Dropbox oder einem anderen verbundenen Speicherort liegt, können Sie es direkt aus WordPress wiederherstellen, ohne zuerst das Archiv herunterladen und erneut hochladen zu müssen.

Wenn WordPress überhaupt nicht geladen wird, laden Sie das Backup, mit dem Sie begonnen haben, in Ihr Stammverzeichnis hoch. Starten Sie den Installer von Duplicator mit einer URL wie: https://your-domain/installer.php

Eine Wiederherstellung setzt Ihre Website auf den Zeitpunkt zurück, zu dem das Backup erstellt wurde. Alles, was seitdem veröffentlicht oder bestellt wurde, geht damit verloren. Auf einer kompromittierten Website ist dies normalerweise die richtige Entscheidung, da eine teilweise Bereinigung, die eine Hintertür übersieht, Sie in einer Woche wieder hierher zurückbringt.

Duplicator scannt nicht nach Malware und entfernt sie auch nicht. Es liefert Ihnen eine saubere Kopie einer funktionierenden Website. Kombinieren Sie es mit einem Sicherheits-Scanner, wenn Sie es mit einer aktiven Infektion zu tun haben.

Für den manuellen Weg deckt Manuelle Wiederherstellung Ihrer WordPress-Website die Wiederherstellung von Dateien und Datenbanken von Hand ab, und Wiederherstellung einer Website nur mit einem Datenbank-Backup behandelt, was zu tun ist, wenn die Datenbank alles ist, was Ihnen noch übrig geblieben ist.

Fehlerbehebung: Häufige Fehler nach der Wiederherstellung von Kerndateien

Dies sind die Fehler, die am häufigsten nach einem Austausch von Kerncodedateien auftreten. Arbeiten Sie von dem Symptom aus, das Sie gerade betrachten.

Warum steht auf meiner Website „Kurzzeitig wegen geplanter Wartungsarbeiten nicht verfügbar“?

Sie sehen eine einfache weiße Seite mit einer einzigen Textzeile, die nicht verschwindet.

WordPress schreibt eine Datei namens .maintenance in Ihr Stammverzeichnis, wenn eine Aktualisierung beginnt, und löscht sie, wenn die Aktualisierung abgeschlossen ist. Wenn die Aktualisierung dazwischen fehlgeschlagen ist, befindet sich diese Datei immer noch dort, und WordPress weiß nicht, dass der Vorgang nie abgeschlossen wurde. WordPress ignoriert die Datei nach 10 Minuten, aber eine fehlgeschlagene Aktualisierung kann Ihre Website in der Zwischenzeit halb aktualisiert lassen.

Löschen Sie .maintenance über FTP aus Ihrem Stammverzeichnis, indem Sie versteckte Dateien anzeigen. Über SSH deaktiviert wp maintenance-mode deactivate dasselbe. Ihre Website ist wieder verfügbar, sobald die Datei gelöscht ist.

Warum werde ich nach meinen FTP-Verbindungsinformationen gefragt?

Sie klicken auf Version X.X.X neu installieren und WordPress öffnet ein Dialogfeld Verbindungsinformationen, das nach einem Hostnamen, Benutzernamen und Passwort fragt. Dies ist ein Problem mit dem Dateibesitz.

WordPress schreibt Dateien direkt nur, wenn sie demselben Benutzer gehören, unter dem der Webserver läuft. Wenn nicht, fragt es nach FTP-Zugangsdaten, damit es sie auf andere Weise schreiben kann.

Geben Sie die Zugangsdaten für das FTP-Konto ein, dem Ihre WordPress-Dateien gehören, und es wird fortgesetzt. Wenn Sie diese nicht haben, bitten Sie Ihren Hoster, den Besitz zu korrigieren, was die eigentliche Lösung ist.

Sie finden auch online Ratschläge, wie Sie define('FS_METHOD', 'direct'); zu wp-config.php hinzufügen können. Es funktioniert manchmal, aber es umgeht das Symptom und kann später auf eine Weise fehlschlagen, die schwieriger zu diagnostizieren ist als der Dialog.

Warum erhalte ich einen weißen Bildschirm, nachdem ich Kerndateien ersetzt habe?

Es lädt überhaupt nichts, weder Frontend noch Admin, und es gibt keinen Fehlertest, mit dem man arbeiten kann. Drei Ursachen decken fast alle diese Fälle ab: eine unvollständig abgeschlossene FTP-Übertragung, Dateiberechtigungen, die beim Hochladen falsch waren, oder ein PHP-Fatal-Fehler, der unterdrückt wird.

Laden Sie zuerst wp-includes erneut hoch, da dies der größte Ordner ist und am wahrscheinlichsten Dateien verloren gegangen sind. Überprüfen Sie dann Ihre Berechtigungen, die für Dateien 644 und für Ordner 755 sein sollten.

Wenn der Bildschirm immer noch leer ist, fügen Sie define('WP_DEBUG', true); und define('WP_DEBUG_LOG', true); zu wp-config.php hinzu und lesen Sie wp-content/debug.log. Das verwandelt einen weißen Bildschirm in einen Dateinamen und eine Zeilennummer.

Warum schlagen Prüfsummen nach einer sauberen Neuinstallation immer noch fehl?

Sie haben alles ersetzt und wp core verify-checksums wirft immer noch Warnungen aus. Es sind normalerweise drei Dinge: readme.html wird markiert, weil Ihr Hoster es modifiziert oder entfernt, der Befehl hat die falsche Sprache für Ihre Installation gewählt, oder etwas in diesen Ordnern gehört dort wirklich nicht hin.

Wenn jede Datei markiert wird, führen Sie sie erneut mit Ihrem Gebietsschema aus (z. B. wp core verify-checksums --locale=fr_FR) und sehen Sie, was übrig bleibt. Eine Warnung „Datei sollte nicht existieren“ bedeutet, dass sich etwas Zusätzliches in einem Kernordner befindet und Überschreiben es nicht entfernt. Löschen Sie wp-admin und wp-includes vollständig und laden Sie frische Kopien hoch, was der Unterschied ist, den Methode 3 macht.

Warum meldet WordPress, dass ein Update bereits läuft?

Sie versuchen, neu zu installieren und erhalten die Meldung „Ein weiterer Update wird gerade durchgeführt“. WordPress setzt einen Sperre in Ihrer Options-Tabelle, wenn ein Core-Update beginnt, damit nicht zwei Updates gleichzeitig laufen können. Ein abgestürztes Update hinterlässt diese Sperre, ohne dass etwas sie löschen kann.

Die Sperre läuft nach 15 Minuten von selbst ab, sodass Warten Sie nichts außer Zeit kostet. Um sie jetzt zu löschen, führen Sie wp option delete core_updater.lock aus oder öffnen Sie Ihre Options-Tabelle in phpMyAdmin, suchen Sie die Zeile core_updater.lock und löschen Sie sie.

Nichts funktioniert mehr: Was nun?

Sie haben die Liste abgearbeitet und die Website ist immer noch nicht erreichbar. An diesem Punkt hören Sie auf zu reparieren und fangen Sie an wiederherzustellen.

Gehen Sie zurück zu dem Backup, das Sie in Schritt 2 erstellt haben. Wenn Sie immer noch auf das Dashboard zugreifen können, führen Sie eine Ein-Klick-Wiederherstellung über Duplicator Pro » Backups durch. Wenn nicht, laden Sie das Archiv und das Installationsprogramm erneut in Ihr Stammverzeichnis hoch und starten Sie das Installationsprogramm in Ihrem Browser, das ohne eine funktionierende WordPress-Installation dahinter funktioniert.

Wenn Sie kein Backup haben, wenden Sie sich an Ihren Hoster und fragen Sie nach einem serverseitigen Snapshot. Die meisten Hoster führen tägliche Backups in einem rollierenden Fenster, selbst bei Shared-Tarifen, und der Support kann eines für Sie wiederherstellen.

Häufig gestellte Fragen (FAQs)

Saubere Kerndateien sind die Basis: Hier erfahren Sie, was als Nächstes zu tun ist

Sie haben die Programmdateien von WordPress durch verifizierte Kopien ersetzt und dies mit einem Checksummen-Durchlauf bestätigt. Dieser Durchlauf ist wichtiger, als dass die Website einfach wieder geladen wird. Eine Website kann perfekt funktionieren, auch wenn eine geänderte Kerndatei heimlich den Code eines anderen bei jeder Anfrage ausführt. Deshalb kam der Diagnoseschritt vor allem anderen.

Drei Gewohnheiten bewahren Sie von nun an davor.

• Planen Sie Ihre Backups, anstatt sie zu erstellen, wenn Sie zufällig daran denken.
• Erstellen Sie nach jedem erfolgreichen Update ein frisches Backup, damit Ihr letzter bekannter guter Zustand nie mehr als eine Wiederherstellung entfernt ist.
• Führen Sie wp core verify-checksums als routinemäßige monatliche Überprüfung aus, anstatt als Notfallmaßnahme, denn eine geänderte Kerndatei, die Sie bei einer Gesundheitsprüfung entdecken, ist ein weitaus kleineres Problem als eine, die Sie entdecken, wenn die Website ausfällt.

Eine weitere Sache, die sich lohnt, während Sie bereits in wp-config.php sind. Fügen Sie define('DISALLOW_FILE_EDIT', true); hinzu, um die integrierten Theme- und Plugin-Editoren zu deaktivieren. Dies schließt den einfachsten Weg für jeden mit Admin-Zugriff, eine Datei von innerhalb des Dashboards zu ändern. Fügen Sie dann eine kleine .htaccess-Datei in wp-content/uploads hinzu, die PHP daran hindert, dort ausgeführt zu werden:

<Files *.php>

Require all denied

</Files>

Die zweite davon ist Apache 2.4-Syntax. Unter nginx möchten Sie also den entsprechenden location-Block in Ihrer Serverkonfiguration. Zusammen schließen sie die beiden Türen, die die meisten Leute überhaupt erst in diese Lage bringen, und keine davon dauert länger als eine Minute.

Hören Sie auf, WordPress-Websites von Hand zu reparieren

Das manuelle Ersetzen von Kerndateien funktioniert. Es kostet Sie auch einen Nachmittag und hilft nur, wenn Sie das Problem erkennen, bevor es sich ausbreitet. Ein aktuelles Backup und eine Ein-Klick-Wiederherstellung verwandeln diese lange Debugging-Sitzung in zwei Minuten.

Duplicator Pro ist das, worauf über 1,5 Millionen aktive Benutzer für geplante Backups, Ein-Klick-Wiederherstellungen direkt aus dem Cloud-Speicher und eine Notfall-URL verlassen, die auch dann funktioniert, wenn WordPress nicht geladen wird. Jeder bezahlte Plan beinhaltet eine 14-tägige Rückerstattung ohne Fragen.

Wenn dieses Tutorial hilfreich war, sind diese Anleitungen auch lesenswert.

• So stellen Sie WordPress aus einem Backup wieder her (in weniger als 5 Minuten)
• So stellen Sie Ihre WordPress-Website manuell wieder her
• So stellen Sie eine Website mit nur einem Datenbank-Backup wieder her
• So stufen Sie Ihre WordPress-Version herab und machen fehlerhafte Updates rückgängig
• So stellen Sie Ihre WordPress-Website aus einem Google Cloud-Backup wieder her
• So stellen Sie eine WordPress-Website auf ein früheres Datum ohne Backup wieder her