Lokal entwickeln und testen

**Gausi** · 14.10.2018, 10:24

Ich bin mir zwar fast sicher, dass das irgendwo schon erklärt ist, aber ich steige da einfach nicht durch. Ich möchte ja (ich hoffe, ich nerve mit meinen Fragen nicht zu sehr) meine Kalender-Erweiterung zu einem Bundle machen, damit das auch hübsch unter Contao 4.4 läuft. Auf meinem kleinen Webserver zu testen habe ich jetzt langsam satt - das läuft absolut nicht performant, und wenn ich mir beim testen regelmäßig alles komplett zerschieße, macht das "online" absolut einen Spaß.

Aber wie mache ich das genau lokal? Wie funktioniert das mit dem Contao-Manager bzw. Composer zusammen?

Ich habe nun eine lokale XAMPP-Installation unter "c:\xampp", mit Contao 4.4 installiert in C:\xampp\htdocs\Contao4\web (Managed Edition, versteht sich), Document-Root auf diesen Ordner gesetzt. Also ganz so, wie es am Ende auch auf dem Webserver laufen sollte. Aufruf der Testseite über http://localhost bzw. http://localhost/app_dev.php .

Der Code meiner Erweiterung liegt lokal auf "F:\Github\Calendar-Editor". Das ist die lokale Version des Git-Repositories, das am Ende auch bei GitHub bzw. packagist.org landet und dann über den Composer installiert wird.

Frage: Wie kommt nun der neue Code von meinem lokalen Repository auf Platte F:\ nach "C:\xampp\htdocs\Contao4\vendor\<...>", ohne den Umweg über GitHub und Packagist?

"Irgendwas" mit der globalen Composer.json habe ich schon mitbekommen. Was genau, ist mir noch schleierhaft. Aber wie funktioniert das dann mit dem updaten, also wenn ich ein paar Zeilen Code verändert habe? Oder kann ich testweise sogar einfach die Dateien manuell kopieren, was deutlich schneller gehen würde als ständig den Manager zu bemühen, der dann jeweils ne halbe Minute (oder länger) rödelt und irgendwelche Dependencies auflöst, die sich aber während der Entwicklung nur ganz selten ändern?

**fiedsch** · 14.10.2018, 10:35

Du fügst der composer.json Deiner Contao Installation einen Abschnitt repositories hinzu. In etwa so:

Code:

 "repositories": [
        {
            "type": "path",
            "url": "F:\\Github\\Calendar-Editor",
        }
    ]

oder

Code:

 "repositories": [
        {
            "type": "path",
            "url": "F:\\Github\\Calendar-Editor",
            "options": {
                "symlink": true
            }
        }
    ]

Ich kann Dir allerdings nicht sagen, ob und wie das mit den Symlinks unter Windows funktioniert.

**Gausi** · 14.10.2018, 10:53

Ok, das scheint zu klappen (Also, Version 1 bis auf das Komma in der zweiten Zeile, das ist zu viel). Zumindest taucht der Pfad jetzt in der Konsolenausgabe beim Update auf. Danke dafür.

Als Verständnisfrage: Woher weiß der Manager nun, welche Version er nehmen soll? Haben die Verzeichnisse, die dort angegeben sind, einfach eine höhere Priorität als der Standard Packagist.org?

Und lässt sich das Update lokal nicht irgendwie noch beschleunigen? Ich habe beispielsweise in einer php-Datei eine Kleinigkeit korrigiert - meinetwegen bei einer Variable im Code das $ vergessen. Muss dann trotzdem der ganze Kram über den Manager gemacht werden? Denn das Update dauert auch lokal jeweils eine Minute (mehr oder weniger) - das ist doch grausig.

**fiedsch** · 14.10.2018, 11:15

Zitat von Gausi

Ok, das scheint zu klappen (Also, Version 1 bis auf das Komma in der zweiten Zeile, das ist zu viel).

Ja, sorry -- copy/paste Fehler

Und lässt sich das Update lokal nicht irgendwie noch beschleunigen? Ich habe beispielsweise in einer php-Datei eine Kleinigkeit korrigiert - meinetwegen bei einer Variable im Code das $ vergessen. Muss dann trotzdem der ganze Kram über den Manager gemacht werden? Denn das Update dauert auch lokal jeweils eine Minute (mehr oder weniger) - das ist doch grausig.

Wenn Du Symlinks verwendest sind die Quellen doch automatisch geändert. Dan musst Du ggf. nur den Cache löschen -- z.B. bei Änderungen an einer DCA-Datei.

Wenn Du (ohne Symlink) die Dateien in vendor/ kopiert hast, ist das dann Dein lokales Entwicklungsverzeichnis (Repository) und die Änderungen sollten ebenfalls sofort sichtbar sein.

**Gausi** · 14.10.2018, 13:32

Ah, das hört sich ja gut an, bzw. sieht beim ersten Test auch ganz gut aus. Mit den Symlinks werden in /vendor/ praktisch nur Verweise auf die eigentlichen Verzeichnisse bzw. Dateien angelegt, und Änderungen werden auch "direkt übernommen" (zumindest teilweise), d.h. F5 im Browser auf der Testseite und fertig. Ok, verstanden (hoffe ich).

Also kann man (zumindest nach der Installation der Erweiterung per Manager) doch "lokal" bzw. direkt in "vendor" (weiter-)entwickeln. Beim rumstöbern klingt das in den meisten Forenbeiträgen irgendwie anders. Als würde da der Manager noch ordentlich im Hintergrund rumzaubern müssen, damit das alles läuft, sobald auch nur ein Byte in den php-Dateien geändert wurde...