[ad_1]
Es ist nicht unüblich, dass wir hier in Threads Ergänzungen und Anmerkungen posten, auch wenn bereits eine gute Antwort gegeben wurde. Ich möchte vorab darauf hinweisen, dass meine Antwort nur eine Ergänzung zur Antwort von Torsten sein soll.
WordPress verwendete eine Konfigurationsdatei wp-config.php, in der verschiedene Konstanten mit der PHP-Funktion define() definiert werden. Dazu gehören auch Zugangsdaten zur MySQL-Datenbank, die genutzt wird, um Beiträge und Seiten, aber auch alle Einstellungen im Customizer, die aktuelle Auswahl an Themes, Plugins usw. zu speichern.
Da jemand mit Zugriff auf den Server mit diesen Zugangsdaten beliebige Änderungen an der Datenbank vornehmen und so z.B. einen anderen Administrator anlegen kann, ist die wp-config.php besonders schützenswert. Eine (umstrittene) Empfehlung ist deshalb, die wp-config.php aus dem Webstammverzeichnis in ein nächsthöher gelegenes, für Webseitenbesucher nicht erreichtbares Verzeichnis zu verschieben.
Wenn keine Cache-Lösung verwendet wird, liest WordPress bei jedem Webseitenaufruf (auch im Backend) die Zugangsdaten erneut ein und prüft dabei zunächst, ob eine wp-config.php im Verzeichnis mit den WordPress-Dateien vorhanden ist oder ob die Datei im nächsthöher gelegenen Verzeichnis zu finden ist. Dies setzt voraus, dass nicht durch eine Serverkonfiguration die Ausführung von PHP-Dateien außerhalb des Webstammverzeichnisses gesperrt ist. In dem Fall können die Zugangsdaten nicht als Konstante verwendet werden und es kommt zu Fehlermeldungen. Ein einfacher Lösungsansatz wäre, entweder die Beschränkung der Skript-Ausführung aufzuheben bzw. anzupassen oder die wp-config.php in das Webstamm-Verzeichnis zu verschieben.
Sollte die Datei verloren gegangen sein, lässt sie sich schnell wiederherstellen. Dabei kannst du die Datei wp-config-sample.php als Muster in wp-config.php kopieren und die Zugangsdaten in den ersten Zeilen der Datei wie in den Kommentaren beschrieben einfügen. Achte auch auf das Tabellen-Präfix (eine Vorsilbe der Datenbanktabellen wie z.B. wp_), das bei der Installation willkürlich gewählt werden kann und dann entsprechend in der Datenbank auftauchen muss.
Taucht anschließend ein leerer Bildschirm auf, kann es entweder daran liegen, dass mit den Zugangsdaten nicht auf die Daten zugegriffen werden konnte, ein Programmierfehler gemacht wurde oder die Datei mit einem ungeeigneten Editor erstellt wurde, der die Datei nicht in der richtigen Zeichencodierung speichert. Dass du statt Fehlermeldungen nur einen leeren Bildschirm siehst, soll deinem eigenen Schutz dienen – Angreifer sollen mögliche Sicherheitslücken, die sich aus Programmierfehler ergeben könnten, nicht auch noch präsentiert bekommen. Mit der wp-config.php-Konstante define( 'WP_DEBUG', true ); kannst du allerdings Fehlermeldungen auch ausgeben, die sonst nur im Error-Log des Servers stehen.