Update-System - Fehler vorprogrammiert

Ich schreibe dies als Halb-Außenstehender. Ich bin nur Arbeitskollege aus der IT-Abteilung eines Betriebs der sowohl selber ein Shopware-Shop betreibt wie auch mehrere Fremd-Shops supportet. Mehr durch Zufall bin ich heute damit konfrontiert worden als mir der Kollege von einem Problem erzählte und ich mir dann unseren eigenen Shop mal im Backend anschaute. 

Mehrere Hinweise, dass es Updates gibt waren groß zu sehen und meine erste Frage war nicht: „Wo ist das Problem?“ sondern „Wieso verwendet ihr so eine alte Version?“. Antwort: Ja die Version ist rund 5 Monate alt weil es immer Probleme mit den Updates gibt und wir keine Lust haben anschließend 2 Tage im Wartungsmodus alles zu korrigieren. 

Super Einstieg ins System und da ich schon mal da war: Komm wir machen das mal Update - neu ist immer besser. Klicken brav das Formular durch und stellen erstmal fest: Wenn man auf Installieren klickt passiert nichts. Hmm haben wir was falsch gemacht? Gut mal Browsertool gezückt und geschaut was passiert wenn man draufklickt. Er läd im Hintergrund scheinbar etwas sobald man da drauf klickt aber auf dem Bildschirm passiert nichts. Und wenn man mehrmals draufklickt lädt er sogar mehrfach etwas. Ok warten wir mal. Nach 3 Minuten dann mehrere Fehlermeldung die wohl darauf hindeuteten, dass wir zu oft draufgeklickt haben.

Nagut… Update wurde nicht gestartet wir laden alles Neu, keine Fehlermeldung also nächster Versuch. Diesmal klicken wir brav nur einmal auf den Knopf und warten. Und tatsächlich fängt der Shop nach mehreren Minuten bangen wartens endlich an das Update runterzuladen. Auf in den Kampf: Update starten, Systemvorraussetzungen erfüllt und im ISDN-Gallop gehts weiter zur Datenbankmigration. Und da passiert es.

Error
Received the following error message:
Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists

Please try to fix this error and restart the update.
Response

{"valid":false,"errorMsg":"Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists "}

Hmm… der Kollege hat wohl recht, die Updates machen scheinbar wirklich Probleme. Aber was nun? 
Seite aktualisieren und hoffen, dass es von alleine weg geht oder sollen wir wie angefordert versuchen das Problem zu beheben. F5 ging schneller deswegen probierten wir es erneut und wieder der selbe Fehler. Schade wäre auch zu einfach.

Also dann machen wir uns daran das Problem zu fixen. Tabelle s_filter_options_attributes soll bereits existieren also mal schauen ob das stimmt. Und tatsächlich war sie bereits vorhanden und leer. Nagut sie ist leer also löschen wir sie doch mal wie gewünscht. Scheinbar muss sie neu erstellt werden damit das Update durchläuft. Also Tabelle gelöscht, F5, Datenbankmigration und schwupps…

Error
Received the following error message:
Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists

Please try to fix this error and restart the update.
Response

{"valid":false,"errorMsg":"Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists "}

Joa… interessant. Tabelle ist in der Datenbank definitiv wieder vorhanden. Wie es aussieht erstellt das Update die Tabelle mehrfach und das ohne Fallback-Kontrolle. 

Das ist schlecht, denn der Shop ist nun im Wartungsmodus und man kommt weder ins Front- noch ins Backend. Will man den Fehler beheben taucht er wieder auf - kein vor und kein zurück. Ich fange an zu verstehen warum der Kollege keine Lust auf Updates hatte.

Fragen wir mal Dr. Google, der zum entsetzen der shopware AG erstaunlich viele Ergebnisse zu fehlgeschlagenen Updates und „Wartungsmodus“-Problemen findet. Es gibt zwar auch einzelne Lösungsansätze die dem Laien sagen wie man das Update neu startet oder gar den ganzen Update-Ordner löscht, aber nichts davon half. Gut der Shop ist scheinbar im Arsch und wir hatten bereits das Backup-Fenster geöffnet aber irgendwie kann das doch nicht sein.

Wir verursachen bei einem simplen Update einen totalen Crash des Shops und wir hören das von diversen anderen Kunden auch - nicht nur beim aktuellen Update. Im Web gibt es zig Fragen und auch dieses Forum ist überhäuft mit engagierten Händlern dessen Einnahmequelle durch ein Sicherheitsupdate mal eben dicht gemacht wird. 

In dem genannten Beispiel ist es ein simpler SQL-Fehler der offensichtlich vom Update verursacht wurde und wahrscheinlich durch die einfachen Wörter „IF NOT EXISTS“ umgangen werden könnten.Ganz davon zu schweigen, dass der Marktführer in Sachen Shop-Systemen, doch mal irgendwie sowas wie ein Sicherungsmechanismus und sei es try{ } in das Update-System intgrieren können sollte. Besonders dann wenn er nicht mal richtige Updates fährt, sondern jedes Update eine 34MB große Vollversion ist bei dem nur die Datenbank wirklich im Updateprozess angefasst wird.

Wahrscheinlich werden viele Shopbesitzer keine großen Probleme mit Updates haben - hoffe ich jedenfalls. Aber bei Shopware-Besitzern die zu uns kommen sind die wenigsten Systeme aktuell und viele klagen genau über solche Probleme. Hier im Forum sind doch einige solcher Fragen und Google kennt noch deutlich mehr. Und das darf einfach nicht der Fall sein. 

Von daher die bitte an den Community-Support. Bitte aufstehen, ins Büro der IT-Abteilung gehen und dem Team das für die Updates-Funktionen zuständig ist ein Glas kaltes Wasser ins Gesicht kippen. So gehts nicht und es ist mindestens eine Frechheit was hier abgeliefert wird. Von finanziellem und Image-Schaden für die einzelnen Händler und der shopware AG selber ganz zu schweigen.

Und wo wir schon dabei sind: In PHP gibts eine Funktion die nennt sich trim() welche sich hervorragend eignet um Formulareingaben zu reinigen und bei den Standard-Plugin wie z.B. „Statistics“ könnt ihr wenigstens so tun als ob sie seit 2010 mal wieder aktualisiert worden wären. 

Schön Gruß

Wo ist der Like-Button???
Bedankt.

Eigentlich gibt es nur ein Create Statement für die Tabelle, wenn mich nicht alles täuscht. Hast Du die Migration schon über die Konsole ausgeführt?  

Aber zu dem generalisierten Vorschlag, es sei so einfach den Fehler mit IF EXISTS zu unterbinden: Wenn an Stelle X in der Migration eine Tabelle nicht existieren darf, dann bricht die Migration aufgrund des SQL-Fehlers ab. Somit wird verhindert, dass ein möglicherweise inkonsistenter Datenbankstand entsteht. Das ist jetzt natürlich kein besonders ausgefallenes Error-Handling, erfüllt aber an dieser Stelle seinen Zweck. 

Genauso wie für die ähnlich gelagerten Migration-Abbrüche, wenn Hoster oder Shopbetreiber Keys eigenständig gesetzt haben. Immer wenn die DB nicht dem Basisstand/Erwartungen von Shopware entspricht, bricht die Migration ab ohne etwas kaputt zu machen. 

 

So ist es… :slight_smile:

Leider kann man so einen Updatevorgang nicht standardisieren, da bestimmte Servereinstellungen auch eine Rolle spielen und somit den Updatenvorgang ändern bzw. beeinflussen.

Der Fairness halber muss man auch sagen, dass gegenüber anderen Shopsystemen, wo ich bereits die vergangenen Jahre Updates durchgeführt habe, ab und zu für regelrechte Horrortrips gesorgt haben. Da ist Shopware meiner Meinung nach noch sehr handsam.

