Wave oder Flow mit child theme

oxid6
#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.
2 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