Moin, seit einigen Tagen benutze ich jetzt Grunt für Shopware und das mit recht gemischten Gefühlen. Tendenziell ist es ein super Tool um schneller zu arbeiten, es gibt aber einige Nachteile bzw. sogar Fehler: 1. Javascript Dateien werden nicht kompiliert, da der Pfad in der gruntfile falsch ist, statt ‘/Frontend/’ steht dort ‘/frontend/’. Bei einem Linux Server ist das nicht ganz so toll. 2. Javascript Dateien werden in einem src Ordner erwartet. Das ist aber sonst nirgends eine Grundvoraussetzung. Deshalb habe ich das aus dem Pfad entfernt 3. Pfade zu Bildern werden nicht modifiziert. Das sorgt dann dafür das z.B. Hintergrundbilder nicht mehr angezeigt werden. Hier fehlt nur die Option ‘relativeUrls: true’, dann funktioniert auch das. 4. Variablen werden am Ende ersetzt. Ich hab keine Ahnung wie das sonst gemacht wird, aber scheinbar mit Grunt anders als mit dem normalen Compiler. Denn man kann normalerweise die Konfiguration bequem per LESS Datei überschreiben. Das ist für ein Custom Template ziemlich wichtig, damit der Kunde nichts kaputt macht. Grunt ersetzt die Variablen aber scheinbar erst ganz am Schluss. Das sorgt dafür, das alle meine Anpassungen wieder überschrieben werden. Unschön. Punkt 1-3 konnte ich selbst anpassen, das ging recht gut - Auch wenn ich mich wundere warum gerade Punkt 1 nicht vorher aufgefallen ist ? - Punkt 4 nervt aber ganz gewaltig. Ich denke nur an die Situation das man im Development immer mit Grunt arbeitet aber für den Produktiveinsatz dann auf einmal auf den internen Compiler wechselt - wie es empfohlen wird. Wenn dann auf einmal etwas anderes herauskommt als man erwartet, dann hat man ein Problem. Für alle die auch schon Probleme damit hatten und nach einer Lösung suchen, poste ich hier mal meine aktuelle Gruntfile. module.exports = function (grunt) { grunt.option.init({ shopId: 1 }); var file = '../web/cache/config\_' + grunt.option('shopId') + '.json', config = grunt.file.readJSON(file), lessTargetFile = {}, jsFiles = [], jsTargetFile = {}, content = '', variables = { 'font-directory': '"../../themes/Frontend/Responsive/frontend/\_public/src/fonts"', 'OpenSansPath': '"../../themes/Frontend/Responsive/frontend/\_public/vendors/fonts/open-sans-fontface"' }; lessTargetFile['../' + config.lessTarget] = '../web/cache/all.less'; config['js'].forEach(function (item) { jsFiles.push('../' + item); }); jsTargetFile['../' + config.jsTarget] = jsFiles; config['less'].forEach(function (item) { content += '@import "../' + item + '";'; content += "\n"; }); grunt.file.write('../web/cache/all.less', content); for (var key in config.config) { variables[key] = config.config[key]; } grunt.initConfig({ uglify: { production: { options: { compress: true, preserveComments: false }, files: jsTargetFile }, development: { options: { mangle: false, compress: false, beautify: true, preserveComments: 'all' }, files: jsTargetFile } }, less: { production: { options: { compress: true, modifyVars: variables, relativeUrls: true }, files: lessTargetFile }, development: { options: { modifyVars: variables, dumpLineNumbers: 'all', sourceMap: true, sourceMapFileInline: true, relativeUrls: true }, files: lessTargetFile } }, watch: { less: { files: ['../engine/Shopware/Plugins/\*\*/\*.less', '../themes/Frontend/\*\*/\*.less'], tasks: ['less:development'] }, js: { files: ['../themes/Frontend/\*\*/\_public/src/js/\*.js', '../engine/Shopware/Plugins/\*\*/Frontend/\*\*/js/\*\*/\*.js'], tasks: ['uglify'] } }, jshint: { options: { browser: true, force: true, globals: { jQuery: true, StateManager: true } }, src: ['Gruntfile.js', '../themes/Frontend/\*\*/\_public/src/js/\*.js', '../engine/Shopware/Plugins/\*\*/Frontend/\*\*/js/\*\*/\*.js'] } }); grunt.loadNpmTasks('grunt-contrib-less'); grunt.loadNpmTasks('grunt-contrib-watch'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.registerTask('production', ['jshint', 'less:production', 'uglify:production']); grunt.registerTask('default', ['less:development', 'uglify:development', 'watch']); };
Danke für deine Anpassungen, hat mir sehr weitergeholfen. Ich möchte vielleicht ergänzen: Wenn man auf relative Pfade umstellt, muss man natürlich auch die font-Variablen am Anfang der grunt.js-Datei anpassen, falls man die Shopware/Opensans-Webfonts weiternutzen möchte. variables = { 'font-directory': '"../../themes/Frontend/Responsive/frontend/\_public/src/fonts"', 'OpenSansPath': '"../../themes/Frontend/Responsive/frontend/\_public/vendors/fonts/open-sans-fontface"' }; wird respektive zu: variables = { 'font-directory': '"../../fonts"', 'OpenSansPath': '"../../../vendors/fonts/open-sans-fontface"' }; Dann setzt der Task die Pfade wieder richtig zusammen.
Noch mal ein Frage hierzu, ich vermute dass geht in die selbe Richtung: Ich habe ein Theme erstellt, dass ich vom Responsive ableite. Da der Kunde nicht selbst irgendwelche Farben verstellen soll, habe ich in der Theme.php folgendes eingetragen: protected $inheritanceConfig = false; Das soll verhindern, dass das Theme die Konfiguration des parent Themes übernimmt. Meinem Theme habe ich ein .less Datei mit den Standardwerten hinzugefügt, die ich dann editieren kann: /\* Colors Basic \*/ @brand-primary: #fdc93b; @brand-primary-light: saturate(lighten(@brand-primary, 10%), 5%); @brand-secondary: #6d6e71; @brand-secondary-dark: darken(@brand-secondary, 15%); /\* Colors Gray \*/ @gray: #F5F5F8; @gray-light: lighten(@gray, 1%); @gray-dark: darken(@gray-light, 10%); @border-color: @gray-dark; /\* Colors Info \*/ @highlight-success: #2ECC71; @highlight-error: #E74C3C; @highlight-notice: #F1C40F; @highlight-info: #4AA3DF; /\* Colors \*/ @body-bg: #f1f1f1; @text-color: @brand-secondary; @text-color-dark: @brand-secondary-dark; @link-color: @brand-primary; @link-hover-color: darken(@link-color, 10%); @rating-star-color: @highlight-notice; @overlay-bg: #000000; @overlay-opacity: 0.7; /\* Buttons & Panels \*/ /\* Global \*/ @btn-font-size: 14; @btn-icon-size: 10; /\* Default Button \*/ @btn-default-top-bg: #FFFFFF; @btn-default-bottom-bg: @gray-light; @btn-default-hover-bg: #FFFFFF; @btn-default-text-color: @text-color; @btn-default-hover-text-color: @brand-primary; @btn-default-border-color: @border-color; @btn-default-hover-border-color: @brand-primary; /\* Primary Button \*/ @btn-primary-top-bg: @brand-primary-light; @btn-primary-bottom-bg: @brand-primary; @btn-primary-hover-bg: @brand-primary; @btn-primary-text-color: #FFFFFF; @btn-primary-hover-text-color: @btn-primary-text-color; /\* Secondary Button \*/ @btn-secondary-top-bg: @brand-secondary; @btn-secondary-bottom-bg: @brand-secondary-dark; @btn-secondary-hover-bg: @brand-secondary-dark; @btn-secondary-text-color: #FFFFFF; @btn-secondary-hover-text-color: @btn-secondary-text-color; /\* Secondary Button \*/ @panel-header-bg: @gray-light; @panel-header-font-size: 14; @panel-header-color: @text-color; @panel-border: @border-color; @panel-bg: #FFFFFF; /\* Forms \*/ /\* Labels \*/ @label-font-size: 14; @label-color: @text-color; /\* Form Styling \*/ @input-font-size: 14; @input-bg: @gray-light; @input-color: @brand-secondary; @input-placeholder-color: lighten(@text-color, 15%); @input-border: @border-color; /\* Form Status \*/ @input-focus-bg: #FFFFFF; @input-focus-border: @brand-primary; @input-focus-color: @brand-secondary; @input-error-bg: desaturate(lighten(@highlight-error, 38%), 20%); @input-error-border: @highlight-error; @input-error-color: @highlight-error; @input-success-bg: #FFFFFF; @input-success-border: @highlight-success; @input-success-color: @brand-secondary-dark; /\* Tables & Badges \*/ /\* Tables \*/ @panel-table-header-bg: @panel-bg; @panel-table-header-color: @text-color-dark; @table-row-bg: #FFFFFF; @table-row-color: @brand-secondary; @table-row-highlight-bg: darken(@table-row-bg, 4%); @table-header-bg: @brand-secondary; @table-header-color: #FFFFFF; /\* Badges \*/ @badge-discount-bg: @highlight-error; @badge-discount-color: #FFFFFF; @badge-newcomer-bg: @highlight-notice; @badge-newcomer-color: #FFFFFF; @badge-recommendation-bg: @highlight-success; @badge-recommendation-color: #FFFFFF; @badge-download-bg: @highlight-info; @badge-download-color: #FFFFFF; Wenn ich das Theme aus dem Shopware Backend kompiliere, funktioniert es auch. Wenn ich aber das Theme mit Grunt kompiliere funktioniert es nicht. Dann wird das Theme statt mit den Werten aus meiner .less Datei (siehe oben) mit den Werten aus der Konfiguration des Responsive Themes kompiliert. Woran liegt das? Kann man das im gruntfile anpassen? Sorry ich bin Grafiker und mit Scriptsprachen habe ich es nicht so - eher HTML, css und less … Danke Andreas PS: Mal eine persönliche Anmerkung zu den Themes. Das ist jetzt mein zweites Theme das ich umsetze, sonst habe ich Drupal und Joomla Erfahrung. Das mit den Template Dateien und Smarty funktioniert ganz gut aber mit der less Kompilierung hat man zuviel gewollt. Viele Dinge die im Ansatz und in der Theorie gut sind, funktionieren im Alltag einfach nicht. Jeder Frontend Entwickler hat sowieso einen less/sass Compiler und die laufen schnell und performant. Wenn man sich da nicht mit den Pfaden und dem komischen unitize und was es da noch gibt so selbst ins Knie geschossen hätte könnte man einfach in einer normalen Entwicklungsumgebung arbeiten und gut. Wenn das mit grunt problemlos funktionieren würde OK - aber so … meine Meinung
[quote=“analog.eins”] protected $inheritanceConfig = false; [/quote] Oh, super. Seit welcher Version gibt es dieses Flag denn? Oder habe ich es bisher einfach übersehen :shock: [quote=“analog.eins”] Wenn ich das Theme aus dem Shopware Backend kompiliere, funktioniert es auch. Wenn ich aber das Theme mit Grunt kompiliere funktioniert es nicht. Dann wird das Theme statt mit den Werten aus meiner .less Datei (siehe oben) mit den Werten aus der Konfiguration des Responsive Themes kompiliert. Woran liegt das? Kann man das im gruntfile anpassen? Sorry ich bin Grafiker und mit Scriptsprachen habe ich es nicht so - eher HTML, css und less … [/quote] Das dürfte auch irgendwie mit meinem Problem zusammenhängen. Ich denke das hier einfach mit der Grunt die Dateien in einer anderen Reihenfolge compiliert werden wie im Standard. Denn genau das gleiche Phänomen habe ich auch… -.- Bisher habe ich hier aber nicht noch mehr Energie investiert um das Problem zu lösen, da es bei mir wirklich nur auf Farben Einfluss nimmt. [quote=“analog.eins”] PS: Mal eine persönliche Anmerkung zu den Themes. Das ist jetzt mein zweites Theme das ich umsetze, sonst habe ich Drupal und Joomla Erfahrung. Das mit den Template Dateien und Smarty funktioniert ganz gut aber mit der less Kompilierung hat man zuviel gewollt. Viele Dinge die im Ansatz und in der Theorie gut sind, funktionieren im Alltag einfach nicht. Jeder Frontend Entwickler hat sowieso einen less/sass Compiler und die laufen schnell und performant. Wenn man sich da nicht mit den Pfaden und dem komischen unitize und was es da noch gibt so selbst ins Knie geschossen hätte könnte man einfach in einer normalen Entwicklungsumgebung arbeiten und gut.[/quote] Der große Vorteil liegt halt darin, das man die Themes nachträglich sehr einfach konfigurieren kann, wenn LESS Variablen verwendet wurden. Genau das wird ja im Responsive Theme gemacht und wäre ohne eine LESS Kompilierung in Shopware nicht möglich. Zudem kann man auch in den eigenen Plugins usw. auf genau diese Variablen zugreifen und so das Plugin automatisch optisch an den Standard angleichen. Aber du hast schon recht, solange Grunt nicht richtig funktioniert macht es die Entwicklung von individuellen Themes nur unnötig schwierig und zeitintensiv.
[quote=„svenfinke“] Der große Vorteil liegt halt darin, das man die Themes nachträglich sehr einfach konfigurieren kann, wenn LESS Variablen verwendet wurden. Genau das wird ja im Responsive Theme gemacht und wäre ohne eine LESS Kompilierung in Shopware nicht möglich. Zudem kann man auch in den eigenen Plugins usw. auf genau diese Variablen zugreifen und so das Plugin automatisch optisch an den Standard angleichen. Aber du hast schon recht, solange Grunt nicht richtig funktioniert macht es die Entwicklung von individuellen Themes nur unnötig schwierig und zeitintensiv.[/quote] Da habe ich mich nicht klar ausgedrückt. Ich bin ein großer LESS Fan und setze das vielfach ein. Die Kompilierung ist das Problem. Beispiel: Ich habe gestern den ganzen Tag an einem Theme gearbeitet und dann habe ich irgendeinen Fehler gemacht und das Theme kann nicht mehr kompiliert werden weil Variablen in den Plugin .less Dateien nicht definiert sind??? Meines erachtens läuft das ganze nicht stabil. Durch die komplizierten Pfade und durch unitize (wo kommt das eigentlich her) ist eine Kompilierung mit den üblichen Tools nicht möglich. Zu dem oben geannten Problem. Wenn man ein dump der Theme Configuration erstellt(web/cache/config_1.json) wird die oben genannte Flag ignoriert und in config stehen alle Werte aus dem parent Theme, in meinem Fall das Responsive Theme. Wenn man alle Werte bis auf shopware-revision aus dem .json File löscht funktioniert ist. Ist natürlich keine Lösung, das ist ein Bug im Gruntfile, dass inheritanceConfig nicht berücksichtig wird.
Hallo Niklas, vielen Dank für die Rückmeldung. Ich versuche schon lange einen vernünftigen Workflow für die Shopware Theme Entwicklung hinzubekommen - und ich komme nur sehr zäh voran und bin für jede Rückmeldung dankbar. Du hast natürlich recht. unitize ist ein mixin. Mir war nich klar, woher dass kommt weil ich dachte, dass das Bare Theme überhaupt keine less Dateien hat und deshalb habe ich im Responsive nachgeschaut. Eine Frage: Was meinst Du mit on the fly kompilieren. Ins Backend gehen und im Theme Manager kompilieren? Dagegen spricht nicht viel - aber mit Geschwindigkeit durchaus gewichtiges. Oder kann ich auch beim Seitenaufruf / Reload kompilieren? Wie? Zu den Fehlern: Das Problem ist: Ich habe keine Variable verwendet die nicht existiert. Ich musste die entsprechenden Plugins deinstallieren und wieder installieren und dann hatte less auch wieder die Variablen. Ich wiederhole mich: less ist eine gute Sache aber die Kompilierung in Shopware sehr instabil. Ich weiß nicht woher die Plugins die less Variablen haben - aber offensichtlich hat ein Pfad nicht gestimmt?
[quote=“TeichDatensysteme”] Zu den Fehlern: Wenn Du natürlich eine Variable verwendest die z.B. nicht existiert, dann knallt das in jedem LESS compiler - das ist jetzt keine Shopware Eigenheit 
[/quote] na ja, das stimmt natürlich, aber man bekommt die Fehlermeldung nicht nur einen kurzen Augenblick in einer klitzekleinen Dialogbox angezeigt. Es ist schon mühsam, diese schnell zu lesen. Und gegen “on the fly” Kompilierung spricht gerade die benötigte Zeit, mal abgesehen von dem Error-Reporting.
[quote=“analog.eins”]Eine Frage: Was meinst Du mit on the fly kompilieren. Ins Backend gehen und im Theme Manager kompilieren? Dagegen spricht nicht viel - aber mit Geschwindigkeit durchaus gewichtiges. Oder kann ich auch beim Seitenaufruf / Reload kompilieren? Wie?[/quote] Eben das muss man nicht mit Grunt. Du startest also einmal lokal in deiner console “grunt watch” und grunt schaut automatisch ob eine less/js Datei geändert worden ist. Ist das der Fall kompiliert Grunt automatisch die nötige CSS Datei. Du muss also eben nicht jedes mal ins Backend gehen, Theme neu kompilieren und warten bis es neu kompiliert ist. Das macht Grunt bei jeder gespeicherten Änderung deiner less / js Dateien automatisch. @all Hier habe ich übrigens einen kleinen Artikel geschrieben, wir Ihr in Grunt Desktop Benachrichtigungen implementieren könnt. Ihr bekommt also sofort eine Meldung ob der Task durchgelaufen ist oder nicht: https://blog.hostianer.de/shopware-5-gr … ichtigung/ Man muss hier also auch nicht immer in die Console schauen, ob der Task durchgelaufen ist, sondern bekommt direkt die Desktop Benachrichtigung.
[quote=“TeichDatensysteme”] Mh, die Plugin Landschaft ist da eig. gut gelöst, kenne solche Probleme nicht. Vielleicht war das ja was bei Dir im Cache? … [/quote] Beispiel: Ich habe eben gerade die letzte Shopware Version heruntergeladen, installiert und das Paypal Plugin installiert. Dann habe ich das Bare Theme zugewiesen und kompiliert. Ergebnis: Es ist ein Fehler aufgetreten Während der Bearbeitung von Shop "XXXXX" ist ein Fehler aufgetreten: variable @border-color is undefined in file /var/www/html/xxx\_03/engine/Shopware/Plugins/Community/Frontend/SwagPaymentPaypal/Views/responsive/frontend/\_public/src/less/paypal-sidebar.less in paypal-sidebar.less on line 2, column 31 1| .paypal-sidebar { 2| border-bottom: 1px solid @border-color; 3| 4| .paypal-sidebar--logo { 5| display: block; 6| margin: 0 auto; Das erfreut mich nicht. Ich glaube ich verstehe warum das so ist (Plugins verwenden Variablen aus dem Responsive Theme??) aber … das sind Abhängigkeiten die das ganze sehr fragil machen (wenn es so ist). So wie Bare die ganze Seite ohne Styles ausgiebt müsste dann auch das Plugin ohne Styles ausgegeben werden (mindestens als Fallback). Und das ist natürlich kein less Problem sondern … Noch mal: Das ist sicherlich gut gemeint, aber die Komplexität und die Abhängikeiten sind so hoch und ähnliche Fehler sind mir schon häufiger aufgefallen
Hallo Niklas, ich finde Deine Antwort grenzwertig. Ich habe die Dokumentation gelesen, mir ist klar, dass Bare keine Styles hat. Mir ist auch klar wofür das Responsive Theme ist. Ich habe irgendwo übersehen, dass das Paypal Plugin nur mit dem Responsive Theme oder Themes die davon vererbt sind funktioniert. Ich entwickle einfach auch für andere Systeme Themes und wenn dort kein Theme installiert ist werden Plugins meistens einfach ohne Styles ausgeliefert. Ich bin dankbar für solche Hinweise - das mit den Plugins habe ich einfach überlesen - aber einfach davon auszugehen ich hätte die Dokumenation nicht gelesen ist … Grüße Andreas
[quote=“analog.eins”]Hallo Niklas, ich finde Deine Antwort grenzwertig. Ich habe die Dokumentation gelesen, mir ist klar, dass Bare keine Styles hat. Mir ist auch klar wofür das Responsive Theme ist. Ich habe irgendwo übersehen, dass das Paypal Plugin nur mit dem Responsive Theme oder Themes die davon vererbt sind funktioniert. Ich entwickle einfach auch für andere Systeme Themes und wenn dort kein Theme installiert ist werden Plugins meistens einfach ohne Styles ausgeliefert. Ich bin dankbar für solche Hinweise - das mit den Plugins habe ich einfach überlesen - aber einfach davon auszugehen ich hätte die Dokumenation nicht gelesen ist … Grüße Andreas[/quote] Das ist in der Tat etwas problematisch, da stimme ich dir zu. Das einfachste wäre sicherlich auch bei eigenen Themes immer die variables.less einzubinden, auch wenn man diese Variablen nicht unbedingt verwendet oder zur Konfiguration freigibt. Dadurch verhindert man auftretende Fehlermeldungen. Hier muss man einfach Kosten/Nutzen abwägen. Der Nutzen das man als Pluginhersteller auf Variablen zugreifen kann, um das Plugin optisch an den Shop anzugleichen; Gegen die Kosten das es mit Themes die auf dem Bare basieren oder komplett custom sind nicht einfach so funktioniert. In diesem Fall finde ich die Kosten akzeptabel, auch wenn es für Themehersteller natürlich etwas umständlich ist. In der Dokumentation sollte das aber vielleicht trotzdem erwähnt werden. Sonst erlebt man womöglich nachträglich ein böses erwachen.
Das Bare Theme hat KEINE Styles! Kein Less, kein JS, nix - das sind nur die Daten, Templates und Smarty Blöcke.
@TeichDatensysteme Wäre es möglich dass du dir das Bare Theme nie wirklich angesehen hattest? Dann wüsstest du auch dass das Bare z.B. sehr wohl LESS besitzt (genauer gesagt mixins und variables). Bevor du zu schnell etwas äußerst bei dem du selbst nie nachgesehen hast, so würde ich vorher mir wenigstens den kleinen Aufwand machen selbst einmal dann nachzusehen bevor selbstsicher geredet wird und damit hier andere im Forum nicht mit falschen Informationen versorgt werden. Denn genau solche Szenarien kosten dann nämlich extra Zeit, da bei einer Lösungssuche man durch falsche Informationen irre geführt wird.
Und wenn Dir das mit den Pfaden zu kompliziert ist - was spricht gegen das „on the fly“ kompilieren? Dauert etwas länger, aber es funktioniert ja.
Etwas länger? Schon mal knapp 40-50 Plugins und 2-3fache Theme-Vererbung mit Multishops in einem Projekt gehabt (allerdings selbst in mittelgroßen Szenarien teilw. schon problematisch)? Ich ja, das dauert 20-60sec. zum Neu aufbauen, das ist alles andere als akzeptabel (und ja, es wurden sämtliche Optimierungen vorgenommen um den Prozess zu beschleunigen). Da du scheinbar an recht einfachen Szenarien arbeitest, bedeutet das nicht dass es andere auch tun. Alleine der Satz, …es funktioniert ja… Wenn es besser geht (vor allem wenn ein Projekt umfangreicher ist), wieso sollte man es dann nicht gemeinsam besprechen und ausarbeiten wollen? Ich sehe bisher nur kontra-produktive Antworten ohne sich selbst einmal genauer mit der „Grunt“ Materie beschäftigt zu haben.
@analog.eins Da ich selbst das Problem schon mal hatte, allerdings aus Zeitgründen nicht noch mehr Zeit für eine Lösung verwenden wollte, so habe ich die Anpassungen über ein Shell-Script zwischen den JSON Configs (web/cache/config_1.json, web/cache/config_2.json, usw., in denen sich auch die Theme Variables für Grunt befinden) und den eigenen Theme LESS Variables (die die vordefinierten SW Variablen überschreiben sollen, wie in deinem Beispiel) syncen / migrieren lassen (sozusagen ein eigener Watcher der auf Änderungen reagiert und die Einträge synct), ist jetzt allerdings auch nicht die eleganteste und einfachste Lösung, aber es tut was es tun soll. Die andere Alternative ist, du definierst die Werte direkt in deiner eigenen Theme.php wie sie auch in der Responsive Theme.php zu finden ist, die meiner Meinung nach allerdings nahezu keine Übersichtlichkeit und Komfort darstellt sobald man alle abhängigen Anweisungen eintragen muss, Stichwort wäre hier auch „createConfigSets“ soweit ich mich erinnern kann (dann am besten noch den SW Cache leeren „cd var/cache && ./clear_cache.sh“, und zu guter letzt die Configs neu Aufbauen „php ./bin/console sw:theme:dump:configuration“, dann grunt starten). Bei Mehrfachvererbenden Themes mit zusammenhängenden Configs und je nach Aufbau kann es allerdings schon mal recht schnell chaotisch werden und dort sind noch ein paar extra Dinge zu beachten, daher gehe ich darauf erstmal nicht näher ein. Ich wollte aber demnächst sowieso einmal dafür ein Ticket bei SW ausstellen und mit einem der Techniker darüber reden um eine bessere Lösung zu finden, da der derzeitige Grunt-Entwicklungsprozess bei SW doch etwas starr und unhandlich ist, hierzu werde ich mich melden sobald es neue Informationen gibt und sie hier posten.
Hallo Ihr Lieben,
erst einmal vielen Dank für die vielen Infos und die angeregte Diskussion. Habe den Thread mit Spannung verfolgt. Wenn ich es richtig interpretiere, sind zwei wesentliche Punkte für Euch problematisch:
1. Ein geeigneter Weg um die Variablen aus der vererbten Theme Config statisch im LESS zu überschreiben, mit dem Hintergedanken, dass der Kunde im Backend nichts editieren soll.
Für das Editieren im Backend habt Ihr ja bereits richtig erkannt, dass man hierfür die _ $inheritanceConfig Variable setzen kann. Bleibt also das Überschreiben der Default-Variablen beim Kompilieren mit Grunt. Hier ist das Problem, dass die Variablen aus der generierten Config File via modifyVars _ in den Compiler gegeben werden. Dadurch werden alle Variablen global überschrieben. Ich habe hierzu mal ein Test gemacht, ob das mit den Variablen nicht auch anders gelöst werden kann. Meinen Test habe ich Euch mal als Gist auf GitHub verfügbar gemacht. Diese alternative Gruntfile kommt in das /theme Verzeichnis. Hier werden die Variablen direkt in die File geschrieben, so dass man diese später auch statisch im LESS überschreiben könnte.
A test for an alternate gruntfile for Shopware to override LESS variables locally. · GitHub
Bitte beachtet: Dies ist nur als Test gedacht. Kein offizieller Support! - Leider kann man Text im Forum nicht rot einfärben
Ich würde hier einfach gerne mal Euer Feedback haben. Sollte das für Euch fehlerfrei funktionieren, würde ich das in eines der kommenden Releases einplanen.
2. Das Zusammenspiel von Plugins und eigenen Themes wenn vom Bare Theme abgeleitet wird.
Hier ist es natürlich etwas schwieriger, da die Plugins nunmal alle auf das Responsive Theme aufbauen, da dieses als eigentliches Standard-Theme von Shopware supported wird. Mit dem Bare Theme wollten wir Euch einen einfacheren Einstieg bei sehr individuellen Store-Konzepten schaffen. Allerdings muss man sich hier auch im klaren sein, dass das Ableiten von Bare ein deutlich größerer Aufwand ist, da man für sämtliche Kompatibilität selbst verwantwortlich ist. Die nützlichen Mixins wie das Unitize wollten wir Euch dennoch zur Verfügung stellen. Daher findet Ihr diese Mixins schon im Bare.
Ich freue mich über Euer weiteres Feedback und eine angenehme Diskussion.
Solltet Ihr noch weitere nützliche Infos aus Eurem täglichen Entwickler-Leben haben, nehme ich diese gerne in unsere weitere Planung mit auf.
Sonnige Grüße,
Euer Phil
Ich nutze Grunt gar nicht. Ist das Ding nur dazu da um LESS zu rendern?
Gruss
@TeichDatensysteme Wäre es möglich dass du dir das Bare Theme nie wirklich angesehen hattest? Dann wüsstest du auch dass das Bare z.B. sehr wohl LESS besitzt (genauer gesagt mixins und variables). Bevor du zu schnell etwas äußerst bei dem du selbst nie nachgesehen hast, so würde ich vorher mir wenigstens den kleinen Aufwand machen selbst einmal dann nachzusehen bevor selbstsicher geredet wird und damit hier andere im Forum nicht mit falschen Informationen versorgt werden. Denn genau solche Szenarien kosten dann nämlich extra Zeit, da bei einer Lösungssuche man durch falsche Informationen irre geführt wird.
Ok - mixins sind da - trotzdem keine Styles in dem Sinne.
Das keine LESS in dem damaligen Stand drin waren sehe ich ein das es falsch war, der Rest stimmt ja trotzdem wie beschrieben (nicht die angesprochenen Variablen, keine Styles, JS …) Aber so eine Grundsatz"einweisung" zu geben ist doch etwas drüber, ich bin schon lange hier im Forum und habe schon sehr vielen Menschen weitergeholfen - ist ja nicht so, das hier hier nur Quatsch verbreite. Kannst gerne meine Tickets, meine Posts und Antworten durchgehen - da wird schnell klar, dass ich mich sehr wohl immer gut mit dem Thema beschäftige und definitiv die Thematik immer weitergebracht habe. Vielleicht nicht in diesem Posting 100% (sehe ich ein), aber sonst generell. Deswegen will ich mich hier nicht grundsätzlich als falsche oder ungenaue Quelle abstempeln lassen, stimmt einfach nicht.
Update: Ich habe mir das nochmal durchgelesen, war ja schon die 2. negative Stimme zu meinen Beiträgen hier nun.
Vielleicht reizt das Thema, egal - jedenfalls hatte ich ja schon angekündigt, mich aus diesem Beitrag zu entfernen - hatte ich jetzt leider wieder gebrochen.
Jetzt das 2. mal angefaucht zu werden, obwohl man versucht zu helfen ist strange und voll daneben - man kann man ja mal etwas gemäßigter in solche Diskussionen gehen. Deswegen habe ich meine Antworten hier einfach mal gelöscht, um mich vollständig aus diesem Beitrag rauszuhalten, das ist mir irgendwie zu blöd 
Ich nutze Grunt gar nicht. Ist das Ding nur dazu da um LESS zu rendern?
Gruss
Ja - Grunt kompiliert die nötigen Less / JS Dateien. Wenn man in der Theme Entwicklung ist, ist dieses Vorgehen unabdingbar meiner Meinung nach. Ansonsten musst du ja alle paar Minuten dein Theme im Backend kompilieren - Und das frisst ordentlich Zeit.
Hier erledigt dann Grunt für dich alles automatisch, sobald du eine Änderung an einer Datei durchführst. Das ganze dann noch mit Browsersync erweitern und du musst nicht einmal mehr deine Seite manuell reloaden.
Das alles sind eben Tools die die Arbeit erleichtern und da wir alle faule Entwickler sind natürlich extrem viel Zeit sparen.
Hallo zusammen,
ich kämpfe mich nun nach langer Shopware Abwesenheit wieder durch die Template-Entwicklung. Das bedeutet aktuell konkrett: Styling mit less.
Mir gefallen viele Ideen und Ansätze von Shopware 5, aber eine Sache bekomme ich nicht in den Griff:
- Ich habe ein custom-theme welches von responsive erbt (nennen wir es " Bermuda")
- Ich nutze den grunt task & watcher
- Ich möchte _alle_ less variablen selber in meinem Theme verwalten und _nicht_ über das Shopware Backend oder die Theme-Konfiguration. < hier komme ich nicht weiter.
Meine Versuche bisher:
- In Bermuda alle less-variablen kopiert und in all.less an erster Stelle eingebunden
- werden für meine custom-anpassungen natürlich genommen, weil meine components + co nach mit meinen variablen kompilieren
- Bermuda wird später als bare + responsive kompiliert, meine variabeln werden also nicht berücksichtigt
- Angepassten grunt-task von [@Philipp Schuch](http://forum.shopware.com/profile/13283/Philipp Schuch “Philipp Schuch”) genommen und variablen in all.less überschrieben
- klappt nicht, da der watch die all.less jedes mal neu generiert
- Angepassten Grunt-Task und variablen in config_1.json überschrieben
- Klappt so halbwegs, neue Custom Variablen wollen bei mir nicht
- Bei einer erneuten Generierung der config werden wieder die werte aus dem theme genommen > nix mit update-sicher
Ich suche also einen Weg wie ich…
- … variablen für das (bare)-responsive-theme (in meinem Template) definieren kann (“the bootstrap way” > variablen.less anpassen & done)
- … das ganze Updatesicher ist
- … ich die Variablen _nicht_ über das Backend setzen muss
- … ich keine komplett eigene Theme.php config schreiben muss, das ist zwar theoretisch machbar, aber nicht Praxinah - erst recht zum Beginn der Umsetzung wo Werte, Variablen, & co noch ständig umgeschmissen werden und es mit zusätzlichen Custom-Variablen auch nur (noch) nerviger wird.
Ich hoffe, hier hat jemand einen Ansatz für mich.
Ansonsten 
für Shopware 5.x und das Responsive-Theme - um einiges angenehmer als 4.x 
Nächtliche Grüße
Tim
Ich habe eine etwas hemdsärmelige Lösung für das Problem erfunden: Ich erzeuge mir aus der „config_1.json“ einfach eine „config_1.less“, in der ich alle benötigten Variablen ablege - danach füge ich die so erzeugte LESS-Datei in der „config_1.json“ an erster Stelle ein, so dass eigene Variablen-Definitionen dies wiederum überbügeln können.
Das PHP-Skript dazu sieht wie folgt aus:
$value) {
if (empty($value)) {
$value = 'false';
}
$less .= '@' . $key . ': ' . $value . ";\n";
}
}
return $less;
}
?>
Die Generation der Grunt-Konfiguration sieht dann wie folgt aus:
php src/bin/console sw:theme:dump:configuration && tools/modify-grunt-config.php
Edit: Vergesst die PHP-Bastelei, der Gruntfile von [@Philipp Schuch](http://forum.shopware.com/profile/13283/Philipp Schuch „Philipp Schuch“) löst das Problem deutlich eleganter.
Hallo,
@WESTWERK
Was genau meinst Du mit „da der watch die all.less jedes mal neu generiert“? Die all.less Dateien aus den Themes werden ja nie überschrieben. Es wird in dem Grunt Task nur eine temporäre all.less im Cache Ordner erstellt, welche alle Dateien aus den verschiedenen Vererbungsebenen sammelt. Deine eigenen Dateien sind davon unberührt. Wo genau hast Du denn Deine Variablen eingebunden?
@wnboes
Genau das macht die alternative Grunt-File welche ich Euch zum Testen bereitgestellt habe.
Es gibt auch bereits ein Ticket um die Änderungen in Shopware zu übernehmen:
Shopware Issuetracker
Sonnige Grüße,
Phil
[@Philipp Schuch](http://forum.shopware.com/profile/13283/Philipp Schuch “Philipp Schuch”) Tatsache, den hatte ich ganz übersehen. Das ist tatsächlich eine deutlich bessere Lösung, und funktioniert bei mir auch ganz zauberhaft. Ich unterstütze den Plan, den Gruntfile in Shopware-Standard zu überführen.