Hast Du nur den Dokumentenstamm im CCP geändert oder auch alle Dateien dorthin verschoben? Sprich: Ist der Ordner leer?
Ansonsten kontrolliere einmal die Rechte des genannten Ordners. Diese sollten standardmäßig (0)755 sein, also jeder darf lesen/ausführen, aber nur der Besitzer darf schreiben.
Ich merke, dass Ihr ziemlich vom Fach seid
Was leider trotzdem nicht heißt, dass man sich mit Wordpress im Detail auskennt. Ist jedenfalls bei mir so 
Ich nutze es nicht bzw. habe es noch nie verwendet und ich administriere auch keine Systeme, auf denen das läuft.
Im Endeffekt gab ich dann die Daten ein, doch die Seite war dann "nackt" bzw eine Neuinstallation von Wordpress.
Diesen Teil habe ich wohl überlesen. Ich weiß nicht, wie der Wordpress-Installer genau arbeitet, aber im schlimmsten Fall hast Du Dir damit die Datenbank-Inhalte gelöscht. Aber das hast Du eh schon festgestellt…
Im Moment funktioniert die Seite gar nicht, doch ich denke weil eben die Datenbank komplett überspielt wurde bzw. leer ist. Sehe ich auch so in phpmyadmin.
Beim Thema Restore des Backups bin ich mangels Webhostingtarif mit Backupfunktion keine wirkliche Hilfe, da können andere User besser helfen.
Zu Deinen restlichen Fragen:
Passt das zusammen, dass wenn open_basedir auf DOCROOT stand, dass Wordpress eine Neuinstallation verpasst ?
Wenn in der originalen wp-config.php nur ein include() für den neuen Pfad steht (siehe nächster Absatz), dann passt das zusammen. Die Konfigurationsdatei existiert in diesem Fall zwar, aber da der Include-Aufruf aufgrund des open_basedir Konflikts stillschweigend fehlschlägt (im Gegensatz zur Require-Anweisung), sind die benötigten Konfigurationsvariablen leer und Wordpress muss davon ausgehen, dass es noch gar nicht installiert wurde.
Sprich ich erstelle einfach eine neue Installation von Wordpress etc. ... packe dann die wp-config in den Vorordner. Stelle dann von 7.3. auf 7.4., wähle dann doch WEBSPACEROOT anstatt DOCROOT.
Aus technischer Sicht würde ich das Verschieben bleiben lassen, das bringt fast keinen realen Sicherheitsgewinn.
Ich nehme einmal an, Du hast das damals wie hier oder hier beschrieben gelöst? Das ist leider ziemlich unschön, alleine schon deshalb, weil include() statt require() verwendet wird. Hier gibt es offenbar ein besseres Beispiel, aber auch bei dem gilt, dass der Sicherheitsgewinn minimal ist.
Hintergrund: Wer die originale wp-config.php aufrufen kann, ruft damit auch die eingebundene Datei auf. Das ist soweit noch nicht schlimm, da sie als PHP-Script ausgeführt wird und die Zugangsdaten nicht lesbar sind. Kritisch wird es erst, wenn der PHP-Interpreter aus irgendeinem Grund nicht richtig konfiguriert ist und gar nicht zur Anwendung kommt. Dann würde das Verschieben der Zugangsdaten eine Ebene höher (somit außerhalb des Dokumentenstamms) etwas bringen. Das habe ich in der freien Wildbahn (nicht bei netcup!) durchaus schon gesehen, dass durch solche (temporären) Konfigurationsfehler Datenbanken kompromittiert wurden. Die Wahrscheinlichkeit dafür ist bei einem Webhostingtarif allerdings sehr gering. Das ist auch das einzige Szenario, für das die ganze Verschiebe-Aktion etwas bringen würde. Jetzt kommt das große ABER…
Meiner Meinung nach gibt es dafür eine bessere Lösung: Den HTTP-Zugriff auf die originale wp-config.php kann und sollte man lieber über eine .htaccess-Datei verbieten. Das ist wesentlich effektiver und sinnvoller. Denn…
Man schwächt damit die Sicherheit erst recht. Wenn man den open_basedir auf WEBSPACEROOT stellt (was bei Deiner Variante notwendig ist), hat damit auch jedes PHP-Script, und somit ein erfolgreicher Angreifer, Zugriff auf Deinen ganzen Webspace und nicht nur auf den Dokumentenstamm der jeweiligen (Sub-) Domain!
(Dass man das über exec() u.ä. Funktionen trotzdem aushebeln kann, ist eine andere Geschichte und würde den Rahmen des bereits jetzt viel zu langen Beitrags sprengen. Um das gänzlich zu vermeiden müsste man disable_functions anpassen [lassen], was derzeit nur über den Support geht.)
Und noch einmal die Nachfrage : Sind die Dateiattribute wichtig, wenn ich die php-Version umstelle ?
Ich wüsste nicht, welchen Zusammenhang es da geben sollte. Also NEIN. 
habs lange nicht mehr ausprobiert, aber wie performant läuft nextcloud mittlerweile auf den webhosting paketen von netcup?
Einwandfrei! 
Auf einem kaum ausgelasteten ncLabs-Webhosting-Server 
Lud3r Wähle einmal den open_basedir mit WEBSPACEROOT und warte einige Minuten. Die Variante mit DOCROOT kann nicht funktionieren, wenn die Konfigurationsdatei außerhalb des Dokumentenstamms liegt.
Ich bin recht fest der Meinung, dass ich es manuell installiert habe (ist ja ein paar Jahre her) und nicht über das Interface von Plesk. Mit manuell ist gemeint, die notwenigen Datein per SFTP hochzuladen, aufzurufen und dann zu konfigurieren ? Dann habe ich das sehr wahrscheinlich so gemacht.
Ja, genau das habe ich gemeint.
Das Toolkit in Plesk für Wordpress ist mir gänzlich unbekannt. WIrd das ggf. automatisch verwendet ?
Ich hoffe, dass das nicht der Fall ist.
Die wp-config ist vorhanden. Sieht normal aus. Diese liegt aus Sicherheitsgründen nicht im Hauptverzeichnis, sondern einen Ordner davor.
Ebenso habe ich den content-Ordner etc aus Sicherheitsgründen umbenannt. Kann das ein Problem darstellen ? Oder wie gesagt die Dateiattribute ? Weil die wp-config hat 400.
(Hervorhebung durch mich.)
Kann es sein, dass die PHP-Einstellung open_basedir durch die geänderte PHP-Version in Plesk ebenfalls geändert wurde? Überprüfe das bitte einmal. Wenn Wordpress die Konfigurationsvariablen nicht findet, wäre das Symptom einer Neuinstallation erklärbar.
Wie genau hast Du diesen anderen Pfad zur wp-config.php eigentlich hinterlegt? Ein include/require in der originalen wp-config.php oder hast Du die Pfade woanders angepasst? Oder handelt es sich um einen Symlink?
Generell würde ich schon davon ausgehen, dass Dein Problem damit zusammen hängt. Du kannst zum Test ja einmal die wp-config.php an ihrem korrekten Originalort platzieren, verschwindet der Fehler dann?
Ist das Müll?
Ohne Gewähr, nach einem schnellen Blick: Dank filter_var(…, FILTER_VALIDATE_EMAIL) ist es glücklicherweise nicht anfällig für eine Header-Injection, aber Du wirst damit wahrscheinlich früher oder später Probleme mit DMARC bekommen. Besser wäre es, wenn der From Header auf eine eigene Adresse gesetzt wird, zu dessen Versand der Webserver berechtigt ist. Die Absenderadresse kann man dann immer noch als Reply-To Header integrieren.
Statt diesem Teil:
if ($sendermail_antwort and isset($_POST[$name_von_emailfeld]) and filter_var($_POST[$name_von_emailfeld], FILTER_VALIDATE_EMAIL)) {
$email_from = $_POST[$name_von_emailfeld];
}
$header="From: $email_from";Etwas in dieser Art:
$header="From: $email_from";
if ($sendermail_antwort and isset($_POST[$name_von_emailfeld]) and filter_var($_POST[$name_von_emailfeld], FILTER_VALIDATE_EMAIL)) {
$header .= "\nReply-To: " . $_POST[$name_von_emailfeld];
}Unabhängig davon wäre der Versand über SMTP (mit eigenen Zugangsdaten) wahrscheinlich zuverlässiger als mail() zu verwenden. PHPMailer wäre hierfür eine gute Wahl, aber das sprengt den Rahmen dieses Beitrags.
Darf man fragen, woher Du diese send_mail.php hast?
Hintergrund: Es kursieren (leider) noch immer relativ viele solcher Scripts im Internet, die absoluter Müll sind und ein offenes Scheunentor für den Versand von Spam an unbeteiligte Dritte darstellen. Als Laie ist es oftmals unmöglich diese winzigen enthaltenen Programmierfehler sofort zu erkennen.
Eine Neuinstallation sollte durch den Wechsel der PHP-Version definitiv nicht aufgelöst werden, das ist schon mal nicht normal und klingt komisch.
Hast Du Wordpress selbst (manuell) installiert oder wurde das durch Plesk automatisch installiert? Verwendest Du (unabhängig von der vorherigen Frage) das Wordpress Toolkit in Plesk?
Ich hatte auf meiner domain prestashop installiert und wieder deinstalliert, weil es mit den maileinstellungen nicht funktioniert hat und habe dann über netcup WordPress installiert und auch wieder deinstalliert. Seitdem bekomme ich […]
Und was ist jetzt "installiert", von welchem System ist diese .htaccess-Datei? Wenn kein Inhalt (und somit keine index.html oder index.php) existiert, ist ein 403er völlig normal, wenn keine Features wie Autoindex aktiv sind.
Tipp am Rande: Installiere solche Sachen immer manuell und nicht direkt über Plesk! Das ist wesentlich sorgenfreier.
War auf der Suche nach einer Empfehlung für einen externen Backup Storage und nicht nach der allgemeinen Frage wo man ein Backup hin machen sollte.
Naja, offiziell dürfen wir solche Empfehlungen hier auch gar nicht geben. 
Siehe: Nutzungsbedingungen » Verhaltensregeln (§ 3.1; zweiter Punkt)
Wäre ja toll, wenn auch mal jemand ein Feedback geben würde.
Ich verwende kein Wordpress und kenne mich damit nicht aus.
Besser so? 
Ja, wir haben gestern in der Tat einen Wechsel auf ein neues Ticketsystem vollzogen.
Darf man erfahren, was ihr nun statt OTRS verwendet?
Wobei ich mir die Antwort schon denken kann. Aber vielleicht beantworten die Header der nächsten Supportmail das sowieso von alleine.
SOGo wechselt den Besitzer.
Huh? Quelle? (Ich finde dazu gerade nichts.)
Ich bin übrigens schwer enttäuscht wieviel kriminelle Energie hier im Forum steckt
Die haben doch nur ihre Passwörter vergessen, passiert schon mal. Woran Du immer denkst...
Genauso wie dutzende TB an HDDs ausschließlich zum Sammeln von Linux-ISOs verwendet werden! Das weiß doch jedes Kind jeder Reddit-User.
Besser wäre ja nur "SQL: Ja", mit Alternativangebot "Wunsch-Datenkbanksoftware gegen Aufpreis".
Ich hätte bitte gerne MSSQL oder alternativ Oracle DB 
(Da wird spätestens Plesk etwas dagegen haben, weil es das nicht verwalten kann.)
Ja heißt eben: Ja, es ist eine MySQL-Version verfügbar. Hätte auch ohne Datenbank sein können.
Oder MariaDB 
Wir haben uns mit dem Produktmanagement abgestimmt und eine passende Änderung vorgenommen.
Kunde: Welche MySQL-Version ist beim Produkt verfügbar?
netcup: Ja
(SCNR)
Welcher Hosting-Typ ist denn bei den Problem-Domains in den Hosting-Einstellungen ausgewählt?
Das Vorkommen von "Weiterleitung" in der Fehlermeldung irritiert mich nämlich ein wenig.
