[quote=“useg”] Ich hoffe das es seitens Shopware noch einen interne Lösung gibt. [/quote] Ich auch - daher auch meine Frage, ob es sich bei dem aktuellen Verhalten um das beabsichtigte handelt. Die von Stefan Pohl genannte Verarbeitungsreihenfolge lässt ja anderes vermuten.
Hallo Sven, Hallo Thomas, jetzt bin ich aber ein wenig neidisch auf euch, ihr könnt selbst ein Plugin schreiben, so etwas würde ich auch gern noch können. :thumbup: ,da wäre vieles einfacher umzusetzen.
Ich habe ein Ticket in JIRA erstellt: http://jira.shopware.de/?ticket=SW-10910 Votet bitte, wenn ihr die Funktionalität auch braucht. Einen entsprechenden Pull Request habe ich auch eingestellt: https://github.com/shopware/shopware/pull/254 Danke, Sven
Hi zusammen, erstmal vielen Dank für den Pull Request. Bei der Kompilierung der Less/CSS/Javascript Dateien war die Vererbungshierarchie noch nicht wie bei den Templates eingebunden. Dieses haben wir jetzt im RC2 gelöst. Die Dateien werden jetzt in folgender Reihenfolge kompiliert: - themes/bare/less - themes/bare/css - themes/responsive/less - themes/responsive/css - plugin/less - plugin/css - themes/custom/less - themes/custom/css Dadurch habt Ihr jetzt die Möglichkeit Stylings aus Plugins über euer eigenes Theme zu überschreiben. Hierfür könnt Ihr einfach wie erwartet ein eigenes Theme mit eigenen Less Dateien anlegen und das Styling ganz normal überschreiben. Für die Javascript Dateien haben wir ebenfalls die Reihenfolge angepasst: - themes/bare/js - themes/responsive/js - plugin/js - themes/custom/js Den eingereichten Pull Request haben wir noch ein wenig überarbeitet. Die aktuellen Änderungen findet Ihr in diesem Commit: https://github.com/shopware/shopware/co … df3b056e21 Gruß Oliver Skroblin
Hallo Oliver, funktioniert einwandfrei, und euer Fix ist deutlich eleganter als meiner - vielen Dank für die Umsetzung! Grüße, Sven
Wenn ich jetzt in meinem eigenem Theme, das das Bare extended, jQuery einbinde, werden die Plugins in der generierten theme.js am Anfang eingebunden. Dadurch kommt der Fehler in der Console “jQuery is not defined”. Ist bisschen unschön für das Advanced Menü :wtf:
[quote=„sitzdesign“]Wenn ich jetzt in meinem eigenem Theme, das das Bare extended, jQuery einbinde, werden die Plugins in der generierten theme.js am Anfang eingebunden. Dadurch kommt der Fehler in der Console „jQuery is not defined“. Ist bisschen unschön für das Advanced Menü :wtf:[/quote] Hallo zusammen, hat schon jemand eine Lösung für das beschriebene Problem?
[quote=“s.pahrig”][quote=“sitzdesign”]Wenn ich jetzt in meinem eigenem Theme, das das Bare extended, jQuery einbinde, werden die Plugins in der generierten theme.js am Anfang eingebunden. Dadurch kommt der Fehler in der Console “jQuery is not defined”. Ist bisschen unschön für das Advanced Menü :wtf:[/quote] Hallo zusammen, hat schon jemand eine Lösung für das beschriebene Problem?[/quote] Hallo, das würde mich auch brennend interessieren…
[quote=„watsonLousen“][quote=„s.pahrig“][quote=„sitzdesign“]Wenn ich jetzt in meinem eigenem Theme, das das Bare extended, jQuery einbinde, werden die Plugins in der generierten theme.js am Anfang eingebunden. Dadurch kommt der Fehler in der Console „jQuery is not defined“. Ist bisschen unschön für das Advanced Menü :wtf:[/quote] Hallo zusammen, hat schon jemand eine Lösung für das beschriebene Problem?[/quote] Hallo, das würde mich auch brennend interessieren…[/quote] Da gibt es keine Lösung. Es ist derzeit nicht praktikabel mit der Shopware Theme Compiler Component eine Ableitung des Bare Themes zu kompilieren, da die Javascript Instanziierungabfolge der Kompilierung erst Plugin Javascripte vor Custom Theme Javascripten vorsieht. So werden z.B. die Javascripte des AdvancedMenu Plugin in einem Szenario mit einem Custom Theme auf Basis des Bare Themes - welches Jquery in dem protected $javascript Array inkludiert - vor den Custom Theme Javascripte abgeholt und somit auch vor Jquery im Browser instanziert. Folglich kommt der Error „jQuery is not defined“ zustande. Shopware scheint auch deshalb derzeit nur darauf ausgelegt zu sein, dass man Themes vom Responsive Theme ableitet, da etliche Plugins (wie z.B. das AdvancedMenu Plugin) in ihren LESS-Dateien Variablen aus dem Responsive Theme verwenden ohne Fallback Strategie. Da aber die Ableitung vom Responsive Theme dazu führt, dass jegliche LESS-Dateien Desselbigen ebenfalls mit den LESS-Anpassungen via der all.less des Custom Themes zusammen kompiliert werden, kann man sich ja vorstellen, auf welche Größe die kompilierte CSS-Datei bei größeren Anpassungen des Custom Themes anwächst. Man kompiliert also in diesem Fall möglicherweise mächtig viel unnötiges CSS. Somit bleibt in diesem Fall nur die Kompilierung via Nodejs und Gruntjs für das Custom Theme auf Basis des Bare Themes. Allerdings bleibt natürlich trotzdem die Problematik mit den Abhängigkeiten der LESS-Variablen in Pluginstrukturen, was zur Folge hätte, dass man den Theme Backend Aufbau beim Custom Theme mit Basis Bare Theme wie beim Responsive Theme aufbauen müsste.
Hy, hat einer von euch eine Lösung dafür, das mit dem eigenen Theme die Blöcke mit Plugin Inhalt nicht überschreiben werden, aber der Bare Content überschrieben wird? Sonst kann man einen Block global nicht mehr verwenden, wenn man diesen in seinem eigenem Theme abändert.
@Oliver Skroblin Vielen Dank für den letzten Eintrag hier. Ich konnte auf diese Weise mit meiner neuen CSS Datei „/themes/Frontend/ByouteaTheme/frontend/_public/src/css/byoutea.css“ mit dem folgenden Inhalt /\* HEADER - Cookie Bar - BG color \*/ .cookie-bar { background: #25beac !important; }
ziemlich locker die Hintergrundfarbe des Cookie Plugins anpassen. Jetzt hätte ich dazu noch 2 Fragen: 1. Ist das jetzt der „beste Weg“ oder wäre es der bessere Weg das in irgendeiner Form mit diesen .less Dateien umzusetzen? 2. Ich habe nach der Erstellung meines Themes im backend alle leeren Ordner im Theme gelöscht weil ich es übersichtlicher finde und nicht so viel unnötigen „Datenmüll“ in meinem Theme mit rumschleppen möchte. Ist das vom System her unbedenklich wenn man die Ordner neu anlegt, wenn die tatsächlich benötigt werden? Gruß aus Köln-Porz, Atilla
[quote=“sitzdesign”]Wenn ich jetzt in meinem eigenem Theme, das das Bare extended, jQuery einbinde, werden die Plugins in der generierten theme.js am Anfang eingebunden. Dadurch kommt der Fehler in der Console “jQuery is not defined”. Ist bisschen unschön für das Advanced Menü :wtf:[/quote] Dann binde jQuery nicht über die Theme.php ein, sondern ganz normal über Smarty {block name="frontend\_index\_header\_javascript\_jquery\_lib" prepend} <script type="text/javascript" src="%7Blink%20file=" pfad zu js></script>{/block}
das ermöglicht außerdem das nutzen der CDN version (http://code.jquery.com/jquery-1.11.3.min.js) oder auch das nutzen eines eigenen CDN.
Da gibt es keine Lösung. Es ist derzeit nicht praktikabel mit der Shopware Theme Compiler Component eine Ableitung des Bare Themes zu kompilieren, da die Javascript Instanziierungabfolge der Kompilierung erst Plugin Javascripte vor Custom Theme Javascripten vorsieht. So werden z.B. die Javascripte des AdvancedMenu Plugin in einem Szenario mit einem Custom Theme auf Basis des Bare Themes - welches Jquery in dem protected $javascript Array inkludiert - vor den Custom Theme Javascripte abgeholt und somit auch vor Jquery im Browser instanziert. Folglich kommt der Error „jQuery is not defined“ zustande.
Shopware scheint auch deshalb derzeit nur darauf ausgelegt zu sein, dass man Themes vom Responsive Theme ableitet, da etliche Plugins (wie z.B. das AdvancedMenu Plugin) in ihren LESS-Dateien Variablen aus dem Responsive Theme verwenden ohne Fallback Strategie.
Da aber die Ableitung vom Responsive Theme dazu führt, dass jegliche LESS-Dateien Desselbigen ebenfalls mit den LESS-Anpassungen via der all.less des Custom Themes zusammen kompiliert werden, kann man sich ja vorstellen, auf welche Größe die kompilierte CSS-Datei bei größeren Anpassungen des Custom Themes anwächst. Man kompiliert also in diesem Fall möglicherweise mächtig viel unnötiges CSS.
Somit bleibt in diesem Fall nur die Kompilierung via Nodejs und Gruntjs für das Custom Theme auf Basis des Bare Themes.
Allerdings bleibt natürlich trotzdem die Problematik mit den Abhängigkeiten der LESS-Variablen in Pluginstrukturen, was zur Folge hätte, dass man den Theme Backend Aufbau beim Custom Theme mit Basis Bare Theme wie beim Responsive Theme aufbauen müsste.
Und ich dachte schon, ich bin der einzige, der diese Probleme beim Erben vom Bare-Theme hat. Die Dokumentation erwähnt diese Probleme leider in keiner Weise
Ich bin auch der Meinung, dass das Bare-Theme im aktuellen Zustand unvollständig ist, es müssten zumindest alle Less-Variablen, auf die sich die offiziellen Plugins beziehen, vorhanden sein. Ansonsten ist die Aussage, dass man auch problemlos ein Theme auf Bare-Basis aufbauen kann, so nicht richtig.
Falls noch wer auf dieses Problem bei der Erweiterung des Bare-Themes stößt und keine Lösung findet. Im Responsive Theme steckt die Lösung.
Einfach folgende Variable in der Theme.php definieren:
/**
* @var bool
*/
protected $injectBeforePlugins = true;
Falls noch wer auf dieses Problem bei der Erweiterung des Bare-Themes stößt und keine Lösung findet. Im Responsive Theme steckt die Lösung.
Einfach folgende Variable in der Theme.php definieren:
/**
- @var bool
*/
protected $injectBeforePlugins = true;
Davon ist unbedingt abzuraten. Das führt zu üblen Problemen mit diversen Plugins. Ich war anfangs auch sehr glücklich über die Option und scheinbar funktionierte das ganz wunderbar. Dann hatten wir massive Probleme mit dem Paypal Plugin, der Wunschliste, der Vergleichsliste, … die einfach nicht zu lösen waren. Am Ende lag es genau an dieser Option.
Es gibt scheinbar einfach keine saubere Möglichkeit Plugin Ressourcen zu überschreiben. Das gesamte Ressourcenhandling ist für die Tonne. Vllt. guckt man im Shopware Team einfach mal nach links und rechts, wie andere da so machen. Zum Beispiel das Drupal 8 Libraries Konzept ist überragend https://www.drupal.org/docs/8/creating-custom-modules/adding-stylesheets-css-and-javascript-js-to-a-drupal-8-module
Auch das von Wordpress ist einigermaßen brauchbar.