Theme / Website-Template - git repositories und composer install

[Franko]

Hallo,
ich benötige zum Thema eure Denkanstöße.
Ich hatte es schon mal in diesem Beitrag probiert - ohne Response - daher versuche ich es hier im Entwickler-Forum auch auf die Gefahr mich lächerlich zu machen ...

Hintergrund:
Lokal (Windows) benutze ich eine Contao Installation mit Demo Inhalten und zur Entwicklung der Layout Themes als Ausgangsbasis für weitere Installationen. Bei 3.5er Versionen hatte ich bisher entweder die kompletten Verzeichnisse und die Datenbank kopiert oder nur ein Theme Import (via .cto) durchgeführt. Für Contao 4 würde ich gerne zukünftig lokal die Theme Layouts mit git versionieren/verwalten und im Anschluß über composer als Installation inkl. Website-Template (.sql) bereitstellen - also in Anlehnung an die Contao Demo.

Zur Bereitstellung über packagist.org bin ich noch gar nicht - zum Testen reicht mir erst mal eine composer Installation direkt über ein GitHub,- (s. hier) o. lokales Repository (s. hier).

Git-Repository:
Jetzt scheitere ich bereits bei dem lokalen git repository. Nehme ich hierzu die vollständige, lokale Contao Installation und unterdrücke mittels .gitignore (wie in Beitrag) alles außer den benötigten Dateien? Wo setze/pflege ich dann die composer.json?

Oder sollte man hierzu ein separates, lokales git repository pflegen mit einer Verzeichnisstruktur analog zur Contao Demo (hier liegt alles im Ordner "src" - ist das zwingend)? Ich bearbeite dann also css/scss, Contao Theme Einstellungen, templates in der lokalen Installation, stelle ein Website-Template und schiebe dann entsprechende Daten in das git repository - fühlt sich umständlich an (Wie oft commited Ihr dann).
Denkanstöße/Vorgehensweisen hierzu wären toll ...

scss Workflow:
Ich nutze intern scss zur Theme/Layout Erstellung. Dies beinhaltet auch die entsprechenden package.json und node-scripts files. Das dabei im Theme Verzeichnis über eine lokale npm Installation dann auch der "node-modules" Ordner angelegt wird war mir bis dato egal - wurde ja nur zur lokalen Entwicklung herangezogen. Zukünftig möchte ich meine scss Struktur weiter aufsplitten - ähnlich wie ErdmannFreunde mit Ihrer euf_nutshell - also eine scss Ausgangsbasis für verschiedene Layouts. Nur:
Gehört das dann in ein Contao Theme/Demo repository? Die Contao Demo beinhaltet zwar auch scss Daten - allerdings pur ohne package.json, gulp etc.. Bleibt wohl eine Auslegungsfrage.

Allerdings verstehe ich nicht warum ErdmannFreunde mittlerweile einen eigenen Installer (euf_nutshell_installer) für das euf_nutshell_kit aufgestellt haben. Habe hierzu diese Beiträge gefunden:
- Contao 4 Erweiterung - Dateien nicht überschreiben
- Contao 4: gulpfile.js und package.json liegen unter /files
- Contao 4: Copy files outside files-folder with composer
Verstehe aber nicht wozu das notwendig ist ...

Wen man über composer ein (Contao Theme/Demo) repository installiert, das neben den reinen scss Dateien auch entsprechende node/gulp/etc. Daten bereitstellt - könnten diese doch irgendwo innerhalb von "files" liegen.
Denn wenn jemand die scss selbst modifizieren will - geschieht dies doch wohl immer lokal ...
Auch hier - Denkanstöße/Vorgehensweisen hierzu wären toll ...

Danke
Franko

[Spooky]

Es ist üblich alles was du zum builden brauchst in das Repository zu geben. Bspw. package.json, gulpfile.js, build.xml etc.. Je nach Projekt befinden sich auch die fertig kompilierten Dateien im Repository (siehe zB src und dist Ordner bei irgendwelchen JavaScript libraries).

[Franko]

Es ist üblich alles was du zum builden brauchst in das Repository zu geben. Bspw. package.json, gulpfile.js, build.xml etc.. Je nach Projekt befinden sich auch die fertig kompilierten Dateien im Repository (siehe zB src und dist Ordner bei irgendwelchen JavaScript libraries).

Danke Spooky,
in meiner Überlegung dachte ich an ein repository mit scss Struktur als Ausgangsbasis für weitere Themes die dann nach Bedarf diese nutzen/überschreiben (also im Sinne der euf_nutshell). Dies dann separat gepflegt und zur Installation/Update via composer bereitgestellt.
Dann jeweils weitere - analog zur Contao Demo - wobei hierbei aber halt zusätzlich in der composer.json obiges repository required wird.

