Update 6.5.4 auf 7.0.0 PHP-Blockade (Erweiterung deinstallieren?)

Hallo Leute,
ich wende mich heute an Euch weil ich mit einem Problem nicht weiter komme.

Ich hatte bis vor kurzem einen OXID - Onlineshop in der CE-Edition
auf meiner Website laufen in Version 6.4.1 (sehr veraltet)
Da mein Hostinganbieter den Server gewechselt hat,
musste unter anderem auch dieser Onlineshop übertragen werden
was nach vielem hin und her dann auch geklappt hat.
Ich habe den Shop nun auf dem neuen Server bis auf Version 6.5.4 updaten können,
nun steht das Update auf 7.0.0 an.
Genau hier habe ich nun ein Problem.
(Ich bin Hobbyadmin, hab mir alles selbst beigebracht,
(bin hauptberuflicher Handwerker) also entschuldigt bitte meine Amateurfragen.)

Wenn ich jetzt auf 7.0.0 updaten will per Composer, gibt es ein Problem mit der PHP-Version.
Stelle ich die PHP-Version auf die hier aufgeführte Version 8.0.3,
bekomme ich die angehängte Fehlermeldung vom Composer…

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - symfony/yaml[v4.0.0, ..., v4.4.8] require php ^7.1.3 -> your php version (8.0.30) does not satisfy that requirement.
    - symfony/yaml[v5.0.0, ..., v5.0.8] require php ^7.2.5 -> your php version (8.0.30) does not satisfy that requirement.
    - symfony/yaml[v6.1.0, ..., v6.3.0] require php >=8.1 -> your php version (8.0.30) does not satisfy that requirement.
    - codeception/codeception[4.1.9, ..., 4.2.2] require symfony/yaml >=2.7 <6.0 -> satisfiable by symfony/yaml[v2.7.0, ..., v2.8.52, v3.0.0, ..., v3.4.47, v4.0.0, ..., v4.4.45, v5.0.0, ..., v5.4.44].
    - oxid-esales/testing-library[v8.0.0, ..., v8.1.0] require symfony/yaml ~3.0 -> satisfiable by symfony/yaml[v3.0.0, ..., v3.4.47].
    - You can only install one version of a package, so only one of these can be installed: symfony/yaml[2.0.4, ..., v2.8.52, v3.0.0, ..., v3.4.47, v4.0.0, ..., v4.4.45, v5.0.0, ..., v5.4.44, v6.0.0, ..., v6.4.12, v7.0.0, ..., v7.1.5].
    - oxid-esales/oxideshop-metapackage-ce v7.0.0 requires symfony/yaml v6.0.19 || v6.2.10 -> satisfiable by symfony/yaml[v6.0.19, v6.2.10].
    - codeception/codeception[4.0.0, ..., 4.1.8] require php >=5.6.0 <8.0 -> your php version (8.0.30) does not satisfy that requirement.
    - Root composer.json requires oxid-esales/oxideshop-metapackage-ce v7.0.0 -> satisfiable by oxid-esales/oxideshop-metapackage-ce[v7.0.0].
    - oxid-esales/testing-library v8.2.0 requires codeception/codeception ^4 -> satisfiable by codeception/codeception[4.0.0, ..., 4.2.2].
    - Root composer.json requires oxid-esales/testing-library ^v8.0.0 -> satisfiable by oxid-esales/testing-library[v8.0.0, ..., v8.2.0].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
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.

Stelle ich die PHP-Version auf 7.4.33, meckert der Composer,
dass der WYSIWYG-Editor mindestens PHP 8.0 haben will…
Ich kann das Update also mit keiner der beiden Versionen abschließen.
Ich habe testweise mal den Editor im OXID-Backend deaktiviert,
der Composer meckert trotzdem, weil der Editor scheinbar trotzdem aktualisiert werden soll.

Meine Idee ist nun, den Editor vorübergehend zu deinstallieren,
das Update auf 7.0 zu machen und dann wieder in aktueller Version zu installieren.
Das Problem ist, ich weiß leider nicht wie das geht.
Ich habe bereits viele Websites durchstöbert, finde aber keine passende Lösung,
daher wende ich mich heute mal an Euch.

Der neue Server arbeitet mit der “Plesk” -Oberfläche, SSH-Zugang habe ich,
Composer ebenfalls als zusätzliche Funktion.

Ich hoffe ihr könnt mir helfen den Shop auf aktuellen Stand zu bringen.

Ich hab noch im Kopf dass ich mal bei Composer-Updates mehr als nur die
gewünschte Shopversion in die json-Datei eintragen musste, aber das ist Jahre her…

Ich bin für jeden Grashalm dankbar :slight_smile:

Hallo a.eisermann,

hast Du probiert, die php Version auf 8.1 zu setzen im composer.json?

Versuche mal die im Erklärungstext vorgeschlagene -W Option an Deinem Updatebefehl. Composer darf dann auch andere Abhängigkeiten aktualisieren, die mglw. wegen der PHP-Version ebenfalls ein Update bräuchten, aber nicht ausdrücklich benannt sind.

