WBCE CMS Forum

norhei

Developer

Upgrade Script für zukünftige Revisionen

Was denkt Ihr, ist es sinnvoll sämtliche Upgrade Geschichten von WB 2.8.3 Sp 1-4 im Upgrade Script mitzuschleppen ? Auch in die nächsten Revisionen ?

Das Upgrade Script ist momentan ein echtes Alptraummonster, da ich grade Singletab entferne muss wollte ich aber ein paar Settings entfernen. Und stelle fest das da noch Änderungen vom Upgrade auf WB 2.8.2 drin stehen.

florian

Administrator

Re: Upgrade Script für zukünftige Revisionen

2.8.2 kann raus.
2.8.3 SP1-4 würde ich drinlassen.
Alternativ: Ein gesondertes Migrationsscript WB 2.8.3 => WBCE (das alte upgrade-script) und einen neuen Updater ausschließlich für WBCE.

Oder wir legen uns fest, dass für WBCE 1.1 Updates nur von WBCE 1.0 möglich sind, d.h. Umsteiger erst auf WBCE 1.0 mittels des bestehenden Scripts migririeren und dann das Update auf 1.1 mittels eines neuen Updaters machen. So richtig benutzerfreundlich ist das mMn aber auch nicht.

---

Wir Benötigen: Cents, Euros... jetzt spenden!

florian

Administrator

Re: Upgrade Script für zukünftige Revisionen

Vorschlag/Idee:

Für die kommende WBCE 1.2 müsste man m.E. überlegen, wie Updates von Vorversionen erfolgen.

• Update von WB classic: (Noch unterstützen oder erst  WB classic -> WBCE 1.1 -> WBCE 1.2? Ich tendiere ja fast zu letzterem)

• Update von WBCE 1.0

• Update von WBCE 1.1.x

Da

• wir im Core diverse Module mit ausliefern, die individuell angepasst werden

• oft die vorinstallierten Templates (naja, also zumindest SimpleResponsive) als Grundlage für ein eigenes Design verwendet werden

• andere Module von den Benutzern entfernt werden, da sie diese nicht nutzen

• der dickste Brocken im Installer der CKEditor ist, an dem wir bewusst keine Änderungen vornehmen, da der neueste CKE mehr Probleme verursacht als löst, dieser somit also zumindest bei bestehenden WBCE-Websites gar nicht aktualisiert werden muss

ist der bisherige Tabularasa-Überschreib-Mechanismus eigentlich nicht geeignet, um bestehende Websites zu aktualisieren.

Wie könnten ein oder die Anzahl erforderlicher unterschiedlicher Update-Pakete nebst -Scripten erstellt werden? Lässt sich das irgendwie automatisieren?

---

Wir Benötigen: Cents, Euros... jetzt spenden!

cwsoft

Mitglied

Re: Upgrade Script für zukünftige Revisionen

Dem WBCE Upgrade Script merkt man halt an, dass es für WB 2.7 Zeiten (2008) entwickelt wurde und seit dem mehrmals upgedated wurde. Aus WBCE Sicht kommt noch hinzu dass es nun sowohl für WBCE als auch für WB ein Upgrade anstossen soll.

Es gibt drei Installationspfade:
1. Neuinstallation von WBCE (keine Probleme)
2. Upgrade einer früheren WBCE Version
3. Wechsel von WB 2.8.3 (SP4-x) auf WBCE

Ich würde WBCE Upgrade und WB-Wechsel trennen und in zwei Upgradescripte aufteilen.

Wechsel von WB 2.8.3 (SP4-x) auf WBCE:
Ich würde zuerst auf WBCE 1.0 wechseln und dann auf WBCE x.y migrieren.
Vorteil: Zumindest WBCE 1.0 bleibt stabil
Nachteil: Evtl. Änderungen der PHP Version oder MySQL, MariaDB können dazu führen dass WBCE 1.0 zukünftig nicht mehr auf neueren Systemen läuft.

Upgrade einer früheren WBCE Version:
Sollte in Zukunft idealerweise aus dem Backend über ein eigenes Modul gesteuert werden. Das gefällt mir bei WordPress oder Contao ziemlich gut. Grösstes Problem dürfte es hier auf schlecht konfigurierten shared hosting Angeboten geben (Skriptlaufzeit, FTP/PHP Nutzer, Mischung der Schreib- und Leserechte).

Bei strikter Trennung von Core und Nutzerdaten (Templates, Medien, Module, Backendthemes) ist auch das löschen des Core Ordners per FTP oder Webinterface, hochladen des neuen Core Ordners und update der DB gängige Praxis (z.B. Silverstripe ...). Mache ich auch gerne bei WBCE. Wartungsmodus über .htaccess aktivieren, alle Coredateien löschen, ZIP Packet der neuen Version hochladen, über Webinterface oder Script entpacken und DB Update anstossen. Der eigentliche Vorgang dauert so meist nur 1-2 Minuten.

Sinnvoll wäre sicherlich ein Analysescript anzubieten, das mögliche Stolpersteine vorher abklopft und die richtige Updatestrategie vorschlägt. Man könnte z.B. über SHA1 Checksummen die Integrität von Templates/Modulen etc. prüfen um festzustellen, ob Änderungen vorgenommen wurden ...

Alles in allem ein recht komplexes Thema 

Beitrag geändert von cwsoft (23.05.2016 12:05:21)

---

Account inactive since 2018/11/17.