Aufgrund der vielen Forenthreads ist es logisch, dass wenn eine Software viele viele User hat, somit auch mehr Probleme auftauchen können. Dann wird die Menge an Problemthreads ebenfalls mehr. Logisch… Wenn man aber bedenkt, dass so viele User Shopware nutzen, ist der prozentuale Anteil an Problemen, die hier im Forum gepostet werden, doch recht gering.

Wenn ich ein Update mache, muss ich z.B. folgendes durchführen, was nicht standardmässig von Shopware erwartet wird, aber mit unseren Servereinstellungen zu tun hat.

  1. Backend öffnen und Update dort starten. Die Dateien werden dann runtergeladen und entpackt.

  2. Ist das fertig, springt das Back- und Frontent auf Wartungsmodus. Das würde auch so bleiben wenn ich nichts unternehme.

  3. Also ab in den Filezille und im Ordner Recovery > Update die Rechte der php Datei auf 755 setzen. Dann wieder raus aus dem Filezilla.

  4. Nun im Browser wo Wartungsmodus steht einfach STRG F5 drücken. Nun wird das Updaten normal gestartet.

  5. Wenn das Update fertig ist, und die überflüssigen Dateien entfernt sind, kann ich auswählen ob ich ins Front- oder Backend möchte.

  6. Egal was ich dann wähle, es kommt internal Server Error.

  7. Also ab in den Filezilla und die shopware.php auf 755 setzen.

  8. Dann ab ins cpanel und im Ordner Files den Zipordner des Updates löschen und den Unterordner update-assets ebenfalls.

  9. Dann kann ich mich wieder wie gewohnt ins Backend einloggen und alles läuft wie es soll.

 

So hat es bereits einige Updates ohne Probleme geklappt. Ausser beim Update von 5.1 auf 5.2 haben diverse Plugins Fehler gemacht, wobei aber Shopware da nichts dafür kann.

Unser Server läuft mit Apache und nGinx.

Vielleicht klappts bei euch ja auch mit dieser Reihenfolge.

 

Viele Grüße

Matthias

 

Auf die SQL-Problematik hatte ich auch im Zusammenhang mit von All-inkl. gesetztem Index für eine Spalte in einer media-Tabelle hingewiesen. Es wäre an der Stelle zumindest schon sehr hilfreich, wenn das Asset-Script beim Fehler wenigstens seinen Dateinamen nennen würde. Selbst wenn also das “Problem” erkannt wurde, darf man auf die Suche gehen, welche Datei für die Updates gelöscht werden muss.

An der Stelle muss ich aber auch sagen: Das war in 2 1/2  Jahren das einzige Update, das bei mir unerwartete Probleme deim Datenbankupdate gemacht hatte.

Für mich ist das größere Probleme eher das kaputte PlugIn-System und die Marotte von Shopware, selbst in BugFix-Versionen soviel am Unterbau zu ändern, dass man Angst haben muss, ob ein noch so triviales Plugin nach einem BugFix-Update noch läuft. Dafür sind BugFix-Versionen nicht gedacht.

@DerMudder‍ wohl noch nicht so viel in der IT-Welt erlebt, was?

@malzfons‍ Danke für die ausführliche Erklärung aber man kann so ein Problem immer aus zwei Seiten betrachten. Du siehst es dank deiner Erfahrung eher gelassen und auch wenn es vielleicht etwas nervig ist, es ist halt so. Ich betrachte es heute mal als Kunde der hier mindestens 1300€ für ein Produkt bezahlt, welches beim kleinsten Sicherheitsupdate (jedenfalls vom Changelog her) Probleme macht. 

Das Argument, dass es kein einheitlich funktionierendes Update-Script geben kann, weil die Server ja alle unterschiedlich sind. Wieso kann es dann nahezu jedes andere Script? Stell dir dieses Update-Desaster mal bei Wordpress vor. In Sachen Komplexität stehen die dem Shop hier in nix mehr nach, aber dort braucht es nicht mal einen Wartungsmodus um einzelne(!) Elemente zu erneuern. Drupal, Foren wie WBB, vBullitin und Co, IPS und was weiß ich noch - funktionieren teils automatisch im Hintergrund. Klar gibts dort auch immer wieder Probleme doch nicht in dem Umfang wie ich es hier in nur 2 Tagen gesehen habe. 

