All.js Uncaught TypeError: Cannot read properties of undefined (reading 'call') nach Update auf 6.4.11.1

Hallo.

Seit dem Update auf 6.4.11.1, kommt dieser JS Fehler im kompletten Frontend und beeinträchtig teilweise die Funktionen im Frontend… Jemand eine Idee woher dieser Fehler stammt und wie er behoben werden kann?

Gruß Mike

Hallo,

ich kann leider auch nicht weiterhelfen, kann aber bestätigen, dass es hier ein Problem gibt.

Ich bin Plugin-Hersteller und bei einigen meiner Kunden taucht genau dieses Problem ebenfalls auf, wodurch u.a. auch mein Plugin nicht mehr funktioniert.
Die Registierung der Plugins über Webpack scheint in einigen Fällen nicht zu funktionieren. Der Fehler tritt scheinbar zufällig auf, manchmal reicht ein Neukompilieren.

Moin!

Ich habe ebenfalls einen JS Fehler, allerdings leicht abgewandelt:
Cannot read properties of undefined (reading 'has')

Bei mir konnte ich den Merkzettel (Wishlist) als Übeltäter ausmachen. Wenn Ihr die Wunschliste also aktiviert habt, könnte das aktuell die Fehlerursache sein.

LG;LA

Hi. Anscheinend hat sich von 6.4.11.0 zu 6.4.11.1 etwas in der JS Logik geändert. Was kann ich aktuell nicht sagen. Jemand von euch nähere Insights? Neukompilieren von storefront JS unter 6.4.11.1 behebt den Fehler meistens. Setzt halt voraus das alles installierten Plugins da auch aktuell sind.

Aktuell haben wir bei nem Kundenprojekt das Problem, dass wir auf 6.4.11.1 gegangen sind, das Tag Manager Plugin aber leider diesen Fehler produziert.

Habe testweise probiert die storefront Logik des Plugin in Dockware mit 6.4.11.1 neu zu kompilieren und die neue Datei dann hochgeladen. Leider besteht der Fehler weiterhin. Bin etwas ratlos

1 „Gefällt mir“

Hallo,

in meinen Fällen ist nicht die Wishlist dafür verantwortlich. Der Fehler tritt auf bei der Registrierung der Plugins - wobei es scheinbar zufällig ist, bei welchem der installierten Plugins der Fehler auftritt.

Hallo,

ich vermute stark, dass es an einer App/Plugin liegen wird, welches nicht kompatibel mit der 6.4.11.x Version sein wird.

Meist reicht das builden des Storefronts aus. Die App-Hersteller müssten ggf. eine neue Version ihrer Apps veröffentlichen.

Versucht einzeln die Apps zu deaktivieren und überprüft, ob im Storefront ein JS Fehler auftaucht.

VG
abdullah

Hallo,

ich habe ein Bugticket angelegt:
NEXT-21595

@abdullah Das Deinstallieren und erneute Installieren eines Plugins (und damit Neukompilieren des JavaScripts) behebt den Fehler unter Umständen - ohne, dass am Plugin-Sourcecode etwas geändert wurde. Deswegen gehe ich im Moment nicht davon aus, dass ein Kompatiblitätsproblem vorliegt.

@kilb_software, dass beim Installieren von Apps die JS Dateien neu kompiliert werden ist mir neu.
Ich zumindest muss beim Entwickeln auch nach der Installation einer App die JS neu kompilieren, also Storefront bzw. Administration.

Daher ist meine Vermutung, dass einige Apps mit der aktuellen Shopware Version gebaut werden müssen, damit die Kompatibilität gegeben ist. Am JS Code selbst muss nicht unbedingt etwas verändert werden.

vg

@abdullah
Wenn eine App deinstalliert, wird auch deren JavaScript aus der kompilierten all.js entfernt. Wird sie erneut installiert, wird das JavaScript wieder eingebaut - es wird also definitiv neu kompiliert. Für gewöhnlich kann ein Shopbetreiber eines Produktivsystems ja keine CLI-Commands manuell ausführen, deswegen macht Shopware das bei Installation/Deinstallation (bzw. Aktivierung/Deaktivierung).

Bei einem meiner Kunden konnte ich das Problem zwar erst lösen, indem ich eines der Plugins neu installiert habe - nach ein paar Stunden trat das Problem aber erneut auf. Ich weiß nicht, was in dieser Zeit passiert ist - das spricht aber ja erst einmal dafür, dass ein reines Neukompilieren mit der neuesten Version nicht ausreicht.

@kilb_software, ah jetzt versteh ich was du meinst.

Mit Deinstallieren/installieren bzw. Deaktivieren/Aktivieren kann die Reihenfolge beeinflusst werden, wie die einzelnen Plugins (JS) in all.js geladen werden.

Aber die einzelnen Plugins werden nicht neu kompiliert, bin ich der Meinung.

Je nach Plugin Reihenfolge und auftreten des Fehlers kann es vorkommen, dass das Storefront mal mehr mal weniger funktioniert. Je später das Plugin auftritt, welches ein Problem verursacht, desto mehr Funktionalitäten sind gegeben, da mehr Plugins initialisiert werden.

vg

Danke für den Hinweis. Wusste nicht das die storefronts beim installieren nochmal kompiliert werden. Habe das gerade beim Kundenprojekt probiert. Fehler ist nun weg nachdem ich das entsprechende Plugin de- und wieder installiert habe.

