[manuelles Update auf 5.1.2]kein Backend Anmeldebereich mehr

Hallo liebe shopware - Gemeinde, ich habe heute das Update auf Shopware Version 5.1.2 vorgenommen (von Shopware Version 5.1.1). Das Update habe ich von http://community.shopware.com/Downloads … ml#updates bezogen (http://releases.s3.shopware.com.s3.amaz … 1451978502). Nachdem ich alles per FTP hochgeladen habe und das eigentliche Update durchgeführt habe, kam wie immer die Meldung, das ich den Ordner update-assets vom FTP löschen soll. Gesagt getan. Nun wollte ich mich per /backend wieder anmelden und habe folgendes Problem: ich erhalte keine Anmeldemaske mehr. Folgendes wirft Firebug aus: SyntaxError: expected expression, got ';' var ajaxTimeout = ; --\> base?fi...1120732 (Zeile 1537, Spalte 18) Error: Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Shopware.container.Viewport ....length\>0){if(!j.config.enabled){throw new Error("Ext.Loader is not enabled, so ... --\> ext-all...1120732 (Zeile 21, Spalte 60070) Nachstellen kann man den Fall ansich problemlos, indem man das Update manuell durchführt. Ich hoffe jemand kann mir helfen - bis jetzt hat das manuelle Update immer auf diesem Wege funktioniert und die Meldung von oben deutet mir auf einen Shopware-Fehler hin, da die sonst auch nie kam. Den Cache oder ähnliches kann ich nicht löschen - ich komme ja nicht ins Backend (es fehlt ja die komplette Anmeldemaske). Meines Erachtens wird die HTML-Struktur des Backend-Anmeldebereichs nicht (mehr) korrekt aufgebaut. Im Vergleich zu einer 5.1.1 - Version fehlt im Head-Bereich die ID von head (ext-gen1031) als auch die CSS-Dateien (/themes/Backend/ExtJs/backend/_resources/resources/css/extra-icon-set-01.css?201510221322, etc.). Das Body-Element hat weder das div mit der id „ext-quicktips-tip“ noch das div mit der id „ext-comp-1021“. Hier scheint also das manuelle Update-Paket einen Fehler zu haben. Was nun? Hat jemand einen Tipp? Im Frontend funktioniert alles problemlos. Andere Browser wurden auch schon getestet etc. Es scheint auch nicht das erste Mal gewesen zu sein, das dieses Problem entstanden ist, wenn ich Google durchforste (bspw. https://www.facebook.com/shopware/posts … 7162630978) - nur leider gibt es keine Lösungsansätze. Beste Grüße Sebastian

Hallo Auf den ersten Blick scheint folgende Migration das Problem zu machen: https://github.com/shopware/shopware/bl … imeout.php Das Update scheint nicht korrekt durchgelaufen zu sein. Am besten ein Backup zurück spielen und das Update erneut einspielen. Sollte dies nicht helfen, dann einmal prüfen ob die SQL-Migration korrekt durchgeführt wurde. Die Problematik auf Facebook ist schon etwas älter und war auf einen LightHTTP-Server zurück zu führen. Moritz Naczenski

Hi, es deutet wie Moritz sagt alles darauf hin, dass bei dir die Migration 629 nicht korrekt ausgeführt wurde. Bitte kontrolliere das einmal in der Datenbanktabelle s_schema_version. Hier muss die Zeile Vorhanden sein und in dem Feld error_msg darf nichts stehen. Du solltest einmal versuchen schritt für schritt diese Migration von Hand in die Datenbank zu schreiben. Erstelle bitte danach dann noch einen Eintrag in der s_schema_version für diese Migration. Sollten die Migrations nach 629 ebenfalls nicht ausgeführt worden sein, empfehlen wir das Update erneut durchzuführen, damit dies nachgeholt wird. VG, Marcel