Wenn andere Shop-Software ähnliche Probleme haben, dann muss sich die gesamte Branche mal fragen was sie da für ein krummes Zeugs produzieren. Wobei man evtl. sogar wohlwollend sagen muss: Ja aktuelle Konkurrenzprodukte sind teilweise deutlich schlimmer aufgebaut und leiden scheinbar noch immer darunter, dass sie eigentlich nur angepasste Scripts von Shopsystemen sind, die vor über 10 Jahren geschrieben wurden.

Aber egal wie es ändert eben nichts daran, dass die Updateroutine bei unserem Shop nicht funktioniert hat und wenn man sich Kunden anschaut die haufenweise die selben Probleme haben dann sind wir da schlicht kein Sonderfall den man unter “Ist halt so” abstempeln kann. Und da Shopware nun simpel gesagt auch nicht das Shopsystem ist das überwiegend von großen Unternehmen mit eigener IT-Abteilung verwendet wird, sind haufenweise alte Versionen im Umlauf weil der einfache User immer Angst hat irgendwo drauf zu drücken. Und da ist der Shop der als Einnahmequelle dient noch deutlich sensibler als der blöde Windows-Rechner zu Hause der eh nie macht was er soll. Spätestens wenn er einmal Probleme hatte heißt es fortan “Never change a running system”. 

Ein Großteil dieser Betreiber wird sich jedenfalls nicht hier im Forum anmelden und schauen wie man irgendwie was reparieren könnte. Wenn man damit sein Lebensunterhalt verdient, dann heißt es: Reparieren egal wie. Und da wartet man nicht 2 Tage auf eine Antwort im Forum sondern da wird irgendein IT’ler angerufen der sich mit sowas auskennt.
Und ja es kommt einem schon in den Sinn, dass hier evtl. sogar absichtlich die ein oder andere Support-Subscription verkauft werden soll. Nur Vermutung aber shopware wird nicht nur mit ein paar Verkäufen der Profi-Version sein Personal bezahlen können.

Ohne nun tiefgreidend ins System geschaut zu haben aber ich behaupte, dass sich die Update-Routine deutlich besser absichern lässt. 
Rechte lassen sich im Vorfeld prüfen und wenn alles richtig konstruiert ist, dann braucht man die auch nur einmal zur Installation setzen. Der Laie will im Browser und nicht per FTP arbeiten. Besonders dann wenn es um so komische Zahlen geht die man irgendwo eintragen soll.

Der von mir oben beschriebene Fehler ist z.B. auch so ein Ding wo ich beim besten Willen nicht verstehe wie es dazu kommen kann. Die Tabelle wird eindeutig durch das Update-Script generiert und anschließend wird gemeckert, dass es bereits generiert wurde. Man kann da nun verschiedene Theorien aufstellen wo und warum es dazu kommt aber Tatsache ist einfach: Es gibt einen ganz simplen Fehler der durch ein SQL-Query ausgelöst wurde. Man könnte diesen “Fehler” umgehen und prüfen. Und da es auch kein Fehler ist der das Update blockieren würde, könnte das Update sogar weiterlaufen. 
Stattdessen bricht alles ab, der Shop ist down und statt ein Recovery-Script zu starten welches die alte Version wiederherstellt passiert gar nix. Ja es werden nicht mal Links zu Update- oder Recovery-Script angezeigt.

Allein der “Fehler”, dass einfach nichts passiert wenn man auf “Update installieren” klickt ist … Sorry aber selbst unser Azubi weiß wie man mit onclick das Feld deaktvieren und Aktiviät symbolisieren könnte. Arbeitsaufwand 5 Minuten inkl. dem raussuchen der Template-Dateien. 

Man kann es nun sehen wie man will. Man kann es schönreden oder man kann mit nem Anwalt drohen. Man kann versuchen eine Lösung zu finden oder man kann bocken und das Shopsystem wechseln. Tatsache ist einfach, dass es diverse Fehler gibt und für ein Unternehmen sollte eigentlich das Kredo sein: Schon ein Rechtschreibfehler ist einer zuviel. Sein Geschäftsmodell evtl. darauf ausrichten, möglichst viel Support zu verkaufen wird nach hinten los gehen sobald sich irgendein Hacker-Kiddie mal das Script durchschaut und all die ganzen veralteten Versionen findet wo man doch an die Datenbank mit Kundendaten rankommt. So ein PR Desaster möchte man keinem wünschen.

Von daher gerne nochmal die Aufforderung an den Support: Ab in die Küche und ein Glas kaltes Wasser für die Entwickler besorgen.

Wieder mal so jemand der glaubt bei Shopware würden nur Idioten sitzen. Tipp: schaue erstmal was Ihr bei Eurer Shopware-Installation verbockt habt… In sauberen Installationen gibt es sehr selten Probleme. 

Beheb den Fehler und ich bin ruhig

Error
Received the following error message:
Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists

Please try to fix this error and restart the update.
Response

{"valid":false,"errorMsg":"Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 's_filter_options_attributes' already exists "}

Ansonsten lass ich dir gerne deine Fanboy-Gesänge und du mir meine Kritik an einem bezahlten Produkt.

 

Edit: Das muss ich eben mal nachholen.
Ok wenn du als Betreiber von nextshops Support und Co an Kunden verkaufst damit Shopware richtig läuft kann ich dich sogar verstehen. Wäre auch schlimm wenn man euch nicht mehr bräuchte, weil die Software einfach von vorn herein fehlerfrei liefe. :slight_smile:

@DerMudder schrieb:

Beheb den Fehler und ich bin ruhig

Error
Received the following error message:
Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‚s_filter_options_attributes‘ already exists

Please try to fix this error and restart the update.
Response

{„valid“:false,„errorMsg“:"Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‚s_filter_options_attributes‘ already exists "}

Ansonsten lass ich dir gerne deine Fanboy-Gesänge und du mir meine Kritik an einem bezahlten Produkt.

Super einfach. Wenn du ein Backup zurückspielst, solltest du sicherstellen, dass neu angelegte Tabellen nicht vorhanden sind. Schau in deine Datenbank vor dem Update -> Ist die Tabelle vorhanden? Dann hat derjenige der dein Backup eingespielt hat Mist gebaut, denn die Tabelle gibt es erst ab 5.2.

Die Lösung gibt es hier aber auch schon zigfach im Forum, einfach mal suchen:  Updatefehler - Slim Application Error - #16 von Moritz_Naczenski - Installation/Einstieg - Shopware Community Forum

Typisches Problem bei vielen Hostern, dass das Backup einfach in eine bestehende Datenbank zurückgespielt wird und daher Tabellen nicht gelöscht werden, die mit dem Update erst angelegt werden. Wenn dem so ist, musst du vor dem Update halt deine Datenbank bereinigen. Zukünftig solltest du sicherstellen, dass der Hoster das Backup korrekt zurückspielt, denn da gibt es in der 5.1 diese Tabelle noch nicht.

Noch ein gut gemeinter Tipp: Ich helfe natürlich gerne - der Ton macht aber die Musik  Wink

1 „Gefällt mir“

Ich schrieb: 

Tipp: schaue erstmal was Ihr bei Eurer Shopware-Installation verbockt habt… In sauberen Installationen gibt es sehr selten Probleme. 

wenn Ihr dazu nicht in der Lage seid, helfe ich auch gerne. Warum nicht?!

Vielen Dank für die Antwort. 

Wie ich oben beschrieben habe bzw. der Fehler ja aussagt war die Tabelle ja bereits vorhanden. Allerdings habe ich sie nach der ersten Fehlermeldung auch von Hand gelöscht gehabt. Sprich beim ausführen des Updates war die Tabelle nicht vorhanden. Sie wurde durch das Update erstellt und anschließend meckerte das Update, dass sie bereits vorhanden ist. 

