Danke für den Hinweis. Ich habe CSS Grid völlig verschlafen, bestimmt auch deswegen, weil ich für Grids immer Bootstrap herangenommen habe.
Ingesamt komme ich mit der Shopware-Frontendentwicklung nicht sehr gut klar, anders als im Backend. Ob das jetzt an dieser starren Ausrichtung aus gewisse Technologien liegt, weiß ich nicht.
Das Problem ist hier wohl eher, wenn man immer nur mit einem Framework wie Bootstrap arbeitet, dann verliert man das Auge für die Aufgaben außerhalb dieses Frameworks. Ist das gleiche als wenn ich bspw. nur mit Laravel arbeite und noch die blanko PHP geschrieben habe und jemand sagt mach mal ne DB Abfrage mit Blanko PHP, dann stehst du auch erstmal aufn Schlauch
Ich weiß allerdings nicht so recht, was im Frontend mega starr sein soll - Was willst du denn überhaupt genau machen? Wofür brauchst du ein fertiges Grid System?
Bisher schaut es wirklich sehr gut aus. Twig, Bootstrap 4 als Framework im Frontend, Sass, ES6, Vue.js - Evtl. macht es auch für dich mehr Sinn dich auf Shopware 6 zu fokussieren, anstatt dich noch komplett in 5 einzuarbeiten?
Bisher schaut es wirklich sehr gut aus. Twig, Bootstrap 4 als Framework im Frontend, Sass, ES6, Vue.js - Evtl. macht es auch für dich mehr Sinn dich auf Shopware 6 zu fokussieren, anstatt dich noch komplett in 5 einzuarbeiten?
Ja, Shopware 6 hört sich interessant an. Aber ich kann jetzt dem Kunden schlecht sagen, er soll mit seinem Shop, den er dringend haben möchte, bis Anfang 2020 warten, bis SW 6 produktionsreif ist. Aber ja, dass das ganze Wissen um SW5 quasi in dem Moment obsolet sein wird, wenn ich mit diesem Projekt fertig bin, ist schon eine ziemliche Spaßbremse.
Andererseits sollte SW aufhören, sich so Hals über Kopf gewissen Technologien zu verschreiben. Warum den Entwicklern Bootstrap vorgeben, wenn man mittlerweile vieles wirklich mit reinem CSS lösen kann, wie ich ja dank eurer Hinweise kapiert habe? So wird SW immer einen Schritt hinterher sein, anstatt den Entwicklern die Freiheit zu lassen, die Dinge zu wählen, die für sie am angemessensten sind.
Wenn ich im in den Smarty-Templates (also nicht in den Less-Dateien) eine Änderung mache, muss ich im Browser die Seite 2-3 Mal neu laden, bevor die Änderungen angezeigt werden; bin mir nicht sicher, womit das zusammenhängt? Livereload bei einer Änderung im CSS funktioniert tadellos (wenn auch langsam).
Wenn ich im in den Smarty-Templates (also nicht in den Less-Dateien) eine Änderung mache, muss ich im Browser die Seite 2-3 Mal neu laden, bevor die Änderungen angezeigt werden; bin mir nicht sicher, womit das zusammenhängt? Livereload bei einer Änderung im CSS funktioniert tadellos (wenn auch langsam).
Ich persönlich habe für Chrome noch die „Clear Cache“ Extension und das ganze auf CMD+D. Damit reloaded er die Seite und löscht gleichzeitig auch direkt den Browser Cache für diese.
Andererseits sollte SW aufhören, sich so Hals über Kopf gewissen Technologien zu verschreiben. Warum den Entwicklern Bootstrap vorgeben, wenn man mittlerweile vieles wirklich mit reinem CSS lösen kann, wie ich ja dank eurer Hinweise kapiert habe? So wird SW immer einen Schritt hinterher sein, anstatt den Entwicklern die Freiheit zu lassen, die Dinge zu wählen, die für sie am angemessensten sind.
Shopware ist nicht hinterher, sondern weit vorne im Gegensatz zu vielen anderen E-Commerce Lösungen. Aber wie so oft gehen hier natürlich auch Meinungen auseinander. Ich habe in meiner Laufbahn schon mit allen zu tun gehabt: Shopify, Magento, Woocommerce, Prestashop usw. Shopware ist nach meiner Ansicht das beste System und mit SW6 noch einmal ein ganzes Stück nach vorn gsprungen. Ich muss zugeben, dass dieser Extjs Kram grässlich war und vor allem recht eingeschränkt hat. Was ja jetzt der Vergangenheit angehört mit der 6er
Du brauchst auch nicht unbedingt auch das bestehende Responsive Theme aufbauen, was dir die Styles bereits mitgibt. Du könntest auch komplett von vorne starten. Nur macht es in den allerwenigsten Fällen Sinn, da es extrem viel Arbeit wäre alles komplett neu aufzubauen. Aber man kann es natürlich machen - So baust du dann praktisch auf dem Bare Theme auf und hast prinzipiell völlige Freiheit. Egal ob Bootstrap, Zurb, custom CSS, Sass oder Less usw.
Einzig an smarty bist du gebunden, aber das ist ja nicht so wild. Smarty ist veraltet, aber durchaus brauchbar und flexibel :)
Wenn ich im in den Smarty-Templates (also nicht in den Less-Dateien) eine Änderung mache, muss ich im Browser die Seite 2-3 Mal neu laden, bevor die Änderungen angezeigt werden; bin mir nicht sicher, womit das zusammenhängt? Livereload bei einer Änderung im CSS funktioniert tadellos (wenn auch langsam).
Die Einstellungen haben scheinbar geholfen, danke.
>Smarty ist veraltet, aber durchaus brauchbar und flexibel
Jo, habe gerade wieder eine halbe Stunde erfolglos damit aufgebraucht, die Produkt-Detailansicht zu erweitern, und nach stundenlangem detail_index_detail und Hin- und Herspringerei zwischen Bare, Responsive und dem eigenen Themchen ist man dann gottefroh um den Feierabend.
Wenn ich im in den Smarty-Templates (also nicht in den Less-Dateien) eine Änderung mache, muss ich im Browser die Seite 2-3 Mal neu laden, bevor die Änderungen angezeigt werden; bin mir nicht sicher, womit das zusammenhängt? Livereload bei einer Änderung im CSS funktioniert tadellos (wenn auch langsam).
Die Einstellungen haben scheinbar geholfen, danke.
>Smarty ist veraltet, aber durchaus brauchbar und flexibel
Jo, habe gerade wieder eine halbe Stunde erfolglos damit aufgebraucht, die Produkt-Detailansicht zu erweitern, und nach stundenlangem detail_index_detail und Hin- und Herspringerei zwischen Bare, Responsive und dem eigenen Themchen ist man dann gottefroh um den Feierabend.
Die Detail Ansicht ist teilweise etwas wirr von den Template Dateien, dass stimmt.
Wie ich vorgehe: Ich habe immer das Repo vom Bare Theme für die Markup Struktur bei Github offen für alle .tpl Files und Blöcke.
Und einen weiteren Tab mit dem Responsive Theme für die less & JS Dateien.
In der IDE springe ich gar nicht hin und her, dass sollte man meiner Meinung nach auch lassen. Da passiert es ganz schnell, dass man dann auf einmal was im Core Theme ändert usw.
Oder: In VisualCode kannst du bspw. die header headline färben. Dann hast du bspw. einmal nur das Bare Theme offen mit einer Farbe und dann das Responsive Theme mit einer Farbe. Sodass du es direkt unterscheiden kannst. Ist auch eine Möglichkeit. Ich habe aber lieber die Seiten in Github offen, sodass ich in der IDE nicht durcheinander komme.
>Die Detail Ansicht ist teilweise etwas wirr von den Template Dateien, dass stimmt.
Das ist die Untertreibung des Jahrhunderts, das Template-Chaos ist ein absoluter Alptraum, wenn man nicht nur das CSS etwas anpassen will, sondern auch Elemente wie Preis oder Artikelnummer herumschieben muss. Die Übersicht geht nahezu sofort verloren. Unlogisch ist es auch noch: die buy-container.tpl liegt unter details/content, die darin angezeigten actions.tpl liegen aber unter details/.
>Wie ich vorgehe: Ich habe immer das Repo vom Bare Theme für die Markup Struktur bei Github offen für alle .tpl Files und Blöcke.
Ein möglicher Ansatz. Allerdings finde ich es noch anstrengender, von der IDE in den Browser und dann dort in einen anderen Tab wechseln zu müssen, als in PHPStorm innerhalb der Scopes zu wechseln (eines für Bare, eines für Responsive etc), wodurch auch schon die Farben in den Reitern gegeben sind. Die Gefahr mit dem Überschreiben des falschen Templates ist dadurch verringert, existiert allerdings immer noch.