Das JavaScript wird beim installieren nicht kompiliert. Zumindest meinem Verständnis nach nicht. Es wird in die all.js integriert. Das war es aber auch schon. Wie abdullah geschrieben hat passiert die Umwandlung von JS in Webpack nur über die CLI-Befehle.

1 „Gefällt mir“

Naja irgend einen zusätzlichen Prozess gibt es da. Die storefront js werden ja auch mittels theme:compile in der all.js zusammengefasst. In meinem Fall hat das aber nichts bewirkt. Erst die Neuinstallation hat geholfen.

Die Integration in die all.js ist die Kompilierung, die ich meine. Um die all.js zu bauen, muss sie kompiliert werden. Es gibt ja keine Logik irgendwo, die eine bestehende all.js öffnet und dort hacky bestimmte Zeilen einfügt oder entfernt. Nein, die all.js wird von Grund auf neu gebaut.

Wenn ich ein Plugin baue, implementiere ich meinen JavaScript-Code.
Wenn ich das Plugin veröffentlichen möchte, muss ich eine Zip-Datei bauen, die diesen JavaScript-Code bereits vorkompiliert.

Wenn ein Shopbetreiber dieses Plugin nun installiert, wird der vorkompilierte Code eingelesen und in die all.js kompiliert.
Der Plugin-JavaScript-Code selbst wird nicht erneut kompiliert. Die all.js aber schon.

Wenn ich mich richtig entsinne, liegt die Verantwortlichkeit für diese Logik in der Datei \Shopware\Storefront\Theme\ThemeCompiler, mit Betonung auf Compiler. :stuck_out_tongue_winking_eye:

Wenn ich nun die Kompilierung der all.js neu anstoße, ist der Fehler unter Umständen weg. Ich befürchte aber, dass ein erneutes Kompilieren den Fehler wieder verursachen könnte.

Hm, ich hab eine Vermutung, aber ich kann sie nicht belegen. Es gibt zwischen den Versionen 6.4.11.0 - 6.4.11.1 eine Anpassung beim ScripLoader, nach welcher Scripts nun erst geladen werden, wenn diese als „active“ markiert sind:

(Hinweis: Es gab noch einen zweiten Commit davor, allerdings mit den Änderungen an den falschen Stellen im Code. Dieser Commit behebt die vorherigen Fehler und führt noch einige, zusätzliche Änderungen auf)

Ich weiß leider nicht, ob die DB-Spalte neu ist, oder schon existiert hat, aber: Wenn sie neu ist, dann könnte es sein, dass das Update-Script einen falschen default-Wert in die Spalte einträgt und erst die Neu-Installation hat die richtigen Default-Werte in die entsprechende Spalte eingetragen - aber reine Spekulation…

Das hätte man allerdings mit dem deaktivieren der Plugins theoretisch relativ einfach beheben können, bzw. die Fehlerursache zumindest einkreisen können - So kann ich leider auch nur ins blaue raten.

Ich hoffe ich kann damit irgendwem weiterhelfen oder zumindest einen Hinweis geben.

LG;LA

1 „Gefällt mir“

Hi,

wir haben das Problem auch auf einigen Shopware-Shops nun. Können aber ja nicht wahllos Plugins deaktivieren und deaktiviert lassen. Auch im Git dazu tut sich nicht wirklich was: JavaScript error: TypeError: Cannot read properties of undefined (reading ‚call‘) · Issue #2477 · shopware/platform · GitHub - Der Fix dort bringt übrigens bei uns auch nichts.

Gibt es einen „sauberen“ Weg Shopware auf Version 6.4.10 downzugraden?
Weiß das jemand?

Grüße…

Moin!

Würd ich absolut nicht empfehlen.

Um Plugins auszuschließen, legt lieber eine zweite Shopware-Installation als als Test-System an. Konstruiert dort die selbe Plugin Struktur (mit Theme) und testet dann in Ruhe auf der Kopie. Aber da mehrere den Fehler haben… entweder Core, oder viele nutzen das selbe Plugin :smiley:

EDIT: Du sagst, es sind mehrere Shops betroffen. Haben diese eventuell ein übereinstimmendes Plugin? Dann spart Ihr Euch die Kopie :sweat_smile:

LG;LA

Ich auch nicht.
Hab’s trotzdem getan, da ich im Moment davon ausgehe, dass das Matomo Plugin „schuld“ ist. Weg lassen mag ich das aber nicht.

Das Downgrade hat augenscheinlich aber geklappt - jetzt warten wir mal, wann das GitHub-Ticket geschlossen wird.

Wir bekommen das nicht gefixt. Das Matomo Plugin haben wir nicht - das wäre ja auch zu einfach gewesen. Ein Ticket ist seit 13.05. eingestellt. Was kann man noch tun, um an eine Lösung zu kommen?

Wie geht ihr denn vor? Würde zunächst alle nicht SW Plugins deaktivieren, dann nach und nach wieder aktivieren (DB), Theme kompilieren und Frontend checken. So konnte ich damals die 2 betroffenen Plugins identifizieren. Sind die Plugins bekannt, einfach mal die Entwickler anschreiben und eine kompatible Version anfordern. Sollte in den meisten Fällen einfach nur durch eine Neukompilierung der JSs getan sein.
In meinem Fall gab es für das TagManager Plugin keinen Support. Habe das Plugin dann unter einer Docker Entwicklungsumgebung installiert, neu kompiliert und die aktualisierten JS Dateien im Projekt ersetzt.
Bis dann mal der offizielle Fix kommt.

Gruß Mike

1 „Gefällt mir“