Composer Update Shop auf 6.3.0 - symfony/filesystem[v4.4.21]

Danke @indianer3c

von da komme ich ja aus der Anleitung: composer update --no-plugins --no-scripts --no-dev

Sehe ich das richtig, dass oxid-esales/oxideshop-ide-helper nicht installiert wird, da das symfony/filsystem nicht installiert / kompatibel ist?
…und wenn ja… kann ich einfach die Einträge:
“symfony/event-dispatcher”: “^3.4”,
“symfony/dependency-injection”: “^3.4.26”,
“symfony/config”: “~3.3|~4.0”,
“symfony/yaml”: “~3.4|~4.0”,
“symfony/expression-language”: “^3.4”,
“symfony/lock”: “^3.4”,
“symfony/console”: “^v3.4.15”,
“webmozart/path-util”: “^2.3”,
“symfony/finder”: “^3.4”,
“symfony/filesystem”: “^3.4”,
“oxid-esales/flow-theme”: “^v3.4.1”,
in die composer.json reineditieren?
oder sollte ich einmalig die komplette:

übernehmen?

Wenn man wie in der Dokumentation Standard-Update — OXID eShop 6.3 | Anwenderdokumentation
‘composer require --no-update oxid-esales/oxideshop-metapackage-ce:v6.3.0’
ausführt, ändert sich zwar die OXID Version aber nicht die Abhängigkeiten unter “require-dev”! So gewollt oder Bug?
Entweder man löscht den Teil ganz, wenn der nicht gebraucht wird oder ändert händisch.

Ja, der --no-dev Parameter dazu da Pakete die nur zur Entwickung benötigt werden wegzulassen weil die für den LIVE Betrieb des Shops nicht notwendig.

Dies mag ein Grund sein, oder weil sich das Rad weiter dreht und diese Pakete zur Entwicklung nicht mehr benötigt werden.

Nein, man macht dort einen Vergleich was sich geändert und ändert nur die Stellen welche für den jeweilgen Shop relevant sind.

Die composer.json ist für jeden Shop mit der Zeit individuell und anders. Weil jeder Shop andere Module nutzt, andere Pakete…

Das kein Bug, dies war schon immer so. Der --no-update Paramter sorgt nur dafür, dass nach Aktualisierung der composer.json nicht anschließend das Vendor Verzeichnis aktualisiert wird. Dies passiert im nachgelagerten Update Schritt.

Dies kann man machen wie man möchte, man ist dort frei in seiner Entscheidung.

Wenn eine neue Version, hier die v6.3.0 neue Abhängigkeiten verlangt, dann müssen die doch aber auch in der composer.json geändert werden!
Ansonsten passiert beim 2. Update Schritt das:

’ Problem 1
- Root composer.json requires oxid-esales/oxideshop-ide-helper ^v3.1.2 → satisfiable by oxid-esales/oxideshop-ide-helper[v3.1.2].
- oxid-esales/oxideshop-ide-helper v3.1.2 requires composer-plugin-api ^1.1.0 → found composer-plugin-api[2.0.0] but it does not match the constraint.
Problem 2
- oxid-esales/testing-library[v7.2.0, …, v7.3.0] require symfony/filesystem ^3.0 → satisfiable by symfony/filesystem[v3.0.0, …, v3.4.47].
- You can only install one version of a package, so only one of these can be installed: symfony/filesystem[v2.3.0, …, v2.8.52, v3.0.0, …, v3.4.47, v4.0.0, …, v4.4.22, v5.0.0, …, v5.2.7].
- oxid-esales/oxideshop-metapackage-ce v6.3.0 requires symfony/filesystem v4.4.21 → satisfiable by symfony/filesystem[v4.4.21].
- Root composer.json requires oxid-esales/oxideshop-metapackage-ce v6.3.0 → satisfiable by oxid-esales/oxideshop-metapackage-ce[v6.3.0].
- Root composer.json requires oxid-esales/testing-library ^v7.2.0 → satisfiable by oxid-esales/testing-library[v7.2.0, v7.3.0].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

You are using Composer 2, which some of your plugins seem to be incompatible with. Make sure you update your plugins or report a plugin-issue to ask them to support Composer 2.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.

Ist das nur bei mir so? Kann ich fast nicht glauben!

Wenn man
“require-dev”: {
“oxid-esales/testing-library”: “^v8.0.0”,
“incenteev/composer-parameter-handler”: “~v2.0”,
“oxid-esales/oxideshop-ide-helper”: “^v4.1.0”
}, in der composer.json händisch ändert funktionioniert das Update!

Ja, die Composer Dateien composer.json und composer.lock sind doch entscheidend.

Man kann die composer.json über die CLI ändern oder manuell.

Die composer.lock ist wichtig um den identischen Versionsstand installieren zu können.

Ah okay, dann muss man auch die Dev-Requirements aktualisieren.

Was kannst du nicht glauben?

Das nur bei mir das Update hängen bleibt, wenn ich mich an die Doku halte.

Ich denke, Du bist nicht allein.

hi all

ich bin hier auch hängen geblieben und habe mich geärgert, dass die Doku zum Update von 6.2.x auf 6.3.0 nicht aktualisiert wurde. Ich habe mir dann die Infos aus der json einer Neu- Installation geholt.

Die Antwort ist oben zwar schon gegeben aber hier mal dennoch noch die Änderungen im require-dev:

“require-dev”: {
“oxid-esales/testing-library”: “^v8.0.0”,
“incenteev/composer-parameter-handler”: “^v2.0.0”,
“oxid-esales/oxideshop-ide-helper”: “^v4.1.0”,
“oxid-esales/azure-theme”: “^v1.4.2”
},

