Die 6.0.1 wurde heute veröffentlicht: https://docs.oxid-esales.com/eshop/de/6.0/releases/releases-2018/oxid-eshop-601.html
Martin, hast Du ganz am Anfang in composer.json überhaupt nichts geändert, so wir hier
beschrieben
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_6x_to_6y/update_default.html
und evtl. noch mehr.
Muss nachbessern. Ja die Datei muss wohl geändert werden. Ich jedoch selbst habe die bei der Anleitung nicht geändert!
Das heißt, dass die Updates die eingespielt wurden wohl auch mit der 6.0.0. kompatibel waren.
Werde den Punkt in die Anleitung aufnehmen.
In der composer.json im root, also von “oxideshop_project” steht ja:
"require": {
"oxid-esales/oxideshop-metapackage-ce": "^v6.0.0"
},
Wobei das Zeichen “^” steht für: >=6.0.0, <7.0.0, also sollten alle Updates 6.x automatisch installiert werden ohne dass die composer.json editiert werden muss.
Was ich vermisse, auch bei der offiziellen Anleitung, wenn bei der Installation --no-dev verwendet wurde, also wie es in der Installationsanleitung steht, dann sollte es beim Update auch wieder verwendet werden.
Kann ich so unterschreiben, es fehlen einfach offizielle Infos.
Was mir als Informatiker fehlt ist ne bessere Integration. Wir Informatiker sind nicht dafür bekannt, dass wir kompliziertes/umständliches kompliziert/umständlich lassen, sondern Dinge vereinfachen.
Alleine für die ganze Updategeschichte (die ehrlich gesagt nicht viel ist) könnte man das System doch so viel verbessern wenn man einen Updatebutton im Backend anlegt der folgendes macht:
1.) Felder haben wo man vorab schon alle wichtige Informationen die für die Installation benötigt werden einfüllen und abspeichern kann.
2.) FTP + DB sichern und auf dem Server ablegen.
3.) alle Module deaktivieren und merken welche deaktiviert wurden (in nem File etc abspeichern)
4.) “composer update --no-plugins --no-scripts” ausführen
5.) “composer update” ausführen (mit den Daten von Punkt 1)
6.) alle Module die deaktiviert wurden wieder aktivieren.
7.) Status ausgeben.
Ist doch wohl bei DEM Enterprise Shop CMS nicht zu viel verlangt?
Machbar wäre es, vtl kann man sich auch mit n paar Jungs zusammen setzen und so ein Modul selbst schreiben 
Nützlich wäre es und ich selbst wäre bereit für so ein Modul Geld zu zahlen, wenn sich also jemand angesprochen fühlt 
Macht doch mal nicht ganz so zackig, Leute. Der Update-Prozess von uns aus, also das Ausstreuen von Infos, dauert auch eine ganze Weile, zumal sich mit der sechser Version einiges geändert hat in den Abläufen. Ich hab z.B. gestern noch einen Pull Request hier reingereicht, der nach dem Cron in der Doku verfügbar ist:
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_6x_to_6y/update_default.html
Diese vier kleinen Schritte sollten ausreichen, um die Version von 6.0.0 auf 6.0.1 raufzuhebeln.
1 Like
In der Anleitung steht auch:
For executing possible database migrations, in the project folder run:
vendor/bin/oe-eshop-db_migrate migrations:migrate
Muss das auch bei dem Update auf die 6.0.1 gemacht werden? Kann ja sein das sich was in der Datenbank geändert hat.
@marco.steinhaeuser Schritt 1 ist doch irgendwie überflüssig? Und nochmal die Frage, warum kein --no-dev?
@Medicus keine db-Änderung in diesem Release.
Hey Frank,
Wir nutzen “Exact Version Contraints”, weil wir wollen, dass die Versionen kontrolliert ausgerollt werden können. Insofern ist der Schritt 1 notwendig.
Weiss ich nicht ^^
–no-dev wird eigentlich nur in der Produktivumgebung benötigt. Sollte man mal noch so in der Update-Anleitung dokumentieren…
Dann sollte in der Anleitung stehen, dass das “^” vor dem 6.0.0 weg muss. Dann kann man die Updates kontrollieren und auf die Version updaten, auf die man will.
Oder liege ich falsch? 
Bzw in der Version die ich nutze wird eben kein Exact Version Contrains benutzt. Wird das geändert oder muss das jeder selbst ändern?
Du hat recht: Ich hab grad beide Varianten, also Caret Version Range (ziehe automatisch alles bis zur nächsten Major) wie auch Exact Version Contraint gefunden. Ich versuch mal, dazu noch mehr Infos ranzubekommen bzw. das ggf. auch in Code oder Doku etwas konsistenter gestalten zu lassen
1 Like
In der Installationsanleitung ist --no-dev der Standard, Installation mit Dev-Tools wird in einem Extra Abschnitt beschrieben.
Hm also oxid-esales/oxideshop-metapackage ist doch immer mit caret.
Lass uns nächste Woche nochmal per PN besprechen, Frank, damit dort etwas mehr Klarheit reinkommt
@Martin-Hot, ich schliesse mich voll Deiner Meinung an.
Da wir hier ja in einer Diskussion stehen, wie ein Update mit composer läuft und wo es hakt, gebe ich mal meine Erfahrung dazu:
Testumgebung Server Debian 8.
-
Jan-2018 Server verfügbare php 5.6, 7.0, 7.1
Oxid Installation v600 in Verzeichnis mit php 7.0
Composer installiert alles problemlos. -
Feb-2018 Server verfügbare php 5.6, 7.0, 7.1, 7.2 (also autom. neu 7.2. nach ServerUpdate)
Oxid Update v600 auf v601 in Verzeichnis mit php 7.0
composer update --no-plugins --no-scripts
Your requirements could not be resolved to an installable set of packages.
Problem 1
- amzn/amazon-pay-sdk-php 3.1.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
- amzn/amazon-pay-sdk-php 3.1.0 requires ext-curl * -> the requested PHP extension curl is missing from your system.
- oxid-esales/oxideshop-metapackage-ce v6.0.1 requires amzn/amazon-pay-sdk-php 3.1.0 -> satisfiable by amzn/amazon-pay-sdk-php[3.1.0].
- Installation request for oxid-esales/oxideshop-metapackage-ce ^v6.0.1 -> satisfiable by oxid-esales/oxideshop-metapackage-ce[v6.0.1].
To enable extensions, verify that they are enabled in your .ini files:
- /etc/php/7.2/cli/php.ini
- /etc/php/7.2/cli/conf.d/10-opcache.ini
…
PROBLEM-LÖSUNG:
php -v zeigt php 7.2 ist Server default.
A. Dann setze ich Server default auf php 7.0
Damit läuft das Update natürlich problemlos.
B. Oder müsste die composer.phar in jedem Shop-Verzeichnis mit verschiedener php-Version liegen?
Das habe ich noch nicht getestet.
Für Oxid 600 sollte aber im Verzeichnis unter php 7.0 ein Update möglich sein.
Wie dem auch sei, eine GUI-Lösung mit Optionen wäre auf jeden Fall einfacher = userfreundlich.
Da steht doch genau, wo das Problem ist: die curl-Extension für PHP 7.2 ist nicht installiert.
Einfach mit apt install php7.2-curl installieren
Das ist schon klar so wie es dort steht aber Oxid 600 braucht doch überhaupt keine php7.2 (die durch ein ServerUpdate autom. installiert wurde) sondern php7.0, die ja im Shopverzeichnis eingestellt ist. Wozu hängt er sich daran auf? Der Shop läuft in dieser Situation problemlos nur das Update nicht.
Das hat mit dem Verzeichnis nichts zu tun, wenn durch das Update PHP 7.2 als CLI eingestellt ist, nutzt Composer das auch
Caret wird entfernt, und wir nutzen bis auf Weiteres nur fixed version
1 Like
Darf ich wissen wo man die Infos her bekommt? Wäre super zu wissen welche Version immer die aktuelle ist.
1 Like
Ja natürlich:
- Hier folgen oder z.B. per RSS-Feed direkt den Release Notes, zumindest aber den Security Issues.
- Diese Ansagen werden hier verteilt:
** Forum (rechts oben über den kleinen Kreis Benachrichtigungen erhalten)
** Mailingliste (funktioniert aktuell leider nicht, muss schnell operiert werden)
** Linkedin-, XING, Facebook-, Google+-Gruppen, Twitter, (noch) Skype-Chat
Allerdings bin ich mit dem Release wahrscheinlich erst morgen durch. Die Jungs schauen schon mal direkt auf GitHub nach oder werden bei (PE/EE/Partner-Agenturen) direkt per E-Mail benachrichtigt.
1 Like