Zu einfach gedacht?
Dachte ich jedenfalls, verunsichert bin ich dabei mit der aktuellen Vorgehensweise von ErdmannFreunde - daher dieser Beitrag ...

[tl_richard_user]

Hallo Franko,

ich habe vor Kurzem erst Mal zusammengefasst, wie ich das handhabe.
-> https://github.com/richardhj/contao-workflow

Der Vorteil, von dem euf_nutshell_kit ist, dass es eine ".gitignore" mitliefert, die Contao 4.4 LTS nicht in der Art hat. Außerdem gibt es eine ".htaccess", die wohl für die meisten Projekte geeignet sein dürfte.
Der euf_nutshell_installer ist eigentlich nur ein Tool, um bei der Installtion den Theme-Ordner etc. umzubenennen. Nach der Installation kannst du diesen natürlich aus der Composer.json entfernen.

Für die Sache mit der Datenbank hab ich auch eine relativ angenehme Lösung gefunden, ich muss sie aber noch mit ein paar mehr Projekten testen.

Wenn du alleine an Projekten arbeitest, dann hast du Recht, dass du nicht allzu oft commiten musst. dann reicht es eigentlich, wenn du 1x committest, wenn du das Projekt auf den Production Server bringen willst.

[Franko]

ich habe vor Kurzem erst Mal zusammengefasst, wie ich das handhabe.
-> https://github.com/richardhj/contao-workflow

Hi,
danke schaue ich mir an...

Der euf_nutshell_installer ist eigentlich nur ein Tool, um bei der Installtion den Theme-Ordner etc. umzubenennen. Nach der Installation kannst du diesen natürlich aus der Composer.json entfernen.

Ah, okay - kann man also so machen - muß man aber nicht ...

Hallo Franko,
Für die Sache mit der Datenbank hab ich auch eine relativ angenehme Lösung gefunden, ich muss sie aber noch mit ein paar mehr Projekten testen.

Hm,
das mit den git hooks ist interessant:

After copying the file, run chmod +x .git/hooks/pre-commit to make the hook executable.

Muß ich das für Windows auch so setzen ...

Wenn ich es richtig lese wird über Dein ".git/hooks/pre-commit" ein vollständiges sql dump zum import (via Console o. phpmyadmin) erzeugt.
Dieser ist nicht dann so nicht als Website-Template Import für den Contao Installer gedacht/geeignet wie es beispielsweise die Erweitereung "backupDB" erzeugt...

[tl_richard_user]

Wenn ich es richtig lese wird über Dein ".git/hooks/pre-commit" ein vollständiges sql dump zum import (via Console o. phpmyadmin) erzeugt.
Dieser ist nicht dann so nicht als Website-Template Import für den Contao Installer gedacht/geeignet wie es beispielsweise die Erweitereung "backupDB" erzeugt...

Kann gut sein, dachte aber immer, dass das Install-Tool einfach nur einen SQL-Dump verlangt.

Wenn ich ein Projekt auf live schiebe, ist ja die Datei var/sql/dump.sql vorhanden. Aufgrund des git-hooks.
Dann braucht es nur noch ein "mysql -u user -p mydatabase < dump.sql" auf dem Live-Server.

Ich kann so eine Webseite innerhalb von 5 Minuten auf Live deployen.
1. git clone
2. composer install
3. webseite root anpassen
4. mysql-import

[tl_richard_user]

Ich muss natürlich noch dazu sagen, dass die hooks wahrscheinlich auch nicht funktionieren werden, weil du ja kein "mysqldump" executable auf Windows hast. Also glaube ich.

[Franko]

Der euf_nutshell_installer ist eigentlich nur ein Tool, um bei der Installtion den Theme-Ordner etc. umzubenennen. Nach der Installation kannst du diesen natürlich aus der Composer.json entfernen.

Wenn ich mir die composer.json der Contao-Demo und der euf_nutshell anschaue werden die jeweiligen Daten nur nach "files" und/oder "template" kopiert.

Auszug Contao demo:

    "extra": {
        "contao": {
            "sources": {
                "src/files/contaodemo": "files/contaodemo",
                "src/templates/codv4.0.0_contao_4.4.3.sql": "templates/codv4.0.0_contao_4.4.3.sql",
                "src/templates/contaodemo": "templates/contaodemo"
            }
        }
    }

Ist es korrekt das man nur in diese Verzeichnisse kopieren kann?
Da das euf_nutshell_kit aber z.B. die gulpfile.js und package.js im root Verzeichnis legen wird die Vorgehensweise über deren installer benötigt.
Habe ich das so richtig verstanden?