iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014 edited November 2

Hallo Leute,

ich wollte heute das aktuelle Update einspielen, da ich den Shop erst noch im Aufbau habe und teste.

Leider bricht das Update jedesmal vor der Datenbank-Migration ab (Dialog: 1/3 Dateien werden überschrieben), weil das Update einfach so Vendor-Dateien löscht und dann prüft, ob diese da sind.
Das habe ich jetzt mit Dateien im Ordner /vendor/monolog und /vendor/mtdowling durch und habe vorher immer geprüft, ob die Dateien vor dem Update auch wirklich da waren.

Ist das bekannt?
Kann man das Update auch ander einspielen?

 

Error
Received an error message.
URL: unpack?offset=0&total=0
Message: Internal Server Error

Please try to fix this error and restart the update.
Response
{"code":0,"message":"The file \"vendor\/mtdowling\/jmespath.php\/src\/JmesPath.php\" was not supposed to exist.","file":"\/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/knplabs\/gaufrette\/src\/Gaufrette\/Filesystem.php","line":63,"trace":"#0 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/Steps\/UnpackStep.php(111): Gaufrette\\Filesystem->rename('files\/update\/fi...', 'vendor\/mtdowlin...')\n#1 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/Controller\/BatchController.php(90): Shopware\\Recovery\\Update\\Steps\\UnpackStep->run(0, 3806)\n#2 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/app.php(91): Shopware\\Recovery\\Update\\Controller\\BatchController->unpack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#3 [internal function]: Closure->{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#4 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Handlers\/Strategies\/RequestResponse.php(40): call_user_func(Object(Closure), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#5 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Route.php(281): Slim\\Handlers\\Strategies\\RequestResponse->__invoke(Object(Closure), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Array)\n#6 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(117): Slim\\Route->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#7 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/Route.php(268): Slim\\Route->callMiddlewareStack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#8 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(503): Slim\\Route->run(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#9 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/src\/app.php(66): Slim\\App->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#10 [internal function]: Closure->{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#11 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/DeferredCallable.php(57): call_user_func_array(Object(Closure), Array)\n#12 [internal function]: Slim\\DeferredCallable->__invoke(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#13 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(70): call_user_func(Object(Slim\\DeferredCallable), Object(Slim\\Http\\Request), Object(Slim\\Http\\Response), Object(Slim\\App))\n#14 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/MiddlewareAwareTrait.php(117): Slim\\App->Slim\\{closure}(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#15 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(392): Slim\\App->callMiddlewareStack(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#16 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Common\/vendor\/slim\/slim\/Slim\/App.php(297): Slim\\App->process(Object(Slim\\Http\\Request), Object(Slim\\Http\\Response))\n#17 \/var\/www\/web749\/html\/vendor\/shopware\/recovery\/Update\/index.php(36): Slim\\App->run()\n#18 \/var\/www\/web749\/html\/public\/recovery\/update\/index.php(6): require_once('\/var\/www\/web749...')\n#19 {main}"}

 

1 Answer

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    PROBLEM GELÖST!!!

    Nach langem hin und her habe ich das Problem lösen können.

    Es lag am aktiven OP-Cache von PHP 7.4.
    Nachdem dies deaktiviert lief das Update problemlos durch.

    Quote
    Accepted Answer
  • Accepted Answer

Answers

  • SoundySoundy MemberComments: 9 Received thanks: 0 Member since: October 19

    Habe frische Shopware 6 6.3.2.0 gehabt, bei mir lief das Update so durch.

    Dh. er löscht dieses, während er das Update durchführt? 

    Sieht aus, als wenn das alles sein könnte.. hast du berechtigungen von Verzeichnissen andes als Default?

    Welche Umgebung hast du?

    (meine: Debian 10, PHP 7.3.19,  Apache/2.4.38, MariaDB 10.3.23, Krnl Debian 4.19.132-1 (2020-07-24) x86_64)

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    Ich habe auch frisch die 6.6.3.2.0 installiert, welche bei mir beim Hoster läuft (PHP 7.4.3, MySQL 5.7.29, Apache).

    Sschreibrechte sind alle i.O. und wurden nicht geändert (Verz. 755).

  • SoundySoundy MemberComments: 9 Received thanks: 0 Member since: October 19

    Hm, puh.. 

    Da ich ganz frisch hier in der Shopware Sache bin, kann ich dir da nicht weiterhelfen. Das müsste sich ein Admin / Dev anschauen.

    Ich würde ein Ticket beim Bug Tracker aufmachen

    https://issues.shopware.com/?products=SW-6&edition=platform,starterEdition,professionalEdition,enterpriseEdition&projects=all&type=1,4&status=open,inProgress,done

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9663 Received thanks: 2921 Member since: September 2013

    Warum nicht einfach die Datei manuell löschen und Update nochmal ausführen?

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    Welche Datei manuell löschen?

    Das Problem kommt bei jedem Updateversuch?

    Habe es schon 3x probiert.

  • Moritz NaczenskiMoritz Naczenski AdministratorsComments: 9663 Received thanks: 2921 Member since: September 2013
    "The file \"vendor\/mtdowling\/jmespath.php\/src\/JmesPath.php\" was not supposed to exist."

    Da Ist ja der Fehler, wenn die Datei nicht existieren sollte, würde ich die mal manuell löschen.

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    Wenn sie nicht existiert soll ich sie löschen?

    Wie das, wenn sie nicht existiert?

    Der Updateprozess löscht sie doch selber und meldet danach, das sie fehlt.

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    Kann mann denn das Update auch anders als über den Updatemanager einspielen?

  • iceman_fxiceman_fx MemberComments: 20 Received thanks: 1 Member since: August 2014

    PROBLEM GELÖST!!!

    Nach langem hin und her habe ich das Problem lösen können.

    Es lag am aktiven OP-Cache von PHP 7.4.
    Nachdem dies deaktiviert lief das Update problemlos durch.

    Quote
    Accepted Answer
Sign In or Register to comment.