OXID eShop Update ab v6.0.0


#1

Guten Tag (Morgen),

seit 9 Stunden ca ist OXID eShop in der Version 6.1.0 erschienen (https://github.com/OXID-eSales/oxideshop_ce/releases/tag/v6.1.0). Zu gerne würde ich nun also wissen, wie ich nun von v6.0.0 auf v6.1.0 reibungslos updaten kann, bzw wie die Updates in Zukunft (ab v6.0.0) ablaufen?

Weiß das jemand? Bzw hat es schon jemand gemacht?
Vielen Dank, schon mal im Voraus und eine schöne Woche noch.


#2

Der OXID eShop ist Bestandteil (Komponente) in der sog. OXID Kompilation (aktuelle Zusammenstellung. Die aktualisierte Kompilation (mit OXID 6.1) wird in Kürze veröffentlicht.

Siehe auch: https://docs.oxid-esales.com/developer/en/6.0/glossary.html


#3

Die Compilation ist auch noch nicht draussen, sie erscheint erst - wie üblich - am letzten Dienstag im Monat, also jetzt am 30.1. Die Versionsnummer der Compilation wird dann die 6.0.1 sein.


#4

Bezügl der Compilation:
Da ist ja viel drin, was man evtl nicht braucht, wie zB payment module die man nicht nutzt, zb amzn/amazon-pay-sdk-php oder oxid-esales/oxideshop-demodata-ce.

Kann man den require block von oxid-esales/oxideshop-metapackage-ce compilation auch in die Haupt composer.json kopieren und dann anpassen und die compilation löschen?

Und dann ganz normal composer update machen.

Wie läuft das dann mit den Datenbank updates?


#5

Vielen Dank, aber das beantwortet nicht die Frage wie das Update durchgeführt wird.
Gibt es dazu ne Duko oder Anleitung? Wäre super.

Und wenn das ein Befehl über die Console sein wird, kann man den dann auch per Backend anstoßen? Wie z.B bei Typo3, da kann man bestimmte Befehle auch aus dem Backend aus anstoßen/ausführen.

Vielen Dank


#6

sobald es ein Update gibt, wird es auch eine Anleitung geben.
Es ist bisschen schwer Anleitung für etwas zu schreiben, das gar nicht existiert.


#7

Ich vermute sowas wie hier beschrieben
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_6x_to_6y/update_to%206.0.0.html

Also composer update & db migrations auf der console.


#8

Die des Shops auch, warum heißt das Tag dann eigentlich 6.1.0?


#9

Dazu soll es noch einen detaillierten Blogpost geben, Frank. Vorab schonmal so viel: Jede einzelne Komponente wird ab der V6 semantisch versioniert. Wirf mal einen Blick hier drauf: https://github.com/OXID-eSales/development-wiki/blob/master/shop/changelog/changelog_v6.0.1.rst
Dort siehst Du z.B. die CE und die EE getagged mit 6.1.0, die PE bleibt auf dem Stand 6.0.0, weil in dieser Komponente (Repo) nichts geändert wurde. Bei den Versionsständen für die Compilation bleibt es bei der bisher üblichen Versionierung: Patches fixen nur Bugs (keine Änderung DB, keine Änderung an der GUI) etc…


#10

Ja, das ist kein Problem. Du musst die composer.json der Compilation nicht zwingend verwenden, sondern kannst dir auch das was du brauchst in deine root composer.json schmeißen.

Eher nicht, dafür gibt es ja composer.

Genau, kommt noch …

Ich fände es auch besser, wenn sich die Compilation am Shop (Komponente) orientieren würde, aber macht halt OXID wie immer anders :wink:


#11

Tut sie ja, der Shop ist auch Version 6.0.1, nur der Tag heißt anders.


#12

Das ist wohl privat :wink:


#13

Ne, der Shop hat als Tag/Release 6.1.0


#14

Sag ich doch, das Tag ist 6.1.0 aber die Shopversion ist 6.0.1: https://github.com/OXID-eSales/oxideshop_ce/blob/2ae745feb81dfd8852aa8bdf63eed9ea23536c06/source/Core/ShopVersion.php#L19


#15

Ahhh, jetzt … weiss nicht ob ich das sinnvoll finde …


#16

Ähm ja, sorry, geht sicher am Dienstag auf:

# OXID eShop compilation v6.0.1
## Compilation components
...
    Flow Theme
        from version v2.3.1 to version v2.3.3

    OXID eShop CE
        from version v6.0.0 to version v6.1.0

    OXID eShop demodata CE
        from version v6.0.0 to version v6.0.1

    PayPal - The OXID eFire extension
        from version v5.1.3 to version v5.1.5

    The PAYONE module for Oxid 6
        from version 1.0.4 to version 1.0.5

    Visual CMS
        from version v3.0.0 to version v3.1.0

    OXID eShop demodata PE
        from version v6.0.0 to version v6.0.1

    OXID eShop demodata EE
        from version v6.0.0 to version v6.0.1

    OXID eShop EE
        from version v6.0.0 to version v6.1.0

Da sieht man schon, was abgeht: Es wird quasi pro Komponente/pro GitHub-Repository ein neues (semantisches) Versioning eingezogen, komplett unabhängig von der sog. Compilation. Das Repository OXID eShop PE ist nicht aufgeführt und bleibt deshalb z.B. beim Tag 6.0.0 stehen.

WTF? Ja! Weil eben nicht mehr wie früher in einem Strang entwickelt wird sondern PE und EE in den jeweiligen Repos nur noch die Code-Teile enthalten, die on top auf die CE kommen. Mit wachsenden semantischen Versionsnummern wird sich diese aktuelle Verwirrnis sicher auch etwas auflösen. Semantische Versionierung schreibt eben vor, dass beim Hinzufügen neuer Funktionen (nicht Features, sondern Klassen/Methoden) oder auch beim Kennzeichnen von Funktionen als “deprecated” einen Versionssprung an der zweiten Stelle (Minor Update) vorgesehen ist.

Das heisst z.B. aber auch, dass solche bisher hinderlichen Dogmata wie z.B. “Man darf im Patch-Release keine Änderung an der GUI durchführen” oder auch “Es werden nur noch die letzten beiden Serien supported” nicht mehr von reiner Marketingsicht abhängig sind und man mit dem Beheben von z.B. Bugs, die das Frontend betrafen, unter Umständen warten musste, bis der Rest der Firma nachgezogen hatte - und das finde ich persönlich sehr sehr gut so ^^

Vielleicht kann ich das noch ein Stück weiter abstrahieren: Ubuntu 14.04 wird mit PHP 5.6 ausgeliefert, während Ubuntu 16.04 schon mit PHP 7.0 daherkommt. Die Kernel-Versionen und die des X-Servers/Desktops sind entsprechend unterschiedlich.

Noch eine Anmerkung:
Auffällig sind die Versionsspünge von zwei Patch-Releases beim Flow-Theme wie auch bei Paypal. Dort ist es schlichtweg so, dass es bis dato keine Changelogs in dieser Form gegeben hat.

Hab ich das halbwegs verständlich erklärt? Ansonsten fragt bitte!


Update mit Composer auf 6.1.x nicht möglich
#17

Danke für die Erklärung. Ich fasse mal zusammen:

Compilation Version bleibt identisch mit Shopversion

Repo Version/Tag Name: hat nichts mehr mit der Shopversion zu tun wie bisher sondern hängt nur noch von den technischen Änderungen im jeweiligen Repo ab.

Neue Shopversion ist also 6.0.1 in allen Editionen


#18

Aha, das ist schon verwirred genug und wenn ich aus 6.0.0 ein update auf 6.0.1 durchführen will - so wie hier beschrieben
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_6x_to_6y/update_to%206.0.0.html
und compser.jason mit v6.0.1 - dann kommt folgende Meldung:

The requested package oxid-esales/oxideshop-metapackage-ce ^v6.0.1 exists as
oxid-esales/oxideshop-metapackage-ce[dev-b-6.0, dev-b-6.0-beta, dev-master, v6.0-beta.1, v6.0-beta.2, v6.0-beta.3, v6.0.0, v6.0.0-rc.1, v6.0.0-rc.2, v6.0.0-rc.3] but these are rejected by your constraint.”

Also einfach in CLI <project_root> “composer update” ausführen und es läuft.
Dann nochmal mit den in Github beschriebenen Updates stichprobenweise verglichen und es ist ok. Im Admin steht dann oben rechts aber immer noch 6.0.0 satt 6.0.1.


#19

Wie oben schon geschrieben wurde 6.0.1 noch nicht offiziell veröffentlicht, daher auch nicht installierbar.


#20

Ich denke ich werde ich mal meine “Lösung” hier reinschreiben. Dann kann jeder meine Anleitung vervollständigen.
Anders führt das ja zu nix. Bitte vervollständigen wenn man sieht das etwas fehlt.
.
.
.

Hier meine Vorgehensweise.

BACKUP ANLEGEN (Von FTP und von der DB)

IST Status: Der OXID Shop (frisch installiert) befindet sich in der v6.0.0 “stable” und es wird auch als 6.0.0 im Backend angezeigt und das ein Update verfügbar ist

SSH auf <project_root>

Die Ordnerstruktur von <project_root> sieht so aus:
source (Ordner)
vendor (Ordner)
composer.json (Datei)
composer.lock (Datei)

Hier führe ich per SSH den Befehl aus:

composer update --no-plugins --no-scripts

Läuft reibungslos durch und Updated alles, bis auf Plugins und Skripte.

Danach wird mir im Admin Backend angezeigt, dass der Shop in der v6.0.1 installiert ist.
Wärend des Update-Prozesses habt ihr viele Codezeilen gesehen, welche beschrieben haben was und auf welche Version es geupdated wurde.

z.B.:

  - Updating oxid-esales/paypal-module (v5.1.3 => v5.1.5)

Demnach sollte das PayPal Modul auf Version v5.1.5 sein, wenn Ihr jedoch unter Erweiterung --> Module nachprüft ist es immer noch auf der Version 5.1.3 (es wurde also nicht geupdated)


Das liegt an dem Parameter “composer update –no-plugins --no-scripts” , welcher unterbindet das Plugins (und Skripte) geupdated werden.

Der Shop ist also geupdated, Plugins, Skripte etc nicht. Das ist wichtig um erstmal zu testen ob alles geht und vtl wollt ihr auch ein paar Plugins gar nicht updaten.

Falls Ihr Module (Plugins) doch Updaten wollt, wie ich, dann geht es so weiter:

composer update

Der Befehl sollte nun am Shop nichts zum Updaten haben und direkt zum Updaten der Skripte und der Plugins gehen. Da läuft der Befehl einfach durch und fragt immer wieder ob er Moduldateien überschreiben darf. Ich habe alles mit “y” bestätigt da ich keine Moduldateien verändert habe.
Danach hält er an:

Creating the "test_config.yml" file
Some parameters are missing. Please provide them.
shop_path (source):
shop_tests_path (tests):
partial_module_paths (null):

Ihr füllt dort die Daten eures Shops ein. Meine (und das sind die Standarddaten) sind folgende:

Creating the "test_config.yml" file
Some parameters are missing. Please provide them.
shop_path (source): 'source'
shop_tests_path (tests): 'test'
partial_module_paths (null): (hier einfach mit Eingabe bestätigen ohne etwas einzutippen)

Wenn Ihr alles richtig gemacht habt und zurück ins Backend geht, seht ihr erst, dass der Shop nach wie vor auf Version v6.0.1 ist (also erfolgreich geupdated wurde)
und z.B. das Modul PayPal nun auf der Version 5.1.5 ist!

Wichtig ist das auch unter Erweiterung --> Module --> Installierte Shop-Module alle Standardmodule eingetragen sind und nicht durchgestrichen sind! (Sonst ist etwas bei “composer update” schief gelaufen)

Nun sollte euer Backend so aussehen:

Die Ordnerstruktur von <project_root> sieht nun so aus:
source (Ordner)
vendor (Ordner)
.ide-helper.php (Datei)
composer.json (Datei)
composer.lock (Datei)
test_config.yml (Datei)

So habe ich meinen Shop geupdated! :slight_smile:

Das einzige was jetzt noch stört ist:

Service --> Systemgesundheit, Hier wird folgendes angezeigt:

Systemgesundheit:

  • PHP 7.1 & 7.2 werden nicht offiziell unterstützt. Könnte ich lösen, indem ich auf 7.0 wechsle
  • MySQL (MariaDB) v10.0 wird nicht offiziell unterstützt. Das ist doof, es geht nun mal alles in Richtung MariaDB, CentOS und Debian bringen in den neuen Versionen standardmäßig auch nur MariaDB mit.

Fehlende Modulblöcke im Template:

Modulname Blockname Template Dateiname
oepaypal mb_details_productmain_morepics page/details/inc/productmain.tpl
oepaypal mb_details_productmain_tobasket page/details/inc/productmain.tpl
oepaypal mb_basket_btn_next_bottom page/checkout/basket.tpl
oepaypal mb_basket_btn_next_top page/checkout/basket.tpl
oepaypal mb_select_payment page/checkout/payment.tpl
oepaypal mb_select_payment_dropdown page/checkout/payment.tpl

Die fehlenden Modulblöcke fehlen jedoch auch in der frischen v6.0.0, liegt also nicht am Update, habe es extra nochmal nachgeschaut.

Ebenfalls funktioniert in der v6.0.0 & v6.0.1 der oxchkversion check nichtmehr.
Bei mir wird folgender Fehler angezeigt.

v6.0.0:

v6.0.1: