wollte auf die neueste Version 6.3.1 updaten. Vorher inkompatible Updates deaktiviert, Backup der DB gemacht, aber nicht des Fileordners auf dem Server.
Update ist abgebrochen mit DB-Fehler (irgendwas mit CREATE TRIGGER… - nicht genau hingeschaut). Hinweis, man soll das Update wiederholen nach Korrektur.
Komme aber nicht so weit, weil seither nur noch der Wartungsmodus aufgerufen wird.
Restore der DB gemacht, Fileordner geht nicht, da mein Hoster leider keine Kundendateien sichert, wie ich grade erfahren habe.
Ich fürchte, da kannst du dir nur in die Abacke beißen und dich fragen, wieso du nicht auch die Dateien vorher backuppst. Und einen neuen Hoster solltest du dir auch schon mal raussuchen. Wenn du ganz crazy bist, versuch an die Version der Dateien vor dem Update zu kommen. Vllt gibt es da ja ein Archiv auf GitHub, keinen Plan… Ansonsten wünsche ich dir viel Kraft. Du hast dich getraut, SW6 einzusetzen, du bist mutig und stark, das schaffst du schon!
danke für die Antwort. Ein Teil vom A fehlt bereits
Soo viel Kraft brauche ich zum Glück nicht, da der Shop noch nicht produktiv war. Da bedarf es noch ein paar Releases von SW6, bis ich einen SW6-Shop auf Kunden loslassen will. Nur die ganze Vor- und Testarbeit ist dahin und darf nochmal gemacht werden. Manchmal reinigt sowas ja die Blindenbrille und man merzt im Neuaufbau noch manchen eigenen Fehler aus. Kann im Idealfall sogar hilfreich sein, von Null zu beginnen.
Mit Deinem Zuspruch wird das garantiert ein Leichtes!
ganz ehrlich würde ich niemals ein update fahren, wenn auch nur eines der plugins noch nicht so weit ist. selbst wenn es deaktiviert ist, spielt das womöglich noch irgendwo mit rein.
ich warte immer erst ein paar tage und dann schreibe ich die pluginhersteller an, die noch fehlen. bin jetzt seit februar dabei und diese strategie hat sich die monate über bewährt
Bei mir das Gleiche. 2 Installationen und bei beiden bricht das Update ab. Einmal auch mit der CREATE Trigger Fehlermeldung wie oben und einmal mit CREATE TABLE ‘language’ da TABLE ‘language’ schon existiert…Irgendwas ist doch bei dem Update nicht ganz ausgereift. Es gibt auch Leute die keine Probleme haben…wie kann das denn sein?
Error Received the following error message: An exception occurred while executing 'CREATE TRIGGER product\_listing\_price\_update BEFORE UPDATE ON product FOR EACH ROW BEGIN IF @TRIGGER\_DISABLED IS NULL OR @TRIGGER\_DISABLED = 0 THEN IF NEW.listing\_prices IS NOT NULL THEN IF JSON\_CONTAINS\_PATH(NEW.listing\_prices, 'one', '$.structs') = 1 THEN SET NEW.listing\_prices = NULL; END IF; END IF; END IF; END;': SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege and binary logging is enabled (you \*might\* want to use the less safe log\_bin\_trust\_function\_creators variable) Please try to fix this error and restart the update. Response {"valid":false,"errorMsg":"An exception occurred while executing 'CREATE TRIGGER product\_listing\_price\_update BEFORE UPDATE ON product FOR EACH ROW BEGIN IF @TRIGGER\_DISABLED IS NULL OR @TRIGGER\_DISABLED = 0 THEN IF NEW.listing\_prices IS NOT NULL THEN IF JSON\_CONTAINS\_PATH(NEW.listing\_prices, 'one', '$.structs') = 1 THEN SET NEW.listing\_prices = NULL; END IF; END IF; END IF; END;': SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege and binary logging is enabled (you \*might\* want to use the less safe log\_bin\_trust\_function\_creators variable)"}
Auf AWS RDS hat man auf der DB keine SUPER Privilegien. Der Tipp mit dem log_bin_trust_function_creators ist jedenfalls richtig uns löst das Problem (dafür braucht man eine neue Parameter Group).
Was ich etwas nervig finde: Danach lässt einen Shopware und auch die Anleitung ziemlich alleine wie man das Update zum Weiterlaufen bringt. Ich musste diesmal eine “dummy”-Datei löschen.
{"code":0,"message":"The file files\/backup\/auto\_update\/dummy already exists and can not be overwritten.","file":"\/home\/shopware\/live\/vendor\/shopware\/recovery\/Common\/vendor\/knplabs\/gaufrette\/src\/Gaufrette\/Filesystem.php","line":100,"trace":"#0 \/home\/shopware\/live\/vendor\/shopware\/recovery\/Update\/src\/Steps\/UnpackStep.php(66): Gaufrette\\Filesystem-\>write('files\/backup\/au...', 'dummyfile')\n#1
Ja genau, das ist der Fehler. Sowas sollte aber eigentlich von Shopware bedacht werden. Ich kenne mich ja schon etwas mit DB’s aus aber damit bin ich jetzt überfordert. Es ist eine Testinstallation auf einem Webserver. Auf eine MYSQL Konfiguration habe ich keinen Zugriff. Scheinbar kann ich MYSQL Variablen aber über die php.ini setzen. Dann sollte der Eintrag: log_bin_trust_function_creators = 1 doch ausreichen, oder? Was ist mit dieser Parameter Group? Was hat es damit auf sich?
Ja genau, das ist der Fehler. Sowas sollte aber eigentlich von Shopware bedacht werden. Ich kenne mich ja schon etwas mit DB’s aus aber damit bin ich jetzt überfordert.
Ich denke, du bist mit deine Frage gehört eher in Installation/Einstieg oder im Adminstration . Vielleicht bekommst du da schneller Hilfe
Super, das war auch bei mir die Fehlermeldung.
Vielleicht kann jemand (oder SW) eine kurze Anleitung posten, wie man den Fehler wieder grade ziehen kann.
MYSQL muss mit dem Parameter log_bin_trust_function_creators = 1 bzw. log_bin_trust_function_creators = ON laufen. Auf einem gehosteten Webspace ist das aber ein Problem weil das in der Regel nicht so einfach möglich ist.
Shopware muss sich da aber etwas einfallen lassen. Es kann ja nicht sein, dass man keine Updates mehr machen kann, nur weil man keinen Zugriff auf einen kompletten Webserver hat. Wenn Updates nicht mehr mit einer Standard-Webhosting Konfiguration gehen ist Shopware einfach wertlos für Normalkunden.
Ich hab mir einen eigenen V-Root Server für 5€ bei einem der vielen Anbieter besorgt. Für einen einzelnen Shop sind die Specs vollkommen ausreichend. Im Notfall besorg dir einen Managed mit Root-Rechten. Es gibt auf jeden Fall genug Optionen, sich nicht Apple-like im Shopware-Ökosystem einzusperren.
hat jemand ein plan wie ich den update wieder anstarten kann??? ich komme nun nur auf die maintenance seite, nicht aber mehr ins backend oder sonstiges, wo ich den update weiter triggern könnte