Hallo ihr beiden, ich danke erst einmal für eure Hilfe. [quote=„Marcel S“]Hi, es deutet wie Moritz sagt alles darauf hin, dass bei dir die Migration 629 nicht korrekt ausgeführt wurde. Bitte kontrolliere das einmal in der Datenbanktabelle s_schema_version. Hier muss die Zeile Vorhanden sein und in dem Feld error_msg darf nichts stehen. [/quote] Die Zeile ist in der Datenbanktabelle s_schema_version vorhanden und auch error_msg ist leer (NULL). Ich habe nun aber eine Lösung gefunden, falls jemand auch das gleiche Problem einmal hat: ich habe bei dem aktuellen Production-Ordner unter „/var/cache“ eine Zahl hinzugefügt, sodass dieser nicht mehr „aktiv“ ist. Danach habe ich das Front- und Backend aufgerufen. Das Frontend hat einen Fehler geworfen, das Backend ging nach wie vor nicht. Nach einem erneuten Aufruf des Back- und Frontends ging es wieder (die Anmeldemaske wird wieder angezeigt), da es ja automatisch einen neuen Production-Ordner erzeugt hat - da scheint es also wohl ein Cache-Problem gewesen zu sein. Wie und warum das ganze nun funktioniert ist mir aber unklar - beim Update kamen keinerlei Fehlermeldungen sondern nur die gewohnten Erfolgsmeldungen, alle Aktionen und DB-Einträge scheinen ja auch vorhanden zu sein. Den Cache konnte ich ja nicht leeren, da ich ja nicht ins Backend kam. Also Problem gelöst :D. Beste Grüße Sebastian

1 „Gefällt mir“

Hallo Sebastian, danke für deine Information, dein Lösungsvorschlag hat bei mir ebenfalls gut funktioniert! LG Peter :thumbup:

hab aktuell das gleiche problem. bin noch dran. kann man den cache eigentlich deaktivieren? ich hab öfter mal probleme damit.

[quote=„sschreier“] Ich habe nun aber eine Lösung gefunden, falls jemand auch das gleiche Problem einmal hat: ich habe bei dem aktuellen Production-Ordner unter „/var/cache“ eine Zahl hinzugefügt, sodass dieser nicht mehr „aktiv“ ist. Danach habe ich das Front- und Backend aufgerufen. Das Frontend hat einen Fehler geworfen, das Backend ging nach wie vor nicht. Nach einem erneuten Aufruf des Back- und Frontends ging es wieder (die Anmeldemaske wird wieder angezeigt), da es ja automatisch einen neuen Production-Ordner erzeugt hat - da scheint es also wohl ein Cache-Problem gewesen zu sein.[/quote] Danke. Genau so konnte ich das Problem beheben.

Wir hatten dasselbe, aber scheinbar nicht das gleiche Problem. Hat mich einige graue Haare gekostet es zu geheben, deshalb mein Lösungsweg gespickt mit einigen Keywords.

Wir sind Kunden bei All-inkl, allerdings nur mit dem Paket PrivatePlus, d.h. ohne SSH  sad Nachdem ich das Update letzte Nacht über die Weboberfläche gestartet hatte, sah es zunächst so aus als wenn alles geklappt hätte, dann wurden aber auf der Startseite einige (aber nicht alle Grafiken) nicht angezeigt und das Backend ging halt nicht. Obwohl wir nur ~120 Artikel im Shop haben war der Shop zu groß um die Besitzrechte durch die Scripte von All-inkl (sowohl unter Tools, als auch im Web-FTP-Client) an allen 3300 Dateien ändern zu lassen. Ergo: permission denied.
Heute Morgen sah die Startseite wieder gut aus und im Frontent schien auch alles zu funktionieren, das Backend ging aber immer noch nicht. Also kurz den Support angerufen, der mir die Besitzrechte an dem production-Odner im cache rekursiv überschrieben hat. Ein einfaches Laden des Front- und Backend erzeugte aber keinen neuen Ordner production, weil sowohl /var/cache als auch /var/logs CHMOD 777 haben müssen 775 reichte nicht aus. Danach wurde der Cache neu aufgebaut, das Backend funktionierte aber immer noch nicht. Folgende Fehlermeldung habe ich dann gefunden:

GET backend/base?file=bootstrap&loggedIn=1234567890 503 (Service Unavailable)
Uncaught Error: Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Shopware.container.Viewport

Hier im Forum habe ich dann herausgefunden, dass es ein ähnliches Problem auch schon mal bei einem Update auf 5.1.1 gab:

Update auf 5.1.1 - Login Form von Backend weg

Die dort beschriebene Lösung (fehlenden Ext.Timeout.js aus guthub laden und in engine/Library/ExtJs/overrides/ einfügen) führte auch bei mir zum Erfolg und ein erneuten aufbauen des Chaches war nicht notwendig. Allerdings erhalte ich jetzt wieder Meldung, dass das Update auf 5.1.2 bereitsteht. Falls sich jemand von Shopware das angucken möchte kann er sich gerne melden. Heute Nacht werde ich das mit dem Update bestimmt nicht erneu probieren.