Und ich will eigentlich nicht rumflamen aber wenn man sich den Thread so durchließt… Sorry aber die Update-Funktion braucht dringend mal ein Update.

@DerMudder schrieb:

Vielen Dank für die Antwort. 

Wie ich oben beschrieben habe bzw. der Fehler ja aussagt war die Tabelle ja bereits vorhanden. Allerdings habe ich sie nach der ersten Fehlermeldung auch von Hand gelöscht gehabt. Sprich beim ausführen des Updates war die Tabelle nicht vorhanden. Sie wurde durch das Update erstellt und anschließend meckerte das Update, dass sie bereits vorhanden ist. 

Und ich will eigentlich nicht rumflamen aber wenn man sich den Thread so durchließt… Sorry aber die Update-Funktion braucht dringend mal ein Update.

was glaubst Du wo die Tabelle hergekommen ist?! 

Definitiv durch das Update-Script selber. Wir (Mehrzahl) haben das Spielchen gestern 2x gemacht.

Tabelle gelöscht.
Updatescript neu gestartet -> Fehlermeldung
Blick in phpMyAdmin -> Tabelle wieder da
Tabelle wieder gelöscht
Updatescript neu gestartet -> selbe Fehlermeldung
Blick in phpMyAdmin -> Tabelle wieder da

Entweder hat ein Mechanismus versagt der prüft: Wurde die Tabelle korrekt erstellt. return false? Ok starte ich nochmal -> SQL Error = Abbruch.
Oder (der Shop ist aktuell Version 5.1.6) es gibt mehrere Schleifen oder gar SQL-Querys die während des Updates auf 5.2.16 versuchen diese Tabelle zu erstellen ohne vorher zu prüfen ob sie da sind. 

Aber dann hätten doch viel mehr Leute Probleme an dieser Stelle, oder? Ich denke nicht, dass es ein grundsätzliches Problem ist, sondern bei Euch spezifisch. Klar schöner wäre es, wenn der Updates alle möglichen Fälle berücksichtigen würde. Dies ist glaube ich aber, aktuell nicht die Strategie von Shopware.

Warum habe ich die Tabelle beim “Durchupdaten” von früher 4.3.0 bis heute 5.2.16 nicht doppelt, wenn es ein allgemeines Update-Problem ist?
Und zum Thema Rechteproblem: Dann läuft der Shop halt mit falschen Rechten, soll heissen: Filesystem-User != WWW-User. In vielen Umgebungen kann man das ganz einfach durch ein Umstellen von PHP-MOD auf PHP-CGI erledigen. Das ist dann aber kein Shopware-Problem, sondern eher ein E45.

@NextMike schrieb:

was glaubst Du wo die Tabelle hergekommen ist?! 

Da er sie vor dem Update gelöscht hat offensichtlich aus dem Update.

Ich hab mir die Migrations noch nie so genau angesehen, weil ich bisher nie Probleme mit Updates hatte, aber kann es vielleicht sein, dass durch das mehrfache herunterladen des Updates die SQL-Migrations mehrfach da sind und dadurch die Tabelle auch mehrfach angelegt wird? 

Schau mal ob unter update-assets/migrations/ Dateien doppelt vorkommen.

Über das Update kann man sicherlich streiten, ich finde es auch gut, dass bei inkonsistenz einfach abgebrochen wird. Ein IF EXISTS bringt dir gar nichts wenn die Tabelle fälschlicherweise angelegt wurde und die falsche struktur hat. DAnn hast du danach auch ein kaputtes System. Mindestens aber der Update-Button der nicht sichtbar macht, dass gerade etwas passiert verleitet aber wirklich dazu mehrmals drauf zu klicken.

@DerMudder schrieb:

Vielen Dank für die Antwort. 

