PHP update und Wordpress

  • Hallo zusammen,


    ich habe zwei Internetseiten mit Wordpress auf dem gleichen Webspace von netcup. Funktioniert wunderbar.


    - eine sehr aufwendige mit der ich seit Jahren arbeite und mir sehr sehr am Herzen liegt

    - die zweite eher zum rumspielen


    Mir wird angezeigt, dass für Internetseiten php Version auf 7.3.33 aktiv ist.

    Ich pflege alles sehr intensiv und versuche normal immer up to date zu sein, wusste nur nicht, dass ich selbst auch im Interface die php Version umstellen kann.

    Ich habe mehr als nur Ehrfurcht davor einfach die php Version zu verändern (für die erste Seite).


    Ich machte ein vollständiges Backup per netcup im Interface.


    Ich stellte für die zweite Internetseite per Interface von netcup auf von 7.3. auf php 7.4 um. Alles von Wordpress/Plugins up to date davor.


    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.

    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.


    Ich wählte die Wiederherstellung von netcup, doch dann erschien das Bild, dass nun ich komplett neue Daten eingeben soll für eine Datenbank, Benutzer usw ... also eine Neuinstallation.

    Zu erwähnen ist, dass eine Fehlermeldung von der Wiederherstellung (netcup) dargestellt wurde als diese beendet war.


    netcup fehler 1 .jpg



    Fragen :

    a. Sollte normal eine php Versionsumstellung ohne diese Dinge ablaufen ?

    b. Kann ich für die erste Seite das irgendwie simulieren ohne die zu zerschießen (falls es nicht klappt) ? UpdraftClone bietet dieses für kleines Geld (meine ich) an.

    c. Was müsste ich definitiv sichern um auf jeden Fall alles wiederherstellen zu können ? Ich dachte da an BackWPup die die ganze Seite samt Datenbanken sichert. Diese müsste ich doch dann einfach per SFTP hochladen und im Interface die Datenbank einspielen und dann müsste doch normal alles wieder funktionieren, oder bin ich da verkehrt vor ?


    Edit : Oder könnte es an den Dateiattributen liegen ? Weil aus Sicherheitsgründen habe ich oft nur Leserechte (z.B. für wp-confg usw)


    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.

  • Zu a) nein, eine Umstellung von 7.3 auf 7.4 sollte dir nicht gleich deine WordPress Installation zerlegen.

    Die eigentlichen Inhalte kommen bei WP aus der Datenbank, ist diese noch vorhanden?

    Die Einstellungen zur DB kommen aus der wp-config.php ist diese noch vorhanden und steht etwas Sinnvolles drin?

  • 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?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Zu a) nein, eine Umstellung von 7.3 auf 7.4 sollte dir nicht gleich deine WordPress Installation zerlegen.

    Die eigentlichen Inhalte kommen bei WP aus der Datenbank, ist diese noch vorhanden?

    Die Einstellungen zur DB kommen aus der wp-config.php ist diese noch vorhanden und steht etwas Sinnvolles drin?

    Die Datenbank ist noch in dem Plesk-Backup als tszt-datei vorhanden. Ganz komisches Format. Dort müsste ich sie herausextrahieren.


    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.

  • 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 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.


    Das Toolkit in Plesk für Wordpress ist mir gänzlich unbekannt. WIrd das ggf. automatisch verwendet ?


    Gibt es eine Möglichkeit ein php update zu simulieren wie mit Updraftclone oder kann ich das irgendwie anders checken ? das php compability check tool verwendete ich ... doch das geht nur bis 7.3.

  • 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?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Also mein Vorgehen wäre hier - zumindest wenn ich extra vorsichtig sein wollte:

    1. Von Hand die Dateien und die Datenbank sichern (z.B. per PhpMyAdmin).

    2. Mittels eines Plugins das Wordpress sichern (z.B. UpdraftPlus)

    3. Sicherstellen dass Wordpress, alle Themes und alle Plugins aktualisiert sind.

    4. Alle Plugins deaktivieren.

    5. PHP Update durchführen.

    6. Wenn alles geht: Plugins wieder aktivieren.


    Realistisch gesehen mach ich zwar einfach nur Punkt 5 und wenns ned klappt stell ich es halt zurück, aber wir wollten ja auf Nummer extra sicher gehen :)


    PS: Der Hinweis von KB19 ist natürlich sehr gut, eine Configdatei die außerhalb des eigentlichen Wordpresses liegt ist ne komisch Sache. Wenn möglich diese vorher vielleicht ganz normal ins Wordpressverzeichnis stecken, dort wo sie hingehört. "Eigentlich" ist das auch kein Sicherheitsrisiko!

  • Die Datenbank ist noch in dem Plesk-Backup als tszt-datei vorhanden. Ganz komisches Format. Dort müsste ich sie herausextrahieren.

    tzst - das ist die Kurzform von .tar.zstd - Vergleichbar mit .tar.gz

    Unter Linux kann das ganz einfach entpackt werden - unter Windows brauchst du leider eine modifizierte Version von 7zip: https://github.com/mcmilk/7-Zip-zstd/releases


    zStandard ist noch ein sehr neuer Algorithmus.

  • Die Datenbank ist noch in dem Plesk-Backup als tszt-datei vorhanden. Ganz komisches Format. Dort müsste ich sie herausextrahieren.

    Auf dem Host ist sie nicht mehr, also in Plesk? Dann wäre aber was komplett schief gelaufen.


    Ich würde auch empfehlen die Dateien wie wp-config.php auch an ihren Ursprungsort zu legen, vermutlich läuft dann bereits alles wieder.

  • zu openbase_dir :


    Das mit dem open_basedir ist ein sehr guter Hinweis schätze ich, denn also ich von 7.3. auf 7.4 umstellte und übernehmen wollte, da musste ich das dieses Feld selektieren. Also wählte ich die Variante die standard ist. Siehe Bild. Sollte ich da noch nachträglich etwas dran verändern ? Oder habe ich falsch ausgewählt ?


    2022-08-19 13_58_42-Window.png


    Ich wählte die obere (standard)


    Edit : Mir fällt auf, dass nun wo wieder 7.3. von mir aktiviert ist, diese Einstellung weiterhin Bestand hat. Zuvor war sie ja "leer" und nun ist durch die Umstellung auf 7.4. wie angezeigt auch für 7.3. dieses übernommen worden ist.

    Ggf. muss ich dieses anpassen ?


    Zu wp-config :

    Interessanterweise wies mich wordpress darauf hin (als ich beim ersten aufrufen der Seite die Datenbankdaten eingeben hatte), dass bereits eine wp-config vorhanden ist bzw das ein Problem damit besteht.

    Ich habe darauf hin die wp-config aus dem Vorordner in den Hauptordner gelegt und dann ging es weiter. Aber dann war die Seite komplett auf Grundeinstellung.

    Es ist also noch die alte vorhanden ... im Vorordner (ich kopierte sie) und die neue/leere ist im Hauptordner.


    Den Pfad zur wp-config :

    Bin ich ganz ehrlich. Ich weiss es nicht mehr 100%ig. Ich bin jedoch der Meinung, dass dieses ohne Konfiguration möglich war. Ich habe die Datei also einfach in den Vorordner verschoben. Dateiattribute 400.

  • Gerade so denke ich auch. Deswegen nahm ich an, ich kann einfach auf 7.3. zurückstellen, doch leider leider leider nicht.

    Deswegen machte ich ja dann auch eine Wiederherstellung meines gesamten Speichers. Doch da erschien ja eine Fehlermeldung. Habe ein Bild eingefügt in meinem ersten Post.

    Doch wenn ich nun eine Wiederherstellung ganz ganz grob betrachte :


    - ich brauche die "harten" Datein, ob per FTP oder Updraftplus ist ja Geschmackssache ;)

    - ich brauche die Datenbank

    - (Plugins deaktivieren finde ich auch nicht schlecht)


    Diese beiden Sachen lade ich gänzlich hoch und fertig, oder ?

    okay, ich sollte vielleicht in meinem Fall die zuletzt funktionierende php Version verwenden :) ? Also 7.3.

  • Auf dem Host ist sie nicht mehr, also in Plesk? Dann wäre aber was komplett schief gelaufen.


    Ich würde auch empfehlen die Dateien wie wp-config.php auch an ihren Ursprungsort zu legen, vermutlich läuft dann bereits alles wieder.

    Das gesamte Backup ist noch in Plesk vorhanden und kann wiederhergestellt werden, doch leider mit der Fehlermeldung wie im Bild in Post 1 dargestellt.

    Wenn ich dieses Backup herunterlade und die Datenbank suche, dann ist sie dort in dem genannten Format. H6G nannte ja wie ich diese extrahieren kann.

    Diese müsste ich ja dann im Netcup Interface wieder einspielen können. Oder muss ich das direkt in php myadmin machen bei dem Format ?


    Die Datenbank selbst wurde ja anscheinend bei dieser ungewollten Neuinstallation überschrieben und/oder falsch verwendet.

    Ich testete dieses "Datenbank testen/reparieren", doch da kam nichts bei raus.


    Mit der wp-config probierte ich, doch leider nein.

    Ich werde jedoch weitere Tests vornehmen, denn aktuell wird gar keine Seite mehr angezeigt bzw. ein weißer Bildschirm, mehr nicht.

  • 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.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

    Gefällt mir 2
  • Wie gesagt, normalerweise kann man problemlos auf 7.3 zurückstellen. Es wird ja nur der Interpreter geändert. Wenn das nichts mehr bringt dann muss irgendwas durch den Aufruf von Wordpress mit der anderen PHP Version kaputt gegangen sein. Und zwar durch Wordpress selbst.


    Ich bin dafür dass wir uns alle aus dem Thread mal in nem Meeting treffen und gemeinsam draufschauen :)

  • Oder muss ich das direkt in php myadmin machen bei dem Format ?

    Ich gehe mal davon aus, dass die Datenbank im Backup als Dump vorliegt (.sql Datei).

    Dies würdest du per PHPMyAdmin wieder Einspielen - unter Import.


    Ich tippe auch auf den OpenBaseDir - probiere bitte mal die Vorgehensweise von KB19

    Alternativ - deine andere Wordpress Installation funktioniert ja noch, richtig?

    Hier könntest du dir die OpenBaseDir Einstellung auch kopieren und dann bei der anderen Wordpress Installation anwenden.


    Ansonsten die wp-config wieder dahin kopieren, wo sie vorher auch war.

  • Ich merke, dass Ihr ziemlich vom Fach seid :)


    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.


    KB19 : Das werde ich testen! Denn kaputt gehen kann ja nichts mehr.

    Doch wenn ich mir die Datein per SFTP ansehe dann erkenne ich, dass er eine wirkliche Neuinstallation gemacht hat.

    Komischerweise ist mein umbenannter content-Ordner noch vorhanden, doch der wp-content ist nun auch wieder da.

    Die Datenbank ist auch komplett leer. Ist fraglich, ob ich da nun wieder die alte wiederherstellen kann.

    Frage : Passt das zusammen, dass wenn open_basedir auf DOCROOT stand, dass Wordpress eine Neuinstallation verpasst ?


    Wie gesagt, normalerweise kann man problemlos auf 7.3 zurückstellen. Es wird ja nur der Interpreter geändert. Wenn das nichts mehr bringt dann muss irgendwas durch den Aufruf von Wordpress mit der anderen PHP Version kaputt gegangen sein. Und zwar durch Wordpress selbst.


    Ich bin dafür dass wir uns alle aus dem Thread mal in nem Meeting treffen und gemeinsam draufschauen :)

    Ich denke auch, dass Wordpress sich da irgendwie über alles rüber gebügelt hat.

    Und raufschauen finde ich sehr gelungen :)



    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.

    Du meinst, im Plesk-Backup als SQL ? Dort ist extra ein Ordner für die Datenbanken, jedoch gelingt es mir "noch" nicht diese passend zu extrahieren. Weil die sind ja in diesem anderen Format und daraus erhalte ich noch keine SQL. Werde da nochmal angreifen.

    Dazu müsste ich ja auch erstmal die ursprünglichen Datein wieder herstellen, denn die Plugins etc. sind ja alle komplett verschwunden (da Neuinstallation).

    Die wp-config hatte ich bereits verschoben, doch dadurch wurde es nicht besser.

    Die originale wp-config ist im Vorordner vorhanden. Die im Hauptverzeichnis ist nun jungfräulich.


    Wäre es eine Option das Problem zu reproduzieren ?

    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.


    Und noch einmal die Nachfrage : Sind die Dateiattribute wichtig, wenn ich die php-Version umstelle ?

  • jedoch gelingt es mir "noch" nicht diese passend zu extrahieren.

    woran scheitert's denn? 7zip wurde von H6G ja in #8 genannt.

    desweiteren gibt es apps auch direkt vom hersteller https://github.com/facebook/zstd/releases


    Und noch einmal die Nachfrage : Sind die Dateiattribute wichtig, wenn ich die php-Version umstelle ?

    eigentlich nicht. was vorher lief, sollte nach der umstellung ebenso laufen – hauptsache, die dateien können gelesen werden.

    der content passiert ja in den datenbanken, abgesehen von tmp-files etc.

    (ich sag' das als admin von prestashops mit mehrfachen php-versions-umstellungen)

    »Hauptsache BogoMIPS!«

    Fleischfresser

    4 Mal editiert, zuletzt von Olivetti ()

  • 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 :D


    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. :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()