php update und Seite funktioniert nicht mehr

  • Gelöst lud3r

    (@lud3r)


    vor 2 Jahren, 3 Monaten

    Hallo zusammen,

    ich habe einen Webhostingtarif auf dem zwei Internetseiten per WordPress laufen.
    Weil mir jeweils nun angezeigt wird, dass die php Version 7.3.33 aktiv ist und lieber upgedatet werden soll, wollte ich dieses vornehmen.

    Seite A habe ich über Jahre aufgebaut und verwende ich entsprechend oft.
    Seite B ist eher für Spielerein.

    Ich nahm also Seite B, updatete WordPress und die wenigen Plugins und stellte von 7.3.33 auf 7.4. um (in Plesk in den php-Einstellungen)
    Ich wurde in den php Einstellungen noch dann darauf hingewiesen, dass ich eine Einstellung auswählen muss für open_basedir.
    Zur Wahl war DOCROOT (standard) und WEBSPACEROOT. Ich entschied mich für das erstere.
    Blöderweise nahm ich an, dass eine php Umstellung einfach so ginge.

    Wartete einige Minuten und dann rief die Seite auf und dann kam von WordPress ein Interface, dass ich Datenbankname, Datenbankbenutzer, Datenbank Server etc. angeben soll (es sah nicht nach Neuinstallation aus).
    Ich wunderte mich da schon.
    Ich stellte auf 7.3. zurück. Wartete ab.
    Das gleiche Bild, wieder wurden diese Daten abgefragt.
    Im Endeffekt gab ich dann die Daten ein, doch die Seite war dann „nackt“ bzw eine Neuinstallation von WordPress.
    Zu erwähnen ist (ggf ist das ein wichtiger Hinweis), dass ich die wp-config nicht im Hauptordner hatte, sondern im Ordner davor (aus Sicherheitsgründen, ebenso Dateiattribute „400“). Es wurde aber eine neue wp-config im Hauptordner erstellt.
    Ich wählte die Wiederherstellung von Webhostinganbieter, doch dann erschien das Bild, dass nun ich komplett neue Daten eingeben soll für eine Datenbank, Benutzer usw … also eine Neuinstallation. Ich kopierte daher die ursprüngliche wp-config in den Hauptordner.
    Die Seite B ist nun auch nicht mehr funktionell. Einfach ein weisser Bildschirm. Die Datenbank ist komplett leer.
    (dazu ist anzumerken, dass in den php einstellungen die open_basir Einstellung gespeichert wurde mit DOCROOT, obwohl wieder 7.3.33 aktiv ist)

    Fragen :

    1. Welche Bewandnis hat die open_basedir Einstellung oder ist das hier für gar nicht so wichtig ?
    2. Was müsste ich tun um „eigentlich“ ohne Probleme die php Version einfach zu wechseln ?
    3. Muss die wp-config immer zwingend für sowas im Hauptordner sein ?
    4. Andere Hinweise die ich hätte vorher kontrollieren sollen ?

    Mir ist bewusst, dass ich da unsicher bin. Ich habe viel ausprobiert, doch keinerlei Erfahrung bei Anwendung einer Wiederherstellung z.B. .
    Ebenso ist mir auch nicht klar was getan werden muss um einfach die php Version zu verändern.

    Vielen lieben Dank im Voraus an die Person/en die mir dabei versuchen weiterzuhelfen.