Wie ich oben beschrieben habe bzw. der Fehler ja aussagt war die Tabelle ja bereits vorhanden. Allerdings habe ich sie nach der ersten Fehlermeldung auch von Hand gelöscht gehabt. Sprich beim ausführen des Updates war die Tabelle nicht vorhanden. Sie wurde durch das Update erstellt und anschließend meckerte das Update, dass sie bereits vorhanden ist.  

 

 Na ja, das Updateskript legt die Tabelle eigentlich nicht zwei Mal hintereinander an. Bei allem, was Du geschrieben hast, vermute ich fast, dass du den Updateprozeß zwei Mal parallel anstößt. Das ist mir auf einem Kundenserver vor längerem auch schon passiert und daher hatte ich nach der Shell-Methode gefragt. Ich weiß nur nicht, ob dieses Verhalten mittlerweile in der Backendvariante des Updates unterbunden wird. Dinge wie Schreibrechte werden jedoch geprüft. Das die UI nicht ganz so toll ist, stimmt zwar, ist aber nun auch nicht der riesige Deppenfehler, den dein Tonfall nahe legt.

Es ist auch einfach nicht richtig, dass das Skript weiterlaufen darf, wenn eine Tabelle schon existiert. Nur als Beispiel: Shopware führt eine neue Tabelle ABZ ein. Ein Shopbetreiber/Plugin hat eine Tabelle diesen Namens jedoch bereits manuell angelegt - aus welchen Gründen auch immer. Folgt Shopware deinem Rat und überspringt das Anlegen der Tabelle, fliegt dir hinterher der gesamte Shop um die Ohren . Evtl. erst bei einem spezifischen Produkt, dass die neue Tabelle nutzt und nicht bei deinen bisherigen Standardartikeln. 

Einfache Kochrezepte sind nun nicht immer die besten. Entspricht die Datenbankstruktur nicht dem erwarteten Standard, dann muss ein Update-Skript abbrechen, alles andere wäre fahrlässig. Die Stelle in den Migrations wird ja auch genannt. 

Wenn Du Shopware kritisieren möchtest, dann tu das doch mit den Punkten, die wirklich schlecht sind. Die gibt es nämlich in der Tat, auch bei einzelnen Migrations. 

@t2oh4e schrieb:

@NextMike schrieb:

was glaubst Du wo die Tabelle hergekommen ist?! 

Da er sie vor dem Update gelöscht hat offensichtlich aus dem Update.

ich meine bei „erstem“ Lauf 

Wie gesagt ich bin eigentlich nicht für diese Sachen zuständig und auch nicht in der Materie drin. Ich kann also nur davon berichten was mir meine Kollegen erzählen bzw. was ich nun die letzten Tage so im Script alles gesehen habe. 

Klar kann es sein, dass wir irgendeine komische Konstellation haben die durch unglückliche Umstände irgendeinen vorher nie entdeckten Fehler produziert. Passiert immer. Doch den Berichten der Kollegen nach sind diese Umstände doch recht häufig. Da braucht man sich nur hier im Forum umschauen und die aktiven User hier scheinen die meisten der Probleme zumindest schonmal gehört zu haben.

Da es schwer/unmöglich ist ein Update für ein fehlerhaftes Update-Script zu veröffentlichen, will ich ja auch nicht laut schreien: Bei Shopware sitzen nur Idioten die nichtmal einen 6 Monate alten Fehler beheben können. Ja vielleicht ist er in 5.2.16 ja auch schon längst behoben und es gibt in der aktuellen Version auch keine Fehler mehr weil der ganze Update-Prozess verbessert wurde.

Aber ich komme als Außenstehender rein und sehe bei einem simplen Update-Prozess so einen Fehler. Bekomme mit, dass diese Fehler häufiger vorkommen (sieht man auch im Forum und an Google) und wenn ich weiß wie man man mit teils einfachen Methoden solche und ähnliche Fehler umgeht dann wird es die Abteilung die das alles entwickelt hat auch wissen. Problem bei sowas ist dann eher, dass nie die Anweisung dazu kam und man sich auf andere Entwicklungen konzentriert. 

Ok in dem Sinne vielleicht: Entschuldige Entwickler-Abteilung, bringt das Glas bitte der Geschäftsleitung als Ideenbringer für 5.4