Ich kenne die Funktionsweise der json-Datei leider nicht genau, weiß nur dass ich dort die gewünschte Shopversion eintragen muss.
Den angegebenen Wert von 8.0.0 der darin steht habe ich testweise mal auf 8.1.0 geändert,
das änderte aber nichts daran, dass symfony eine 7er-Version von PHP verlangt.

1 Like

Das werde ich mal versuchen, danke für den Hinweis.
Das muss ich dann manuell per SSH-Console erledigen,
die meisten Aktualisierungen habe ich über den “Aktualisieren”-Button durchführen können.

Ich hab mal mein Glück versucht, aber entweder es funktioniert nicht,
oder ich habe den Befehl falsch verwendet, da mir die Option weiterhin ganz unten angezeigt wird.
Ich nehme an, ich muss einen Teil des Befehls weglassen, da diese sich evtl. wiedersprechen.

Hier ein Screenshot meines Updatebefehls und dessen Auswirkungen

In Deiner CLI-Ausgabe sehe ich, dass Dein Projekt noch die OXID Testing Library erfordert / aktualisieren will. Die gibt es für den 7er Shop jedoch nicht mehr. Daher solltest Du die vorher entfernen. Mit etwas Glück sollte Composer dann in der Lage sein, ein gültiges Package Set zusammenzustellen.

Danke für den Hinweis, dann werde ich mich mal schlau lesen wie ich das mache.
Ich hatte schon versucht etwas über symfony heraus zu finden,
aber hab leider nicht viele Infos dazu gefunden.
Der Syntax des verwendeten Update-Befehls passt aber,
oder muss ich einen Parameter weglassen, dass alle Abhängigkeiten aktualisiert werden?

Die Arbeit mit Symfony kannst Du Dir sparen. Detailwissen brauchst Du für das Shopupdate nicht. Composer muss nur auf Basis der Anforderungen eines jeden Pakets eine gültige Zusammenstellen bauen können.

Beim Update von 6.x zu 7.x wird es auch noch andere externe Pakete geben, die ein Update brauchen. Der -W Parameter ist daher mit Sicherheit nicht verkehrt.

Hallo Leute,
nachdem ich nun mehrere Stunden versucht habe eine Lösung für mein Problem zu finden
stehe ich aktuell wieder an der gleichen Stelle wie vorher,
nachdem ich mein Backup wieder herstellen musste,
weil ein weiteres Problem durch “Try and Error” hinzu gekommen ist.

Um vielleicht Usern mit ähnlichen Problemen weiter zu helfen,
oder zumindest einen Suchansatz zu geben,
schreibe ich mal auf was ich inzwischen versucht habe.

Über diese Website bin ich auf die Datenbank hingewiesen worden, speziell die Tabelle “oxconfig”
diese habe ich dann auch durchsucht nach Infos auf die ID der “testing-library”,
leider ohne Erfolg…

Als nächstes landete ich in der “composer.json” und löschte die Einträge
in den letzten Zeilen, natürlich unter Beachtung des Syntax…

  },
  "extra": {
    "incenteev-parameters": {
      "file": "test_config.yml",
      "dist-file": "vendor/oxid-esales/testing-library/test_config.yml.dist",
      "parameter-key": "mandatory_parameters",
      "env-map": {
        "shop_path": "SHOP_PATH",
        "shop_tests_path": "SHOP_TESTS_PATH",
        "partial_module_paths": "PARTIAL_MODULE_PATHS"
      }
    }

Das funktionierte auch durchaus, führte aber am Ende zum weiteren Problem.

Die Entfernung der Einträge in der .json führte scheinbar dazu,
dass weitere Änderungen nicht mehr vorgenommen konnten.

Viele weitere Anpassungen endeten immer wieder mit der gleichen Meldung,
daher machte es wenig Sinn mit diesen Daten weiter zu arbeiten.
Alle Daten auf dem Server gelöscht,
Backup von Daten und DB erneut eingespielt. also alles von vorn.

Nach weiterem suchen fand ich dann diese Website:
https://docs.oxid-esales.com/developer/en/latest/development/modules_components_themes/module/uninstall/index.html

Ich dachte, ich hätte die Lösung gefunden um die veralteten Module zu deinstallieren…

Ich nutzte Befehle wie

composer remove oxid-esales/testing-library

composer remove oxid-esales/flow-theme

composer update --no-plugins --no-scripts --no-dev --with-all-dependencies

composer update --no-dev

vendor/bin/oe-eshop-db_migrate migrations:migrate


Wie ich nun leider feststellen muss, habe ich damit scheinbar gar nichts erreicht,
auch wenn die Console bei jedem Befehl ordentlich gerattert hat.
Bei mir sieht es aktuell so aus…

Die testing-library ist weiterhin vorhanden und auch symfony fordert weiterhin die alte php-Version…
Alles so als hätte ich nichts getan die letzten Tage…

Es kann doch nicht so schwer sein ein kleines Modul zu deinstallieren,
bevor man ein Update installiert.
Der Shop läuft ja auch so, doch das ist keine Endlösung für mich.

Was mache ich denn falsch?

Hallo a.eisermann
Ich denke, das liegt daran, dass Du lokal die falsche Version von PHP nutzt.
Versuche deinen PHP Interpreter auf v7 zu downgraden. Dann wiederhole die installation.