Bin dabei die Migration meines Shops von CE 6.1.1 auf CE 6.2.0 vorzubreiten. Dabei ist mir aufgefallen, dass es zwischen der deutschen und der englischen Updatedokumentation einen Unterschied gibt:
Die Dokumentation wurde an dieser Stelle sicherlich erst neulich ergänzt aufgrund des Forums, da wird es zu einem Fehler bzw. Unkenntniss gekommen sein.
Beide Notationen sind korrekt denn das Caret (Versions and constraints - Composer) besagt, das die aktuellste 7.x Version der testing-library gezogen wird. Also immer die neuste die < 8.0.0 ist!
^7.0.1 und ^7.1.0 markieren nur den Startpunkt, aktuell wird für beide 7.3.0 gezogen.
Könnt Ihr per composer info | grep testing prüfen nach dem Ihr ein composer update durchgeführt habt.
Besten Dank für die Antworten auf meine Ursprungsfrage. Die meisten Antworten verstehe ich nur der Spur nach und mein Problem ist unverändert ungelöst:
Ich möchte meinen tivial einfachen Shop von OXID 6.1.1 auf die OXID 6.3.0 aktualiseren. Nach meinem Verständnis geht das nur in zwei Schritten: Zuerst auf 6.2.x und danach auf 6.3.x.
Frage: Muss ich im ersten Schritt auf 6.2.0 oder auf 6.2.4 aktualiseren? Wo finde ich die für diesen Schritt die korrekten composer.json Einträge fur ‘require’ und ‘require-dev’?
Deine Kernfrage wurde beantwortet, indem es durch das Caret Zeichen ^ egal ist ob der englischen oder deutschen Dokumentation folgst. Es sollte
“oxid-esales/testing-library”: “^v7.0.1”
und
“oxid-esales/testing-library”: “^v7.1.0”
funktionieren.
Beim öffentlichen Packagist Paket Verzeichnis stehen Rechts unten die potenziellen Versionen für das Paket oxid-esales/testing-libraryoxid-esales/testing-library - Packagist
Composer entscheidet anhand Deines individuellen Abhängigkeitsbaum welche Version es nimmt. Dabei wird Composer in diesem Fall immer probieren die 7.3.0 zu verwenden.
Offtopic ON (wenn alles andere schief geht…)
…gäbe es auch nen anderen Weg, der von 4.10.8 ähnlich ist:
… wenn alle Module für >= 6.2x verfügbar sind, kannst folgendes versuchen:
Neuen Shop (6.3x) installieren. Alle Bilder, Media etc.pp. aus dem 6.1er 1:1 kopieren. SSH: cp -R …
Alte “Modulinfos” in “alter” Datenbank (6.1) entsorgen: phpMyAdmin:
delete from oxconfig where oxvarname in (
“aDisabledModules”,
“aLegacyModules”,
“aModuleFiles”,
“aModulePaths”,
“aModules”,
“aModuleTemplates”
);
Danach die config.inc.php auf die “alte” Datenbank umswitchen. Views updaten.
@rubbercut Danke auch für deine Antwort. An dieses Vorgehen habe ich auch schon gedacht aber ich würde es gerne vermeiden, da ich damit all Salesdaten verliere. @indianer3c Besten Dank für deine ausführliche und detailierte Auskunft; sehr hilfreich! Ich bin vorgegangen wie von dir dokumentiert. Hier der Kopf von composer.json:
Es gibt ein Versionsproblem mit ‘composer-plugin-api’; gefunden wird 2.0.0; benötigt wird ^1.1.0
Frage: Was habe ich übersehen, resp. wie kann ich dieses Problem beheben?
Und noch eine weitere Frage: In der Anleitung steht ‘Adapt the metapackage according to your edition’. Mir ist nicht klar was das bedeutet und ob dieser Schritt in meinem Fall überhaupt nötig ist (wie aus dem composer.json’ Extract ersichtlich ist verwende ich nur zwei Module: ‘ocbcleartmp’ und ‘pdf-invoice-module’).
Besten Dank für Antworten
Geronimo (Hannes Schmid)
Du hast glaube ich ein generelles Verständnisproblem bei Composer. Leider ist mit der Einführung es für technische Laien schwieriger geworden selber ein Update vornehmen zu können. Da man zuerst ein Grundverständnis aufbauen muss, was dabei hilft auf verschiedene Fehlerkonstellationen entsprechend reagieren zu können.
Du musst die Anleitung immer überdenken, Du kannst in Deinem Fall z.B. nicht einfach 1 zu 1 die Composer Anpassungen übernehmen. Dann müsstest oben bei der Version zumindest v6.2.0 setzen damit es wieder stimmig ist.
Dies bedeutet meine Anmerkung mit den 3 Schritten, dass dies im Einzelfall immer geprüft werden sollte wie die composer.json auszusehen hat. Dies von Shop zu Shop unterschiedlich, wenn Du z.B. weitere Module installiert hast oder gleich den Sprung auf v6.2.4 gehst etc.
Irgendwo erreicht der Support im Forum auch seine Grenze und im Zweifelsfall sollte dies beauftragt werden.
@indianer3c Hallo Tim, besten Dank für deine Antworten. Es ist auch mein Eindurck, dass ohne Detailkenntnisse über Composer nur eine geringe Chance besteht einen OXID Shop erfolgreich zu erstellen oder zu warten. Mit OXID gestartet bin ich noch vor Composer. Nach meiner Meinung müsste auf der OXID-Homepage an prominenter Stelle stehen:
Lassen Sie Finger vom OXID Shop wenn Sie diesen ohne fremde Hilfe und ohne Composer-Detailkenntnisse betreiben mochten. Sie werden auf die Schnauze fallen!
Das Groteske ist ja dass ich kein Laie bin sondern eine lange IT-Karriere hinter mir habe bei namhaften Banken im Application Layer. Leider bin ich dabei dem Composer nie begegnet. Hättest du mir einen Tipp wo ich mich über den Composer im OXID-Kontext schlau machen kann. Im Moment möchte ich noch nicht aufgeben!
Erste Anlaufstelle ist immer https://getcomposer.org/ und im Forum kann man über Probleme von Anderen auch viel lernen. Sicherlich bester Tipp stetige Weiterbildung und Alltagserfahrung.
Die Fehlermeldungen die Composer selbst ausspuckt meist am hilfreichsten. Genaues arbeiten erforderlich um Fehler zu vermeiden.
OXID eShop spezifisch noch erwähnenswert, dass Composer Version 2 erst mit Version 6.2.3 einzog und mit Version 6.2.4 erst PHP 8 Unterstützung. Weitere Infos unter Releases — OXID eSales Documentation
Oha dann habe ich es falsch verstanden, tatsächlich 6.2.4 unterstützt PHP 8.0 noch nicht. Gerade nochmal in E-Mail Release Benachrichtigung nachgelesen. Mein Fehler sorry
denn das Caret (
