aktualisiert wurde via Composer und dieser Anleitung. PHP Versionen 7.1.33, sind gleich.
Im Ordner …/source/modules (ftp), sind die Files der Module vorhanden, aber im Backend Erweiterungen->Module werden sie nicht gelistet.
Du hast wirklich alle Schritte der Anleitung ausgeführt und alle wurden erfolgreich / ohne Fehlermeldung beendet?
Insbesondere php vendor/bin/oe-console oe:oxideshop-update-component:install-all-modules
Angeblich braucht OXID 6.2 auch PHP Version >= 7.3, so dass es mit 7.1 hätte nicht klappen dürfen.
ja , alle Schritte ausgeführt. Aber bei der Modul Aktualisierung waren schon einige rot hinterlegt, bzw. die Module ich ich erworben habe und schmerzlich vermisse.
Nachtrag: sehe gerade das unter ->Diagnosewerkzeug folgendes zu finden ist
Server-Konfiguration
OK PHP Version 7.1 and 7.4
OK Apache mod_rewrite Modul
OK Dateizugriffsrechte
OK MySQL Version 5.5 oder 5.7
Bei Systemgesundheit steht folgendes:
Es werden unterschiedliche Kollationen für die ID-Felder verwendet:
- oxuser
- OXCOUNTRYID - latin1_general_cs
Evtl. ist das Verzeichnis var nicht beschreibbar.
Das Verzeichnis /var hat bei mir 775.
Nun habe ich auf php 7.3.x umgestellt.
interessant wäre wie Deine 1.yaml Datei aussieht, sind dort die vermissten Module enthalten? Kamen Fehlermeldungen beim Update mit Composer?
in der 1.yaml sind die vermissten Module nicht zu finden. Fehlermeldungen nur rote Hinterlegungen beim Modul update.
Also mir fehlen zum aktivieren folgende Module. dwa, ecs, sit_import_manager, sit_module_framework.
Wie bekomme diese Aktiviert, sind leider nicht in der Liste (Backend) der Module aufgeführt, das wäre ja zu einfach.
Außerdem habe ich da noch den Konflikt
Dies wird die Ursache sein, wahrscheinlich sind die Module nicht kompatibel mit der neusten Shopversion 6.2.1 - daher bitte an Modulhersteller wenden.
ok, danke. Ich schreibe die drei Modulhersteller an, bin mal gespannt wie es weiter geht.
fast vergessen was ist mit der DB Kollationen?
Die unterschiedlichen Kollationen in den ID-Felder dürften keine Rolle spielen, weil da nur Hexadezimalzahlen als String drin stehen, und die enthalten keine Sonderzeichen, sondern nur Ziffern 0…9 und a…f und deren Codierung ist in latin und utf gleich.
hast du mal probiert manuell ein modul zu installieren?
@m431342, ok Danke. Dachte halt das dies evtl. mit dem seltsamen Verhalten in Win 10 und Firefox zusammenhängen könnte, nur da habe ich das Problem dass, der Login (Backend) sich immer wiederholt, und ich auf den Explorer ausweichen muss um ins Backend zu kommen. sobald ich jedoch Malewarebyte darüber laufen lasse, mit anschließenden Neustart, geht es zumindest genau einmal.
@tabsl, ja habe ich auch schon versucht z.B. bei dwa hier habe ich auch für den Moment nicht’s anderes
$ vendor/bin/oe-console oe:module:install source/modules/dwa/dwa_invoicemail
An error occurred while installing module configuration.dann musst du wohl mal debuggen … InstallModuleConfigurationCommand::execute()
Was m.E. nicht unbedingt heißt das es vom Webserver beschreibbar ist.
@tabsl, setzte ich vor ‘InstallModuleConfigurationCommand::execute()’ ein composer? Sorry so fit bin ich noch nicht.
@indianer3c, du hast recht, in allen drei Modulen von dwa, gibt es keine composer.joson, bzw *.joson
jetzt habe ich es geschafft, statt Backend Login große weise leere Seite. 
Nachtrag: nach composer update läuft das Backend wieder
Composer.json ist nicht notwendig bei Metadata 1.x. Die Metadata-Version muss jetzt allerdings immer in metadata.php stehen.