Ansicht von 8 Antworten – 1 bis 8 (von insgesamt 8)
  • Moderator Torsten Landsiedel

    (@zodiac1978)

    vor 2 Jahren, 3 Monaten

    Hi @lud3r

    zu 1 empfehle ich die PHP-Dokumentation:
    https://www.php.net/manual/de/ini.core.php#ini.open-basedir

    Ich hatte früher Sorge dies direkt zu lesen, weil ich dachte, dass mir das zu hoch sein würde. Aber mit der Zeit geht es und meisten habe ich so viel besser verstanden Warum genau etwas in einem Tutorial/Artikel so gemacht wurde, wie es gemacht wurde.

    zu 2: „Eigentlich“ sollte das recht einfach sein. Im besten Fall alles aktualisieren und nur umstellen. Wenn Themes/Plugins mit der neuen Version Probleme haben, sollte der Hoster erlauben zur alten Version zurückzukehren. (Fehlermeldung notieren!)

    zu 3: Nein, aber vielleicht gab es da bei deinem Hoster eine unglückliche Verkettung von open_basedir, anderer Ordner für die Config, die dazu geführt hat, was passiert ist …

    zu 4: Adhoc fällt mir da nichts ein, außer alles aktuell zu halten und nicht am Release-Tag auf die aktuellste PHP-Version zu wechseln …

    Zu deinem akuten Problem: Backup vorhanden? Hoster-Support schon angefragt?

    Gruß, Torsten

    Thread-Starter lud3r

    (@lud3r)

    vor 2 Jahren, 3 Monaten

    Vielen Dank für die Hinweise, Torsten 🙂

    Dann frage ich mal anders :
    Ich hatte für die Variable open_basedir zwei Möglichkeiten :

    1. {DOCROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions{:}{WEBSPACEROOT}{/}tmp (standard) – (diese wählte ich auch)
    2. {WEBSPACEOOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}sessions

    Das liest sich für mich wie Hieroglyphen, auch wenn ich mir gerade die php-Definition durchgelesen habe.

    Allgemein stellt sich mir die Frage, wann und wieso WordPress auf die Idee bzw. den Weg geht die Datenbankdaten abzufragen. Passiert das denn, wenn er keinen Zugriff auf die wp-config Datei bekommt ?
    Kann man es ggf. aus dem Winkel heraus betrachten ?
    Oder sollte ich mal in andere Configs von WOrdpress schauen und suchen, ob da ggf. bestimmte Dinge sind die diese Umstellung verhindern ?

    Ich habe ein komplettes Plesk-Backup, doch er kann komischerweise dieses nicht wiederherstellen. Doch … die Internetseite B liegt mir laaaange nicht so am Herzen, weswegen ich nicht einfach die Seite A umstellen möchte von der php-Version.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 2 Jahren, 3 Monaten

    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.

    Thread-Starter lud3r

    (@lud3r)

    vor 2 Jahren, 3 Monaten

    Ich merke schon, dass Ihr echt nen Plan habt im Gegensatz zu mir mit meinem gefährlichen Halbwissen 🙂

    Auch Dir vielen Dank für Deine ausführliche Erweiterung zu den geschriebenen Dingen von Torsten.

    Es erschließt sich mir bisher also einzig die Möglichkeit, dass wirklich die wp-config mit den gegeben Beschränkungen nicht eingelesen werden konnte.
    Meint Ihr, dass es nun einen Versuch wert sein sollte die wp-config in das Hauptverzeichnis zu legen (von Internetseite A) und dann die php-Version umzustellen ? Wenn ja, dann welche Einstellungsvariante für open_basedir ?
    Ich würde natürlich vorher ein backup machen von Datein und Datenbank.
    Mit den beiden Dingen sollte ich doch alles wiederherstellen können ? Egal was schief geht. Auch wenn ich das noch nie vorgenommen habe.

    Oder sollte ich vorher soetwas wie UpdraftClone nutzen um zu testen, ob meine Seite weiterhin funktioniert und kann ich da solche Dinge überhaupt austesten wie bei mir vermutet ? Also wenn die wp-config im Vorverzeichnis liegt.
    An den Dateiattributen von 400 kann es nicht liegen ?

    Das die Seite weiss ist … von Internetseite B.
    Liegt es nicht daran, dass Datenbank leer ist? 0 Tabellen etc.
    Achso, also füge ich diese Konstante nun mit WB_DEBUG in die wp-config ein und sehe dann die aktuellen Probleme … das werde ich testen.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 2 Jahren, 3 Monaten

    Meint Ihr, dass es nun einen Versuch wert sein sollte die wp-config in das Hauptverzeichnis zu legen (von Internetseite A) und dann die php-Version umzustellen ?

    Aufgepasst: wenn du auf einem Webspace zwei WordPress-Installationen (A und B) in zwei verschiedenen Verzeichnissen hast und kopierst die wp-config.php der einen Installation (A) in das Verzeichnis der anderen Installation (B), greift diese Installation (B) auf die Daten der ersten Installation (A) zu!

    Anders ausgedrückt: die wp-config.php enthält die Zugangsdaten zur Datenbank. Kopierst du die wp-config.php einer Installation, kopierst du damit auch deren Zugangsdaten! Deine zweite WordPress-Installation zeigt dann auf einmal die Inhalte der ersten Installation.

    Wenn ja, dann welche Einstellungsvariante für open_basedir ?

    Wenn du „WEBROOT“ nimmst, können auch nur PHP-Dateien im Web-Stammverzeichnis ausgeführt werden. Kein Problem, wenn du die wp-config.php in das WordPress-Verzeichnis ziehst.

    Ich würde natürlich vorher ein backup machen von Datein und Datenbank.

    Das ist immer eine gute Idee.

    Mit den beiden Dingen sollte ich doch alles wiederherstellen können ?

    Wenn die Backups funktionieren, ja.

    Thread-Starter lud3r

    (@lud3r)

    vor 2 Jahren, 3 Monaten

    Ich wollte nicht die wp-config´s „tauschen“. Hatte ich mich wohl unklar ausgedrückt.

    Moderator Bego Mario Garde

    (@pixolin)

    vor 2 Jahren, 3 Monaten

    Dann ist ja alles gut. 😅

    Thread-Starter lud3r

    (@lud3r)

    vor 2 Jahren, 1 Monat

    Hallo nochmal !

    Auch wenn es etwas mehr Zeit benötigt hat … doch die Lösung möchte ich hier trotzdem noch hinterlassen.

    Es lag tatsächlich daran, dass die wp-config nicht im Stammverzeichnis gelegen hat. Ich hatte diese ja eine Ebene tiefer gesetzt aus Sicherheitsgründen.
    Sie liegt nun also dort, wo auch die normeln wp-Ordner usw aufbewahrt sind.
    php läuft auf 8.1. nun *top*

    Vielen Dank für die Hinweise und Unterstützung hier !

Ansicht von 8 Antworten – 1 bis 8 (von insgesamt 8)
  • Das Thema „php update und Seite funktioniert nicht mehr“ ist für neue Antworten geschlossen.

Schlagwörter