Damit hat das Composer update dann geklappt.

Warum habe ich mich geärgert? Weil ich kein hauptberuflicher Entwickler (sondern technischer Redakteur) bin und bei der Pflege des Shops auf saubere Dokumentation angewiesen bin. Ich habe daher die Bitte an das Oxid Team, diese Updates immer zeitnah auch zu dokumentieren…

2 Likes

Danke, das gebe ich so weiter. Wenn einem so etwas auffällt, kann man auch selbst Hand anlegen und hier einen Pull Request schicken :wink:

Glaube hier gewaltig was durcheinander geraten siehe auch Update CE 6.1 auf CE 6.2: Version testing-library

Zum Verständnis wenn man sich das Projekt ausscheckt am Beispiel einer OXID eShop Community Edition 6.2 Serie

  1. dann nimmt man den Branch “b-6.2-ce” oxideshop_project/composer.json at b-6.2-ce · OXID-eSales/oxideshop_project · GitHub in diesem ist die Metapackage Version definiert “6.2.4”

  2. Metapackage Tag Version 6.2.4 oxideshop_metapackage_ce/composer.json at v6.2.4 · OXID-eSales/oxideshop_metapackage_ce · GitHub enthält die Versionsnummer vom Shop

  3. Shop Versionsnummer Dev-Requires für die Test-Library oxideshop_ce/composer.json at v6.7.0 · OXID-eSales/oxideshop_ce · GitHub

Update: Hat sich im anderen Ticket gelöst, das Caret ^ stellt sicher, dass immer die neuste Version genommen wird von 7.0 bis 7.3. Aber ab 8.0 Version braucht es eine Anpassung in der composer.json.

@akademiker super habe das gleiche Problem mit deiner Antwort lösen können. Composer update … lief durch.

Bis auf einige gelbe Hinweise nach $ composer update --no-dev

Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Package sebastian/resource-operations is abandoned, you should avoid using it. No replacement was suggested.

und 

Class Incenteev\ParameterHandler\ScriptHandler is not autoloadable, can not call post-update-cmd script

Außerdem stelle ich gerade fest das bei einigen Sachen im Backend Bereich (Admin-GUI) statt des angewählten Punktes einfach die Front-End-Seite angezeigt wird. Bis jetzt so bei den Modulen und bei Diagnosewerkzeug nach klick auf Diagnose starten.

oje, wie immer ganze Arbeit. Nochmals ein ‘composer update’ los gelassen, seither Page nicht mehr erreichbar bzw. nur noch weise leere Seite. Und das im Front sowie Backend. Sauber und nun??

Log-Datei einsehen.

in der error.log steht unter anderem folgendes:

Stack trace:
#0 /myhome/my_oxid_eshop_project/vendor/composer/autoload_real.php(75): Composer\Util\ErrorHandler::handle(2, 'require('/myhome/...', 75, Array)
#1 /myhome/my_oxid_eshop_project/vendor/composer/autoload_real.php(75): require()
#2 /myhome/my_oxid_eshop_project/vendor/composer/autoload_real.php(65): composerRequire123225b2628faa9c66fe09094c82cb07('25072dd6e247008...', '/myhome/...')
#3 /myhome/my_oxid_eshop_project/vendor/autoload.php(7): ComposerAutoloaderInit123225b2628faa9c66fe09094c82cb07::getLoader()
#4 /myhome/my_oxid_eshop_project/vendor/oxid-esales/oxidesho in /myhome/my_oxid_eshop_project/vendor/composer/autoload_real.php on line 75
[26-Jul-2021] PHP Fatal error:  composerRequire123225b2628faa9c66fe09094c82cb07(): Failed opening required '/myhome/my_oxid_eshop_project/vendor/composer/../symfony/polyfill-php72/bootstrap.php' (include_path='/myhome/my_oxid_eshop_project/vendor/symfony/yaml:.:/opt/alt/php73/usr/share/pear') in /myhome/my_oxid_eshop_project/vendor/composer/autoload_real.php on line 75

Puuuh. Ich würde den vendor löschen oder umbenennen und

composer update --no-dev

versuchen.

ok, vendor in vendor_old umbenannt,

$ composer update --no-dev            Loading composer repositories with package information
Updating dependencies


  [UnexpectedValueException]
  RecursiveDirectoryIterator::__construct(./vendor/zip): failed to open dir:
  No such file or directory


update [--with WITH] [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--no-autoloader] [--no-scripts] [--no-suggest] [--no-progress] [-w|--with-dependencies] [-W|--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

Da versucht er auf zip zuzugreifen. Ich habe noch nie mit einem leeren vendor nur mit zip als Inhalt versucht. Könnte auch gehen.
Ansonsten probiere:

composer update --no-dev --no-interaction

leider nein unverändert, bin gerade dabei den vendor Ordner, den vor dem Update gesichert wurde, rein zu kopieren, bin gespannt ob das funktioniert.

Ein wenig Heureka, also nachdem ich den vendor Ordner (vor Update) rein kopiert habe, funktionierte das Back- und Front- End wieder, allerdings in der oxid Version 6.2.1-

Dann habe ich nach Anleitung von oxid docs das update auf 6.3.0 durchgeführt, Backend und Frontend sind zumindest aufrufbar.

Allerdings wie zuvor bei zwei Backend Zweigen (Module und Diagnose) habe ich dennoch das Problem das anstatt die gewählte Funktion sich die Startseite des Shops öffnet. Wäre Toll dafür auch noch eine Lösung zu finden.