OXID6 Child-Themes auf Basis von WAVE-Parent erstellen

Originally published at: https://oxidforge.org/de/child-themes-basis-wave-parent-oxid6.html

Im Tutorial beschreibt Mario Lorenz, wie ein eigenes Child-Theme auf der Basis des mitgelieferten Wave-Themes für OXID erstellt werden kann.

2 Likes

Hi,

es ist immer etwas zeitraubend, die Ordnerstruktur im Childtheme anzulegen. Ich habe daher ein fertiges wave-child, in dem die Ordnerstruktur schon fertig enthalten ist, man muss nur noch die zu ändernden tpl-Datei reinkopieren.
Das Child installiert man einfach mit: composer require ecs/wave_child

1 Like

Hallo Mario,

warum änderst Du den Pfad für out im Gruntfile?

‘project: {
theme: ‘wavechild’,
dev: ‘./’,
out: ‘./out/’,
tmp: ‘./…/…/…/tmp/’,
modules: ‘./…/…/…/modules/’,
},’
Damit bleibt der ordner out doch unter views/child-theme.
‘out: ‘./…/…/…/out/’,’ wie im Original funktioniert.

prinzipiell ist das dafür gut, wenn man das Child Theme in einer eigenen Repository speichern möchte.
Ich hätte aber Bedenken, das eigene Theme als fremde Composer Dependency zu installieren. Irgendwann macht man ein Update und die eigenen Sachen sind futsch, weil die Datein aus der fremden Repo aktualisiert werden.

@Mario_Lorenz :wink:

@nickname: Ich lege die Verzeichnisse der Childtheme-Template-Dateien immer erst an, wenn ich sie brauche. Es gab bisher kein Child-Theme, wo ich wirklich alle Dateien angefasst und geändert habe. Aber Dein Ansatz ist auch nicht verkehrt.

@windes: Ich habe das Childtheme in einem Standalone-Repository, genau wie das Flow- oder Wave-Parent-Theme. In den Parent-Repositories sind die fertig compilierten CSS- und JS-Dateien auch Teil des Theme-Repositories. Mein Grunt-“watch” und “production”-Task generiert daher beim Entwickeln die Resourcen in den ./out/-Pfad.
composer update & composer install sorgen dann während der Installation dafür, das die Resourcen aus meinem Repository genau wie beim wave- oder flow-theme an die richtige Stelle kopiert werden.
Damit ich während des Entwickelns nicht permanent composer update & composer install durchführen muss, lasse ich in meiner lokalen Entwicklungsumgebung durch die IDE den out/childthemefolder/ aus dem ChildRepository in den Shop-out/childthemefolder/ syncen.
Am Ende des Tages, nachdem ich die aktuellen Anpassungen alle in das ChildRepository gepusht habe und per composer update & composer install frisch in den Shop ziehe, werden alle manuellen Anpassungen dann “offiziell” bereitgestellt.

Wenn man aber auf ein separates Child-Theme-Repository verzichtet und sein Child-Theme einfach in das Shop-Repository mit ablegt, kann man aber auch bei den Ordner-Vorgaben aus der Parent-Theme-Gruntfile.js bleiben.

@vanilla_thunder: Wo siehst Du ein Update-Problem? In das Standalone-Repository schreibe ich nur allein, da grätscht keiner rein und zerhaut mir etwas. Oder wie können die eigenen Sachen Deiner Meinung nach kaputt gehen?

Ich denke da an folgendes Szenario:
Shopbetreiber installiert über composer das child theme, die dependency ist nun registriert.
Shopbetreiber baut sein child theme in dem Ordner dieser Dependency. In der Zwischenzeit hat sich in der ursprünglichen Repo was geändert.
Dann kommt die halbjährliche Alarm-Stufe-Rot-Email von Marco: critical security issue, update asap sonst kaputt.
Shopbetreiber macht nun composer update und wird etwa 25 tausend mal gefragt, ob er einzelne Dependencies aktualisieren möchte. Das möchte er natürlich, er will ja keinen unsicheren Shop. Und Zack hat composer den Ordner mit dem aufgebauten Child Theme durch die frische Version aus der dependency Repo ersetzt, wo quasi nur das Grundgerüst drin ist.

Ahem… das kommt maximal einmal im Jahr und wenn dann vom Security-Team :wink:
Ich bin häufig mal an den Texten beteiligt.

Hi,

das Problem sehe ich so nicht, da bei dem von Dir beschriebenen Vorgang die bereits vorhandenen Modulordner nicht zuerst gelöscht werden.
Es werden nur die Originaldateien wieder drüber kopiert, zusätzliche eigene .tpl-Dateien bleiben erhalten.

Wer trotzdem ganz sicher gehen will, kann bei der Installation die Versionsnr. mit angeben, dann ändert sich garantiert nichts mehr (composer require x/y:1.0.0) .
Alternativ könnte man die Theme-Ordner einfach umbenennen oder die Abhängigkeit wieder entfernen (aus der composer.json löschen), braucht man ja eh nicht mehr.

Es geht schließlich nur darum, das Childtheme mit geringen Aufwand in den Shop zu laden, das geht via Composer einfach schneller und komfortabler als von der Festplatte per FTP hochladen.

@vanilla_thunder: Ahh, Ich habs verstanden.

Mein Ansatz ist, das dieses Childtheme-Repository nur für diesen Shop gilt. Ich verwende das Childtheme-Repository nicht als Basis für mehrere Shops. Daher kommt in dieses Repository wirklich alles rein, was dazu gehört. Bei einem Update kann also nichts verloren gehen, was nicht vorher schon da war.

Ich bin gar nicht auf die Idee gekommen, das ich das Child-Theme-Repository habe und dann noch zusätzlich weitere Anpassungen, die das Child-Theme betreffen, ausserhalb zu platzieren. Wenn ich das tun würde, wäre tatsächlich die Gefahr, das bei einem Update etwas verloren geht.