Ich hatte ja schon des öfteren moniert, dass der "gm_updater" sehr anwenderunfreundlich ist, vor allem, wenn man viele Shops mit unterschiedlichen Releaseständen aktualisieren muss. Da ich da langsam den Überblick verloren habe, habe ich das jetzt mal grundsätzlich neu gemacht. Ziel ist es, einen(!) generischen "gm_updater.php" zu haben (der generell gilt), und Service-Pack-spezifische PHP-, SQL- und RELASE_INFO-Module, die die notwendigen Befehle jedes Service-Packs zum Datenbank-Update enthalten. Ein weiteres Ziel ist es, automatisch(!) mehrere Service-Packs updaten zu können. Dazu mussten die bestehenden Strukturen geändert werden. Die generellen Anteile der "gm_updater.php"-Programme jeden Service-Packs wurden zu einem neuen "pt_gm_updater.php" zusammen gefasst. Es gibt in der Shop-Root eine neues Verzeichnis "updates", mit den Unterverzeichnissen "info", "php", und "sql". In das Unterverzeichnis "php" werden die Service-Pack-spezifischen Teile des jeweiligen bisherigen "gm_updater.php"-Programms eines Service-Packs ausgelagert. In das Unterverzeichnis "sql" wird das Service-Pack-spezifische bisherige "gm_updater_sql.php"-Programm eines Service-Packs ausgelagert. In das Unterverzeichnis "info" wird das Service-Pack-spezifische bisherige "release_info.php"-Programms eines Service-Packs ausgelagert. Dabei muss die Namensgebung der Dateien folgende Konvention erfüllen: Unterverzeichnis "php": gm_updater_sp-version.php z.B. gm_updater_2.0.10.php gm_updater_2.0.11.2.php gm_updater_2.0.12.2.php Unterverzeichnis "sql": gm_updater_sp-version_sql.php z.B. gm_updater_2.0.10_sql.php gm_updater_2.0.11.2_sql.php gm_updater_2.0.12.2_sql.php Unterverzeichnis "info": release_info_sp-version.php z.B. release_info_2.0.10.php release_info_2.0.11.2.php release_info_2.0.12.2.php Der Verzeichnisinhalt ist dann wie folgt: "pt_gm_updater.php" scannt das Verzeichnis "updates/php" nach "gm_updater_xxxxx.php"-Programmen, und ruft diese nacheinander auf. Vor dem Aufruf wird die zugehörige SQL- und RELEASE_INFO-Datei geladen. "pt_gm_updater.php" prüft, ob ein Service-Pack schon installiert ist, und überspringt die Installation dann. Bei der Erstellung.von Updates mit mehreren Service-Packs legt man am Besten zunächst ein neues Verzeichnis an, das alle Dateien aller zu installierenden Service-Packs enthält, z.B. "Service Pack 2.0.10 - 2.0.12.2 (GX2)", das die Service-Packs Service Pack 1.4g (GX2) Service Pack 2.0.11.2 (GX2) Service Pack 2.0.12.2 (GX2) enthält. Wichtig dabei ist, dass man die Dateien in der Reihenfolge der Service-Packs dort hinein kopiert, um sicher zu stellen, dass am Ende die aktuellsten Versionen der Programme in diesem Verzeichnis enthalten sind "Service Pack 2.0.10 - 2.0.12.2 (GX2)" ist quasi das Root-Verzeichnis des Shops, das die zu aktualisierenden Dateien enthält. Man kopiert also den Inhalt des Unterverzeichnisses "Shopsystem\Dateien\" jedes Service-Packs dort hinein, ebenso die Unterverzeichnisse "Developer_Info", "GProtector" und "StyleEdit". Hinzu kommt das zuvor beschriebene Unterverzeichnis "updates" und das Programm "pt_gm_updater.php". Damit hat man dann ein "Multi-SP"-Service Pack-Paket, das man dann auf mehrere Shops anwenden kann. Die Problematik, dass Service-Pack-Dateien evtl. modifizierte vorhandene Dateien überschreiben besteht natürlich weiterhin, so dass man die Modifikationen evtl. wieder nachtragen muss. Im Anhang ist ein solches "Multi-SP"-Service Pack-Paket beigefügt.Die Idee ist natürlich, dass man nicht die einzelnen Service-Packs erst selbst modifizieren muss, sondern dass Gambio diese künftig gleich entsprechend aufbereitet. Weiterhin ist es natürlich auch möglich, das zuvor beschrieben Kopieren der Service-Pack Dateien automatisiert... Dann könnte man direkt auf dem Gambio-Server solche "Multi-SP"-Packs erstellen: man wählt das erste und letzte gewünschte SP aus (Dropdowns), und dann wird auf dem Server das "Multi-SP"-Pack erstellt, und als "zip"-Download-Datei erstellt. Wie immer gilt: Anwendung auf das ausschließliche Risiko des Shopbetreibers. Es gibt keinerlei Gewährleistung. Erst in einem Testshop testen. Cache leeren.
Mit dem Service Pack 2.0.13.0 haben wir eine Zwischenlösung geschaffen. Es gibt nun einen Ordner gambio_updater in dem die Dateien zum Datenbankupdate liegen (update_2-0-13.php und sql_2-0-13.php). So kann man, wenn man z. B. von 2.0.12.0 auf 2.0.14.0 updaten will einfach beide Service Packs zusammen kopieren und anschließend die bei Datenbankupdater nacheinander ausführen. Das ist noch nicht der Weisheit letzter Schluss, aber als schnell gemachte Zwischenlösung schon einmal eine Verbesserung.
Das funktioniert nur auf Windows-Servern, die kaum jemand im Einsatz hat. Damit das immer funktioniert, muss eine FTP-Verbindung aufgebaut werden. Sowas werden wir sehr wahrscheinlich umsetzen, es wird jedoch noch länger dauern, bis wir dazu kommen.
Das ist ein Rechteproblem. Der User vom Webserver kann keine Dateien löschen, die vom FTP-User erstellt wurden.
Hmmm. Ich bin ja echt kein PHP-/Server-Spezialist, aber ich stelle mir das doch einfacher vor. Eine Liste mit allen zu löschenden Dateien die dann in einem Array abgelegt werden. Die Pfade sind ja fix und bekannt. Das Löschscript räumt dann einfach alle Dateien weg, sind Dateien nicht (mehr) vorhanden wird einfach zur nächsten gesprungen im Array. Zur Sicherheit soll/kann der Benutzer angeben ob die Dateien automatisch gelöscht werden sollen oder nicht. Oder sehe ich das falsch resp. berücksichtige ich da etwas nicht?
Hat was für sich.... Bei Servern, bei denen "allow_url_open" aktiv ist kann man das Löschen per FTP relativ einfach realisieren: FPT-User, -Passwort und -Server als Konstante definieren, dann kann man ein "$ftp_lead='ftp://'.FTP_USER.':'.FTP_PASSWORD.'@'.FTP_SERVER" definieren, und dann mit PHP: foreach ($delete_files as $delete_file) { $file=$ftp_lead.DIR_FS_DOCUMENT_ROOT.$delete_files; @unlink($file); } die Dateien per FTP löschen. Bei Windows-Servern ist "$ftp_lead" leer, so dass das normale Löschen auf dem Server stattfindet. Hab' ich gerade mal so eingebaut....
Wie ist das denn Sicherheitstechnisch? Könnten nicht auch unbefugte Dateien löschen, wenn User und PW hinterlegt sind?
@ Moritz meine Shopversion ist noch die 2.0.11.1, jetzt möchte ich am WE die SP .11.2; ,12.2 und 13.0 einspielen. Kann ich die update-Dateien entsprechend umbenennen, in den Ordner "gambio_updater" packen und nacheinander aufrufen? Beispiel: /gambio_updater/ gm_updater_11.php /gambio_updater/ gm_updater_sql.11php und aufrufen unter (Link nur für registrierte Nutzer sichtbar.) oder kann es da Probleme geben?
Ich habe das weiter optimiert: "pt_gm_updater.php" enthält jetzt die komplette Steuerungslogik für alle Service Packs. Die "gm_updater_sp-version.php"-Dateien im Verzeichnis "updates/php" enthalten nur noch die wirklich für ein Service-Pack relevanten Update-Befehle. Im Anhang ist das Multi-SP Update-Package für die Service Packs 2.0.10 bis 2.0.13.0 beigefügt. Die Doku ist als "multi_sp_updater.pdf" beigefügt. Wie immer gilt: Anwendung auf das ausschließliche Risiko des Shopbetreibers. Es gibt keinerlei Gewährleistung. Erst in einem Testshop testen. Cache leeren.
Hallo Avenger, ich habe mir mal den Multi Updater mal angesehen und getestet. Im ersten Moment sieht das so aus ob das mit dem Update gut funktioniert. Leider werden aber die Dateien nicht gelöscht. allow_url_fopen ist aktiviert FTP Daten in der configure.php eingetragen. PHP: //FTP Zugang für Servicepacks define('FTP_SERVER','XXXXXXXX.de'); define('FTP_USER','webXXX'); define('FTP_PASSWORD','XXXXXX'); ?> Am Ende kommt sogar die Meldung, das die Dateien gelöscht wurden. Wurden Sie aber nicht, denn die Dateien sind noch auf dem Server. Vielleicht ist es auch möglich, wenn allow_url_fopen nicht auf on steht, eine Meldung auszugeben.
Versuche mal im Browser mit folgender Adresse FTP anzusteuern: ftp://FTP_USER:FTP_PASSWORD@FTP_SERVER/DIR_WS_CATALOG Wobei Du natürlich die entsprechenden Konstanten ersetzen musst....
Was geschieht, wenn Du den Pfad für eine zu löschende Datei anfügst? ftp://FTP_USER:FTP_PASSWORD@FTP_SERVER/DIR_WS_CATALOG/eine/zu/löschende/datei Die sollte dann geladen werden.....