Upgrade-Problem 5.1.6 auf 5.2.2 --> Upgrade Abbruch bei der Datenbank-Aktualisierung

Shopware 5 Installation/Einstieg
1

Hallo zusammen,

ich bin schon seit längerem dabei ein Shop aufzubauen und habe unerwarteter Weise derzeit ein Upgrade-Problem von Version 5.1.6 auf 5.2.2. In der Hoffnung, dass vielleicht jemand eine Idee hat, möchte ich nachfolgend einmal die Grunddaten aufführen und in die Runde geben. Vielleicht haben andere auch das Problem und es bringt etwas. Meine verschiedenen Korrekturversuche haben bisher nichts gebracht.

Allgemeine Historie:

  • Shop basiert ursprünglich auf eine 4.3er Version (mit den damaligen Templates)
  • Im Sommer 2015 auf Version 5 upgegraded (anschließend dann das Template Schritt für Schritt aufgebaut – Basis „Responsive-Theme“) – in der Zeit keinerlei Probleme gehabt
  • Alle Updates bis Version 5.1.6 durchgeführt – nie Probleme gehabt

Beim Upgrade von 5.1.6 auf 5.2.2 hält das System bei der Datenbank- Aktualisierung an und die quittiert das Upgrade mit der Fehlermeldung:

 

**** ========================================== ****

Error

Received the following error message:

Could not apply migration (Migrations_Migration705). Error: Undefined offset: 1

Please try to fix this error and restart the update.

Response

{“valid”:false,“errorMsg”:"Could not apply migration (Migrations_Migration705). Error: Undefined offset: 1 "}

**** ========================================== ****

 

Leider kann ich das Problem nicht richtig fassen. Die virtuelle Serverumgebung läuft normal, eine Blankoinstallation 5.2.2 lässt sich anstandslos installieren und das mit PHP 5.6.23.

Folgende Sachen habe ich ausprobiert (mit einer Kopie des laufenden Stands).

  • Manuelles Update

  • Upgrade 5.1.6 auf 5.2.0  (gleicher Abbruch der Datenbank-Aktualisierung)

  • Deaktivierung von derzeit einem benutzten Plugin (gleicher Abbruch)

  • Löschen der hinterlegten Einkaufswelten sowie der alten Template-Strukturen (brachte auch nichts)

  • Upgrade unter anderen Serverstrukturen (gleicher Abbruch)

  • Upgrade unter PHP 7 (gleicher Abbruch)

  • Neue Installation Version 5.1.6, Integration meiner Template-Variante und danach Upgrade auf 5.2.2 --> das Upgrade lief fehlerfrei durch.

 

Das zeigte mir, dass es an der Datenbank liegen muss (wie gesagt, die Updates liefen immer perfekt durch). Aber was kann es sein und wo liegt es?

In der dazugehörigen Migrationsdatei, die ein Mitglied hier vor 2 Tagen aufgeführt hat, kann ich schwer einen Ansatz finden (https://github.com/shopware/shopware/blob/5.2/_sql/migrations/705-rename-category-template-column.php).

Liegt es vielleicht an den alten Templates, ein Array was nicht bestückt ist …

 

Vielleicht kennt jemand das Problem und kann einen Tipp geben. Das wäre genial.

 

Beste Grüße und danke für das Reindenken

Robert William

 

 

 

 

 

2

In der Datenbank in der Tabelle s_schema_version würde ich beim letzen Eintrag eine passende Startzeit und Endezeit eintragen und den Wert des Fldes error_msg auf null setzen. dann sollte das probelm gelöst sein.  

3

Hallo Matze2305,

danke für Ihre Antwort. Habe es einmal ausprobiert und mir angesehen. Alle error_msg Werte waren und sind auf Null. Habe den letzten Zeiteintrag mal aktualisiert (neueres Datum eingetragen), wie von Ihnen empfohlen - hat leider keinen Effekt gehabt. 

 

4

Eigentlich muss man sich nur etwas mit der Migration beschäftigen,… wie man das debuggt steht auch im Wiki. Der Threadersteller hat ja schon viel vorleistung gegeben. Es geht um diese Migration: shopware/705-rename-category-template-column.php at 5.2 · shopware/shopware · GitHub

Die schlägt in der Regel fehl, wenn in der s_core_config_values ein invalider Eintrag für die Kategorie-Templates hinterlegt ist. Dafür muss man sich aus der s_core_config_elements die passende elementid suchen (für Verfügbare Listen) und dann anhand der elementID den Eintrag aus der s_core_config_values löschen. Danach sollte auch das Update laufen.

5

Die Frage die man sich stellen sollte ist, warum man sowas überhaupt debuggen muss. Es sollte eine Selbstverständlichkeit sein, dass ein Shopsystem dass sich so mit Lorbeeren schmückt, eine funktionierende Update-Logik besitzt bei der man sich nicht mit den Tiefen von Symfony auseinander setzen muss um auf Fehlersuche zu gehen. Nicht falsch verstehen - ich mag Shopware, aber es ist ab und an eine Zumutung wieviele Stunden man mit Debugging und der Kompatibilisierung autorisierter und kostenpflichtiger (!) Plugins verbringen muss.

Wenn das jetzt auch noch mit Shopware Standardfeatures wie einem Minor-Update der Fall ist… gute Nacht.

 

Zum Thema:

Danke Moritz für diesen Hinweis. Ich wundere mich, dass ich da nicht selbst drauf gekommen bin, lerne ich doch so gerne die 236 Tabellen von Shopware auswendig., Geholfen hat es übrigens tatsächlich - daher ernsthaft vielen Dank!

Ich frage mich allerdings auch hier, weshalb solche Altlasten nicht automatisch bei den Updates gelöscht werden…

 

Lösung:

Bei mir befanden sich noch aus der alten Emotion-Zeit von Shopware 4 3-col templates in der DB. Folgende Einträge habe ich gelöscht, danach lief es rund.

857×875 236 KB

 

857×875 233 KB

 

1 „Gefällt mir“
6

Moin,

vielen Dank für das Aufgreifen des Beitrags und dem Lösungansatz. Große Klasse, dass “squadhousemedia” das auch schlussendlich umsetzen konnte. Danke.

Der Ansatz in Richtung Kategorie-Templates war ja damals dann nicht verkehrt. Da es schon zwei Monate her ist und der Produkumfang nicht so enorm war, habe ich mittlerweile die Datenbankinhalte zu Produkten, Varianten etc. händisch von Datenbank zu Datenbank übertragen. Musste dann natürlich noch die Einstellungen für den Shop umsetzen. Ist halt so.

Um sauber und updatesicher in die Zukunft zu gehen, sah ich das als den einzigen sinnvollen Weg (der Umfang war aber auch überschaubar, das muss ich dazu sagen). Es war aber trotzdem eine gute Erfahrung die Daten händisch von DB zu DB übertragen und die Mediendateien zum Laufen zu bringen - es funktionierte.

Grüße

7

Moin,

ich hatte auch diesen Fehler bekommen, weil custom templates eingetragen waren.

Eine schnelle Lösung für mein Problem war in der /files/update/update-assets/migrations/705-rename-category-template-column.php  unter der Zeile 38

foreach (explode(";", $templates) as $template) {

kurz leere Einträge auszuschliessen. Also drunter einfügen: 

if (empty($template))continue;

Dann klappts :slight_smile: