Wave oder Flow mit child theme

Deutsches Forum
,
1

Wie ist denn mittlerweile der beste Weg ein child theme von flow oder wave zu erstellen?

Laut wave docs:

If you want to extend the theme you need to clone the repository (see section development) as some soures are ignored on composer installation.

Also soll man das theme nach source/Application/views clonen?
Das umgeht dann aber composer!?
Dann werden doch u.U. bei einem composer update (bzw meta-package update) Files überschrieben?
Das kann zu Inkonsistenzen führen.

Ich denke das Hauptproblem ist, dass die build files in die .gitattributes (https://github.com/OXID-eSales/wave-theme/blob/master/.gitattributes) gepackt worden ist und beim composer package excluded werden.
So kann man die Sass files nicht mehr importen.

Das macht ein korrektes extenden eigentlich unmöglich.
Oder verstehe ich da irgendein Konzept nicht.

2

Das hat mit diesem PR zu tun: https://github.com/OXID-eSales/flow_theme/pull/136
Verstanden hab ich das auch nicht. Nach meinem Verständnis sollte excluden direkt im Projekt-Deployment passieren.

3

Ich habe mir mein Wave-Child-Theme (das ich jetzt für alle weiteren Childs als Basis nehme) so erstellt:

  1. Parent Wave von github lokal geclont (lohnt sich immer, so sieht man immer, wie der aktuelle Entwicklungsstand ist)
  2. Ein eignes Repository für mein Child-Theme angelegt
  3. Aus dem Parent-Wave folgende Ordner bzw. Dateien kopiert:
  • /build
  • /grunt
  • .gitignore
  • composer.json
  • Gruntfile.js
  • package.json
  1. Alle o.g. Dateien angeschaut und auf mein Child-Theme hin umgeschrieben (wichtig in erster Linie die composer.json)
  2. Folgende Dateien angelegt und nach den Oxid-Child-Theme-Regeln befüllt
  • de/cust_lang.php
  • en/cust_lang.php
  • theme.php
  • readme.md
  1. Jetzt via npm die Gruntfiles installiert
  2. anschließend einen ersten Build-Prozess gestartet. Dadurch müsste sich folgender Ordner korrekt erstellen:
  • out/YOURTHEME/*
  1. Aus dem Parent-Out-Theme noch folgende Dateien kopiert, damit sie als Basis vorhanden sind (betrifft Favicons und Logos, die werden später sowieso von Dir während der Themeentwicklung überschrieben):
  • out/wave/img/* -> out/YOURTHEME/img/*
  1. Nachdem die ersten Build-Prozesse gut gelaufen sind, nach und nach die package.json, das SCSS und die Templates bearbeitet
  2. Mein Child-Theme-Repository dann als weiteres Theme in die composer.json des Shops eingetragen, composer update, und dann im Shop das Child-Theme auswählen.
3 Likes
4

Noch ein paar Gedanken:

Ich habe mein Child-Theme und alle von mir entwickelten Module in separaten Pfaden ausserhalb meiner OXID-Testinstallation abgelegt. In diesen Theme- und Modul-Ordnern befinden sich meine lokalen git-Repositories. Somit vermische ich hier nicht meine Shop-Installation mit meinen Enwicklungs-Modul- und Theme-Repositories.

Wenn ich am Child-Theme arbeite, lasse ich den grunt-watch-Task des Child-Themes laufen, der mir die Resourcen zur Laufzeit erzeugt. Ich habe mir meinen Watch-Task so angepasst, das er nur die Resourcen verbindet (concat) und nicht minimiert (uglify). So kann ich das CSS und das JS besser debuggen.

Ein zweiter Watch-Task (eine Kombination aus CPX (https://www.npmjs.com/package/cpx) und Concurrently (https://www.npmjs.com/package/concurrently)) beobachtet und kopiert sämtliche Änderungen in den Resourcen-Ordnern meines Themes und den Modul-Ordnern in meine OXID-Entwicklungsumgebung. Damit wird faktisch die composer-Installation meines OXID-Testshops partiell überschrieben.

Am Ende des Tages checke ich alle Änderungen in die Theme- und Modul-Repositories ein und führe ein composer-Update im Test-Shop durch. Der Testshop bekommt nun wieder seine saubere, composer-basierende Modul und Theme-Struktur zurück.

1 Like
5

Hallo Mario

das ist bestimmt ein Schreibfehler, einen Ordner Grunt habe ich noch nie gesehen.
Kopierst Du auch den gesamten /tpl Ordner ins Childtheme?

6

@windes:

Du hast Recht, den Grunt-Ordner gibt es nur im Flow-Theme. Im Wave-Theme sind alle separierten Grunt-Scripte wieder in die zentrale Gruntfile.js zurückgewandert. Ich persönlich fand die Trennung im Flow-Theme übersichtlicher. Für Kundenprojekte die auf Wave basieren, trenne ich das für meine persönliche Übersichtlichkeit nachwievor so auf.

Schau mal hier: OXID6 Child-Themes auf Basis von WAVE-Parent erstellen
Dort habe ich es zusammengefasst, wie ich an die wave-Child-Themes heran gegangen bin. In dem dortigen Beispiel befinden sich die Grunt-Scripte auch alle noch in der zentralen Gruntfile.js.

Und was den tpl-Ordner betrifft: Nein, ich kopiere nur die Tpl-Dateien in das Child-Theme, die ich für den Kunden anpasse.

  1. kümmert sich OXID darum, die bei mir “fehlenden” Tpl-Dateien aus dem Parent-Theme zu laden
  2. Bin ich schneller, wenn Parent-Theme-Updates kommen. Dann gehe ich im Wave-Theme-Git-Repository alle Anpassungen seit dem letzten Versions-Sprung durch Und nur wenn es “meine” Tpl-Dateien betrifft, die ich für den Kunden angepasst habe, entscheide ich dann, ob ich diese Anpassungen auch in “meine” Tpl-Datei mit übernehme.