Hallo, in der aktuellen Shopware 5.0.2 gibt beim Shopware-Responsive-Template Probleme mit einigen Plugins die eigene (von Jquery abhängige) Javascripte einbinden. Verifizieren konnten wir das Problem zum Beispiel bei den Plugins von Payone und der Filial- und Händlersuche von Net Inventors. Diese Plugins hängen ihre Script-Includes an den Block frontend_index_header_javascript an: {block name="frontend\_index\_header\_javascript" append} ... {/block} Im Bare-Template in der frontend/index/index.tpl wird der Block frontend_index_header_javascript aber vor dem neuen Block frontend_index_header_javascript_jquery ausgegeben. Dies führt dazu, dass sich die Plugin-Skripte auf ein noch nicht definiertes JQuery beziehen: {block name="frontend\_index\_header\_javascript"} ... {if $theme.additionalJsLibraries} {$theme.additionalJsLibraries} {/if} {/block} {\* Include jQuery and all other javascript files at the bottom of the page \*} {block name="frontend\_index\_header\_javascript\_jquery\_lib"} {compileJavascript timestamp={themeTimestamp} output="javascriptFiles"} {foreach $javascriptFiles as $file} <script src="%7B%24file%7D"></script> {/foreach} {/block} {block name="frontend\_index\_header\_javascript\_jquery"} {\* Add the partner statistics widget, if configured \*} ... {/block} Zu erkennen ist das Problem an einfachsten, indem ihr im Chrome mit F12 die Console öffnet. Wenn ihr dort Meldungen der Art [color=red]Uncaught ReferenceError: $ is not defined[/color] bekommt tritt bei euch auch das Problem auf. Vorübergehend haben wir das Problem in unserem abgeleiteten Template in der Datei frontend/index/index.tpl folgendermaßen gelöst: {\* prepend original frontend\_index\_header\_javascript\_jquery\_lib block \*} {block name="frontend\_index\_header\_javascript" prepend} {compileJavascript timestamp={themeTimestamp} output="javascriptFiles"} {foreach $javascriptFiles as $file} <script src="%7B%24file%7D"></script> {/foreach} {/block} {\* clear old block content \*} {block name="frontend\_index\_header\_javascript\_jquery\_lib"} {/block} Dies mag zwar nicht die eleganteste Lösung zu sein, hat uns aber geholfen die Reihenfolge der Javascripte so lange zu korrigieren bis entweder Shopware oder die Plugin-Hersteller die Probleme beheben. Ich hoffe dieser Post erspart jemandem die unnötige Zeit in irgendwelchen Support-Warteschleifen. 
Viele Grüße aus Köln, Robert
Der Fehler wurde inzwischen von Sascha Brüggenolte von Net Inventors bestätigt. Ich habe ein entsprechendes Ticket aufgemacht. Vielleicht mag ja jemand upvoten 
http://jira.shopware.de?ticket=SW-12153
[quote=“benblub”][quote]Now it’s time to take a look on the actual implementation process of a jQuery plugin using the plugin base class. Here’s a commented example of a generic plugin:[/quote] https://developers.shopware.com/designe … luginbase/[/quote] Unfortunately I’m not talking about jquery plugins that I’ve developed for my own Themes. The error happens with several Shopware-Plugins bought from the Community Store that try to include their javascript files. Best, Robert
[quote]Uncaught ReferenceError: is not defined [/quote] das ist jQuery, welche in Shopware5 am besten über die Plugin Base in die Plugins integriert werden ;) [code]jQuery("xy").machWas();[/code] anstatt … könnte ggf. auch schon funktionieren oder halt das $ erst jQuery zuordnen.
Hallo zusammen, ich kann euch bestätigen, dass es sich hierbei nicht um einen Bug handelt, die Plugins wurden schlichtweg nicht auf Shopware 5 migiriert. Wir haben mit Shopware 5 einen Javascript-Precompiler eingebaut, der alle JS-Dateien in eine Datei zusammenfasst und die Kommentare sowie die Whitespaces entfernt. So kann zum einen die Dateigröße der JS-Dateien verringert werden und es wird nur noch ein HTTP-Request zum Server gesendet, um die kompilierte Datei zu laden. Um diese Funktionalität zu nutzen, muss ein neues Event in der Bootstrap.php registriert werden: /\*\* \* Registers all necessary events and hooks. \*/ private function subscribeEvents() { // Subscribe the needed event for js merge and compression $this-\>subscribeEvent( 'Theme\_Compiler\_Collect\_Plugin\_Javascript', 'addJsFiles' ); } /\*\* \* Provide the file collection for js files \* \* @param Enlight\_Event\_EventArgs $args \* @return \Doctrine\Common\Collections\ArrayCollection \*/ public function addJsFiles(Enlight\_Event\_EventArgs $args) { $jsFiles = array(\_\_DIR\_\_ . '/Views/responsive/frontend/\_public/src/js/script.js'); return new Doctrine\Common\Collections\ArrayCollection($jsFiles); } Alle weiteren Informationen rund um das Thema „Plugin update“ haben wir euch bereits dokumentiert und in den Shopware Devdocs zur Verfügung gestellt. Viele Grüße, Stephan Pohl :shopware:
Moin Stephan, dass es kein wirklicher Bug ist, sehe ich ein. Der Einleitungssatz ist aber eine Frechheit und denunziert uns Plugin-Entwickler. Uns ist durchaus bewusst, dass es einen JavaScript-Compiler gibt und wir unser JavaScript an den genannten Collecter mittels EventListener übergeben können. In der Startphase unserer SW5-Migrationen haben wir das auch so praktiziert, allerdings zog das Probleme nach sich. Unter anderem Folgende: - Wir sind gebeten worden, unsere Plugins kompatibel zu Shopware4 und Shopware5 zu gestalten. Das heisst, hier müssen Weichen implementiert werden, die die JavaScript-Files auf unterschiedliche Weise laden. Zudem ist noch möglich, in Shopware5 weiterhin die Emotion-Templates zu nutzen, wodurch noch eine dritte Weiche implementiert werden muss. Dass es überhaupt in Shopware5 noch möglich ist, die Emotion-Templates zu benutzen, mag für Shopbetreiber ein guter Anreiz sein, schnell Ihren Shop zu migrieren. Für Entwickler ist es aber nur zusätzlicher Aufwand, weil man hier noch mehr Anwendungsfälle/Umgebungen unterscheiden muss und zu viele Sonderlocken im Code hat. Im Shopware5-Workshop vor dem Release war übrigens davon überhaupt keine Rede, es wurde dort ausschließlich auf das Responsive-Template eingegangen. - Ein weiterer Punkt ist, dass man u.U. große Mengen an JavaScript-Code (wie z.B. Drittanbieter-Bibliotheken) nur an ganz wenigen Stellen im Shop (z.B. nur auf der Seite confirm/finish) benötigt. Diesen Code-Wust in den Collector zu werfen führt doch zu einem unnötigen Overhead auf allen weiteren Shopseiten. Falls es hier eine Möglichkeit gibt, die JS-Collection nur bei bestimmten Controllern & Actions zu füttern, gebt uns gerne Bescheid. Wir haben zumindest keine gefunden. Das alles führt zu Mehraufwänden, Unüberschaubarkeiten und Code-Overhead, was uns wieder dazu brachte, den bewährten Weg über die JavaScript-Blöcke zu gehen. Es ist aus unserer Sicht völlig unnötig und eine massive Behinderung für Plugin-Entwickler, dass an so elementarer Stelle die Blöcke und damit die Ladereihenfolge der JavaScripts vertauscht wurden. Dazu kommt noch, dass so etwas in einer Minor-Version gemacht und an keiner Stelle kommuniziert wurde. Es taucht nicht einmal im Changelog auf. Wenn ihr gewollt hättet, dass unter Shopware 5 niemand mehr die Blöcke für JavaScript nutzt, hättet ihr sie doch gleich entfernen können. Zum Glück hat Herr Lang das Problem schnell bemerkt und uns direkt informiert (Vielen Dank noch einmal dafür!). Ansonsten wären viele Shops nach Plugin-Update nicht mehr nutzbar gewesen und die Verärgerung der Shopbetreiber natürlich auf uns projeziert worden. Wir müssen jetzt erstmal all unsere weiteren Plugins durchforsten und ggfs. anpassen. Viele Grüße Sascha Brüggenolte
Das kann ja wohl nicht wirklich euer Ernst sein. Wenn ich mir ein Auto kaufe, dann ist die Anhängerkupplung auch an der vorgesehenen Stelle hinten und man kann was dranhängen. Und ich komme nicht morgens runter und stelle fest, dass die Anhängerkupplung nun vor dem Getriebe hängt und man kann nix mehr dranhängen! Uns das nun zu verkaufen, mit dem Spruch “it’s not a bug - it’s a feature” verarscht mich doch gewaltig. Vielleicht sollte die Entwicklergemeinde Shopware mal eine Rechnung über den Aufwand stellen, den wir nun haben, mit der ganzen Anpasserei… Und: Vielleicht gibt mir auch mal von Shopware, nach der schönen Klugsch…ei mal einen Tipp, wie ich denn Konfigurationswerte aus dem Plugin an JQuery übergeben soll. Bislang habe ich das einfach als Smarty-Variable an den JQuery-Block gemacht. Soll ich mir jetzt ein Ajax basteln und einen Controller anfragen, damit ich die Config-Werte kriege? Findet Ihr das nicht arg kompliziert? Vielleicht meint ihr aber auch, wir sind so arbeitslos, da kann man schon mal so eine Beschäftigungstherapie raushauen… Ich bin echt angesäuert. F.
[quote=“snapdragon”]Uns das nun zu verkaufen, mit dem Spruch “it’s not a bug - it’s a feature” verarscht mich doch gewaltig.[/quote] So ist das nun mal, wenn Konzepte überarbeitet und modernisiert werden. Ich habe nie den Schritt von Shopware 3 auf 4 mitgemacht - aber ich kann mir vorstellen, dass es dort ähnlich war. Und ja: auch ich habe als Entwickler lange daran gesessen unsere Plugins anzupassen. Aber so ist das nun mal… Was denkst du denn, wie hoch der Aufwand für Entwickler ist, wenn man sein Windows Programm von Windows 7 auf 8 updaten möchte? Ich zumindest bin froh, dass nun (endlich) eine ordentliche Architektur / ein überdachtes Konzept im Einsatz ist. [quote=“snapdragon”]wie ich denn Konfigurationswerte aus dem Plugin an JQuery übergeben soll[/quote] Entweder tatsächlich per ajax request oder - und so machen es zb auch die Shopware Plugins - die Konfiguration als javascript inline einbetten. Siehe zb: http://pastebin.com/JGUcgCa7 [quote=“Net Inventors GmbH”]Dazu kommt noch, dass so etwas in einer Minor-Version gemacht und an keiner Stelle kommuniziert wurde. Es taucht nicht einmal im Changelog auf.[/quote] Das ist natürlich mies gelaufen… Viele Grüße
Hi, [quote]wie hoch der Aufwand für Entwickler ist, wenn man sein Windows Programm von Windows 7 auf 8 updaten möchte[/quote] Da bin ich jetzt nicht ganz bei Dir. Ich bin selbst lange Jahre Windows-Entwickler gewesen. Und eines habe ich immer hoch gelobt, bei MS - die Dokumentation - und die Abwärtskompatibilität. Ich weiss ja nicht, welche Erfahrungen Du da so mit MS hast, aber bzgl. Shopware im Vergleich fängt es ja hier schon bei den Plugin-Beispielen in der Doku an. Die bedürfen mal eine gewisse Anpassung erfahren, an die Modalitäten des Shopware 5.x. Ich kann mich nicht daran erinnern, dass MS veraltete Beispiele in der Doku hatte, oder diese zumindest nicht kurzfristig erneuert hat. Gut, ich spreche ja hier auch von MS und einer Doku und von mehr Mitarbeitern als Shopware die hat. Da funktioniert dann schon mal sowas. VG ;))
[quote=„snapdragon“]Ich weiss ja nicht, welche Erfahrungen Du da so mit MS hast[/quote] Überhaupt keine… Mein Punkt war auch eher, dass sich Technologien weiter entwickeln und externe Entwickler mitziehen müssen. [quote]Und eines habe ich immer hoch gelobt, bei MS - die Dokumentation - und die Abwärtskompatibilität.[/quote] Shopware legt großen Wert auf Abwärtskompatibilität - an manchen Baustellen (Änderungen an grundlegenden Konzepten) sind break points jedoch unausweichlich. Die schlechte Kommunikation (oder Dokumentation) habe ich ebenfalls bemängelt. Viele Grüße
das sind mal wieder vergleiche^^
Ja, zumal das nicht mal etwas mit der Shopware 5.0.2 zu tun hat. Soweit ich weiß (bzw. so steht es auch im CVS) ist das schon immer im Shopware 5-Template drin. Man könnte das Jquery natürlich auch wieder in den
Hallo Heiner, ich verwende Shopware 5.0.2 und die aktuelle Custom Products Version 1.3.6 und bekomme folgenden JS Fehler: - jQuery is not defined - $.datePickerSettings is undefined Kann dieses nur mit folgendem Code beheben: {block name="frontend\_index\_header\_javascript" prepend} {compileJavascript timestamp={themeTimestamp} output="javascriptFiles"} {foreach $javascriptFiles as $file} <script src="%7B%24file%7D"></script> {/foreach} {/block} {\* clear old block content \*} {block name="frontend\_index\_header\_javascript\_jquery\_lib"}{/block} Ist das ein bekannter Fehler? Beste Grüße
Hi, ja, das Problem ist bekannt und wird auch gelöst. Es erzeugt aber nur eine Fehlermeldung. Das Modul funktioniert trotzdem richtig. http://jira.shopware.de/?ticket=PT-3473 Viele Grüße Heiner
Bei mir treten die beiden Fehler auf jeder Seite auf und das Datumsfeld, Bildupload funktioniert leider auch nicht… Ich hoffe das ist bald behoben. Beste Grüße
Dann hast du wahrscheinlich noch ein anderes Problem. Kann man sich den Shop irgendwo anschauen? Gruß Heiner