Ergebnis 1 bis 13 von 13

Thema: Composer in Contao

  1. #1
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Frage Composer in Contao

    Hallo zusammen,

    ich habe mich versucht ein wenig in den Composer in Verbindung mit Contao einzuarbeiten und es kommen mir dabei ein paar Fragen auf. Vielleicht könnt ihr mir auf die Sprünge helfen. Zunächst mal die Ausgangslage:

    Die Eigenschaften die Composer als Dependency Manager mitbringt habe ich so verstanden: In den composer.json-Dateien werden die Abhängigkeiten mittels require angegeben. Dann wird mittels composer update bzw. initial mit composer install der Prozess angestoßen und Composer holt sich und packt die entsprechenden Ordner/Dateien in ein vendor-Verzeichnis. Dazu lassen sich neben den Abhängigkeiten auch Skripte definieren, die z.B. vor/nach Ausführung von install/update ausgeführt werden (scripts) oder Repository-Quellen hinzugefügt werden (repositories) oder...

    Das sieht dann z.B. für den Contao Composer-Client (Installer) (Contao Community Alliance) so aus:

    Code:
    {
        "name": "contao/core",
        "description": "Contao Open Source CMS",
        "license": "LGPL-3.0+",
        "version": "3.1.4",
        "type": "metapackage",
        "require": {
            "contao-community-alliance/composer": "dev-master@dev"
        },
        "scripts": {
            "pre-update-cmd": "ContaoCommunityAlliance\\ComposerInstaller\\ModuleInstaller::preUpdate",
            "post-update-cmd": "ContaoCommunityAlliance\\ComposerInstaller\\ModuleInstaller::postUpdate",
            "post-autoload-dump": "ContaoCommunityAlliance\\ComposerInstaller\\ModuleInstaller::postAutoloadDump"
        },
        "config": {
            "preferred-install": "dist",
        	"cache-dir": "cache"
        },
        "repositories": [
            {
                "type": "composer",
                "url": "http://legacy-packages-via.contao-community-alliance.org/"
            },
            {
                "type": "artifact",
                "url": "packages/"
            }
        ]
    }
    Soweit so gut. Ein auf den Composer aufbauender Ersatz für das ER funktioniert also vom Prinzip so: Ich will eine neue Extension, also füg ich sie zu meiner composer.json im require-Block hinzu und führe ein update aus. (Oder das ganze weniger manuell: Die Sache wird von einem Client im Contao-Backend wie der oben bereits genannte 'Composer Client' für mich erledigt. Quasi dasselbe, nur mit UI.)

    Ok. Jetzt müssen noch die Klassen dem Autoloader publik gemacht werden, sonst dümpeln sie nur irgendwo im Projektverzeichnis rum. Dazu wird praktischerweise bei einem install/update eine autoload.php im vendor-Verzeichnis erstellt/geupdated. Und die muss dann irgendwo an zentraler Stelle ins Projekt, also in Contao, eingebunden werden.

    Meine naive Vorstellung einer Lösung sieht z.B. so aus: Es gibt entweder ein Modul unter system/modules, indem die autoload.php vom Composer-Verzeichnis eingebunden wird. Oder die Sache passiert irgendwo in einer Config-Datei. Falls der Composer irgendwann mal zum Core gehört, passiert das ganze dann vielleicht sonstwo.

    Frage 1: Unter der gewagten Annahme, dass ich das bis hier richtig verstanden habe, frage ich mich wie das beim genannten Client gedacht ist. Da wird laut Anleitung mittels symbolischem Link das composer/.../modules/!composer-Verzeichnis ins Contao-Modulverzeichnis eingebunden. But why? Soll dann Contao selbst die autoload.php finden? Oder wo passiert die Einbindung? (Mal davon abgesehen, dass ich auf einem Shared-Hosting-Angebot keine Symlinks erstellen kann und es unter Windows auch so manche Stolperstelle gibt...)

    Frage 2: Was mache ich falsch? Wenn ich z.B. "bit3/contao-theme-plus": "4.2" hinzufüge, kann das Update wegen bit3/contao-theme-plus 4.2 requires ikimea/browser dev-master -> no matching package found nicht durchgeführt werden. Ich kann "ikimea/browser": "dev-master" aber problemlos händisch hinzufügen und installieren. Anderes Problem: Es wird bei der Installation/Download eine Composer\Downloader\TransportException geworfen. Ok, grade nachgeprüft, die URL zeigt ins Leere. Dann funktionieren viele Packages einfach nicht bzw. sind veraltet?

    Wer kann etwas Licht ins Dunkel bringen? Ich würde mich ja schon freuen mal ein funktionierendes System/einen funktionierenden Client im Contao-Backend zum Laufen zu bringen (Randbedingung: Unter Windows und später ein lauffähiges Contao-System auf einem 0815-Shared-Hoster.). Bisher ists für mich ein ganz schöner Dschungel. Oder gibt es gar irgendwo eine versteckte Doku?

    Viele Grüße
    Moritz

  2. #2
    Contao-Urgestein Avatar von tril
    Registriert seit
    07.01.2010.
    Ort
    Bad Marienberg
    Beiträge
    2.939
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von mvo Beitrag anzeigen
    Soweit so gut. Ein auf den Composer aufbauender Ersatz für das ER funktioniert also vom Prinzip so: Ich will eine neue Extension, also füg ich sie zu meiner composer.json im require-Block hinzu und führe ein update aus. (Oder das ganze weniger manuell: Die Sache wird von einem Client im Contao-Backend wie der oben bereits genannte 'Composer Client' für mich erledigt. Quasi dasselbe, nur mit UI.)
    Jap, das ist richtig, allerdings ist vorgesehen, dass du die composer.json nach TL_ROOT/composer/composer.json packst. Da Contao nicht für Composer ausgelegt ist, haben wir uns dazu entschlossen, das ganze in ein eigenes Verzeichnis zu separieren.

    Zitat Zitat von mvo Beitrag anzeigen
    Ok. Jetzt müssen noch die Klassen dem Autoloader publik gemacht werden, sonst dümpeln sie nur irgendwo im Projektverzeichnis rum. Dazu wird praktischerweise bei einem install/update eine autoload.php im vendor-Verzeichnis erstellt/geupdated. Und die muss dann irgendwo an zentraler Stelle ins Projekt, also in Contao, eingebunden werden.

    Meine naive Vorstellung einer Lösung sieht z.B. so aus: Es gibt entweder ein Modul unter system/modules, indem die autoload.php vom Composer-Verzeichnis eingebunden wird. Oder die Sache passiert irgendwo in einer Config-Datei. Falls der Composer irgendwann mal zum Core gehört, passiert das ganze dann vielleicht sonstwo.
    Wenn du unseren Client verwendest, musst du nichts dergleichen machen, darum kümmert sich unser Client bereits :-)

    Zitat Zitat von mvo Beitrag anzeigen
    Frage 1: Unter der gewagten Annahme, dass ich das bis hier richtig verstanden habe, frage ich mich wie das beim genannten Client gedacht ist. Da wird laut Anleitung mittels symbolischem Link das composer/.../modules/!composer-Verzeichnis ins Contao-Modulverzeichnis eingebunden. But why? Soll dann Contao selbst die autoload.php finden? Oder wo passiert die Einbindung? (Mal davon abgesehen, dass ich auf einem Shared-Hosting-Angebot keine Symlinks erstellen kann und es unter Windows auch so manche Stolperstelle gibt...)
    1. symlinks sind auf shared hosts normalerweise kein Problem, da diese normalerweise mittels PHP erstellt werden können. Aber symlinks sind kein Zwang, wenn man als Quelle Dist-Archive (Installation über ZIP Archive) anstelle von Source (git und Co.) verwendet, werden Kopien anstelle von Symlinks erstellt.

    2. Der Client kümmert sich, wie bereits gesagt um das laden der autoload.php von Composer. Dafür muss er aber logischerweise von Contao geladen werden, deshalb gibt es das Modul in system/modules/!composer (und natürlich für den GUI Client).

    3. Windows unterstützt Symlinks seit Windows Vista / Server 2008 (siehe http://us1.php.net/symlink#refsect1-...link-changelog)

    Zitat Zitat von mvo Beitrag anzeigen
    Frage 2: Was mache ich falsch? Wenn ich z.B. "bit3/contao-theme-plus": "4.2" hinzufüge, kann das Update wegen bit3/contao-theme-plus 4.2 requires ikimea/browser dev-master -> no matching package found nicht durchgeführt werden. Ich kann "ikimea/browser": "dev-master" aber problemlos händisch hinzufügen und installieren.
    Das Problem ist die minimale Stabilität, die Composer akzeptiert. ikimea/browser liegt leider nur als Entwicklungsbranch (dev-master) vor. Wenn du es von Hand installierst, überschreibst du quasi die erlaubte Stabilität und setzt diese auf develop für dieses eine Paket. Wenn es aber als Abhängigkeit installiert wird, gilt das nicht und Composer meckert das es das Packet nicht in einer ausreichend stabilen Version findet.
    Wir haben uns dazu entschlossen, das Problem so zu lösen das wir minimum-stability:dev mit prefer-stable:true kombinieren. Damit wählt Composer automatisch stabilere Versionen aus, vorausgesetzt das eine existiert, erlaubt aber auch instabile Pakete.
    siehe https://github.com/contao-community-...poser.json#L10

    Zitat Zitat von mvo Beitrag anzeigen
    Anderes Problem: Es wird bei der Installation/Download eine Composer\Downloader\TransportException geworfen. Ok, grade nachgeprüft, die URL zeigt ins Leere. Dann funktionieren viele Packages einfach nicht bzw. sind veraltet?
    Um welches Paket / welche URL geht es speziell?

    Zitat Zitat von mvo Beitrag anzeigen
    Wer kann etwas Licht ins Dunkel bringen? Ich würde mich ja schon freuen mal ein funktionierendes System/einen funktionierenden Client im Contao-Backend zum Laufen zu bringen (Randbedingung: Unter Windows und später ein lauffähiges Contao-System auf einem 0815-Shared-Hoster.). Bisher ists für mich ein ganz schöner Dschungel.
    Ich empfehle dir, einfach unser Dist Archiv zu verwenden.
    https://github.com/contao-community-...#nightly-build
    Für deinen Fall das "production" Archiv, dieses verwendet dann auch keine Symlinks.
    Runterladen und einfach in eine vorhandene Contao Installation entpacken (direkt in den Root, NICHT IN system/modules !!!)
    Das mache ich auch nicht anders, anschließend hast du ein Contao mit lauffähigem Composer Client

    Zitat Zitat von mvo Beitrag anzeigen
    Oder gibt es gar irgendwo eine versteckte Doku?
    Bisher nur hier und da vereinzelt, wir arbeiten an einer Dokumentation.
    Im Wiki findest du vielleicht noch zusätzlich ein paar wenige Antworten.
    https://github.com/contao-community-.../composer/wiki

    MfG Tristan

  3. #3
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    Wow, das ging schnell!

    Vielen Dank soweit!! Ich habe deinen Beitrag bereits einmal überflogen und werde mich morgen mal im Detail daran machen. Die meisten Sachen habe ich in der Tat schon so gemacht. Das sieht mir jetzt nach einem guten Ausgangspunkt aus, den Rest noch zu knacken. Ich werde berichten.

  4. #4
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    Ich konnte es jetzt doch nicht lassen und habe das Dist-Archiv mal testweise über eine frische Contao-Installation drüber gezogen. Sieht erstmal gut aus!

    Mal testweise "mrclay/minify" ausprobiert - funktioniert. Dann "bit3/contao-meta-palettes" (">=1.5.2.0,<1.6"):

    Code:
    Loading composer repositories with package information
    Updating dependencies (including require-dev)
      - Installing bit3/contao-meta-palettes (1.5.2)
        Cloning 8cb6ce1b073733e45d0567c47c6f9357fe066704
    
      [ErrorException]
      symlink(): Could not fetch file information(error 3)
    Das ganze passiert hier: composer/composer.phar/src/Composer/Plugin/PluginManager.php(210) : eval()'d code on line 839

    @tril Ich bin der Sache noch nicht weiter nachgegangen, das dann wirklich morgen. Aber vielleicht hast du ja eine schnelle Idee, was da dahintersteckt?


    Viele Grüße
    Moritz

  5. #5
    Contao-Urgestein Avatar von tril
    Registriert seit
    07.01.2010.
    Ort
    Bad Marienberg
    Beiträge
    2.939
    User beschenken
    Wunschliste

    Standard

    hast du das production oder development dist-archiv genommen?
    Der Versucht meta-palettes zu klonen (verwendet also git).

  6. #6
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    Ha! Das ist mir garnicht aufgefallen. Umgestellt auf Archiv als Installationsform und schon gehts.
    Es war übrigens das production-dist-Archiv.

    Dann ist also git schuld? Hmm, mit git clone auf der Konsole krieg ich problemlos Packages gezogen.

    Vielen Dank für den Anstoß.

    Viele Grüße
    Moritz


    PS: Nachtrag: Wähl ich z.B. "kriswallsmith/assetic" und erlaub Quelle als Installationsform, dann clont er brav und die Installation läuft durch.
    Geändert von mvo (03.11.2013 um 16:46 Uhr)

  7. #7
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    Hallo,

    ich melde mich mit einem Zwischenergebnis, falls jemand auf ähnliches stößt:

    Einige der Probleme, die ich hatte, waren durch ein zu kleines Execution-Limit für PHP-Skripte (30s) aufgetreten. Das ist in der Tat ein Problem, wenn man mehrere Packages vormerkt und dann den Composer anwirft. Mit der Konsole geht das allerdings problemlos.

    (Aus diesem Grund war ich auch skeptisch ob die Migration der ER-Module bei mir funktioniert, weil es haufenweise PHP-Fehler regnete )

    Ok. Ich beginne die Extension und den Manager mehr und mehr zu mögen. Coole Sache, wirklich.

    Viele Grüße
    Moritz

    (PS: OT: Gibt es zufällig irgendwo schon einen (contao-)assetic Filter für minify statt diesem verbuggten cssmin?)

  8. #8
    Contao-Urgestein
    Registriert seit
    07.07.2009.
    Beiträge
    4.107

    Standard

    Zitat Zitat von mvo Beitrag anzeigen
    (PS: OT: Gibt es zufällig irgendwo schon einen (contao-)assetic Filter für minify statt diesem verbuggten cssmin?)
    Wir setzen nur noch mrclay/minify ein und haben damals für Theme+ eine Unterstützung eingebaut.

  9. #9
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    (Ich habe jetzt einmal den Minifier von csscrush im Einsatz (ein Schalter: 'minifiy' => true und die Sache läuft) - tut seinen Einsatz bisher auch ganz gut.)

    @tril: Bei meinem Webhoster ist php 5.3.3 installiert, weswegen sich der Composer Client weigert den Package Manager zu laden (zu Recht ). Er könnte aber vielleicht trotzdem die autoload.php einbinden, damit zumindest die Module laufen?

    Bei mir werkelt deshalb doch die manuelle Einbindung.
    PHP-Code:
    // initconfig.php
    require_once(TL_ROOT'/composer/vendor/autoload.php'); 
    Wieso tauchen denn eigentlich die legacy-Module doppelt auf (einmal im composer-Verzeichnis, einmal unter system/modules)? Liegt das daran, dass diese Module außerhalb des Standard-Pfads potentiell nicht funktionieren (Referenzen...) oder was ist der Gedanke dahinter?

    Danke für euren Input!

    Viele Grüße
    Moritz

  10. #10
    Contao-Urgestein
    Registriert seit
    07.07.2009.
    Beiträge
    4.107

    Standard

    Und wie minimierst du JS?

  11. #11
    Contao-Urgestein Avatar von tril
    Registriert seit
    07.01.2010.
    Ort
    Bad Marienberg
    Beiträge
    2.939
    User beschenken
    Wunschliste

    Standard

    Zitat Zitat von mvo Beitrag anzeigen
    @tril: Bei meinem Webhoster ist php 5.3.3 installiert, weswegen sich der Composer Client weigert den Package Manager zu laden (zu Recht ). Er könnte aber vielleicht trotzdem die autoload.php einbinden, damit zumindest die Module laufen?
    Kurz: nein, weil einige Module ebenfalls 5.3.4 oder neuer voraussetzen, wenn du die Installation nicht auf dem Server durchführst, bekommst du dafür keine Prüfung. Ich mein, die 5.3er Serie ist bereits bei 5.3.27 angelangt! Es ist wohl kaum zu viel verlangt das der Hoster da m

    Zitat Zitat von mvo Beitrag anzeigen
    Bei mir werkelt deshalb doch die manuelle Einbindung.
    PHP-Code:
    // initconfig.php
    require_once(TL_ROOT'/composer/vendor/autoload.php'); 
    So lange du weißt was du tust ist mir das egal. Aber wir können das nicht zur Regel machen, weil das früher oder später kracht und der Otto-Normal-Verbraucher die Schuld dann auf den Comoser schiebt obwohl der nichts dafür kann.

    Zitat Zitat von mvo Beitrag anzeigen
    Wieso tauchen denn eigentlich die legacy-Module doppelt auf (einmal im composer-Verzeichnis, einmal unter system/modules)? Liegt das daran, dass diese Module außerhalb des Standard-Pfads potentiell nicht funktionieren (Referenzen...) oder was ist der Gedanke dahinter?
    Du hast es schon richtig erkannt, composer nutzt das vendor/ Verzeichnis, Contao hingegen system/modules/, deshalb kopiert (oder symlinked) unser Installer bestimmte Dateien von vendor/X/Y/... nach system/modules/Z/... (das kann pro Paket festgelegt werden), damit Contao überhaupt in der Lage ist das Modul zu laden.

    MfG Tristan

  12. #12
    Contao-Nutzer
    Registriert seit
    23.08.2013.
    Beiträge
    87

    Standard

    Zitat Zitat von andreasisaak Beitrag anzeigen
    Und wie minimierst du JS?
    Closure Compiler


    Zitat Zitat von tril Beitrag anzeigen
    Kurz: nein, weil einige Module ebenfalls 5.3.4 oder neuer voraussetzen, wenn du die Installation nicht auf dem Server durchführst, bekommst du dafür keine Prüfung. Ich mein, die 5.3er Serie ist bereits bei 5.3.27 angelangt! Es ist wohl kaum zu viel verlangt das der Hoster da m
    Da geb ich dir vollkomen recht. Und das der Webhoster auf Dauer keine gute Wahl war hab ich auch schon an anderen Stellen gemerkt (keine Kompression - argh). Das mit den Modulen macht aus der Betrachtung natürlich auch Sinn. Aber jetzt stehts zumindest mal hier im Forum, falls jemand ähnlich wie ich plötzlich auf den Composer und Client abfährt und ihn irgendwie auf eigene Gefahr auf einem Schrotthoster zum Laufen bringen will .

    Was die Speicherorte angeht: Das leuchtet mir schon ein. Ich habe mir dabei nur die Frage gestellt, ob (im nicht gesymlinkten Fall) es nicht reichen würde nur Rümpfe in den Modulordnern zu haben, die dann entsprechend verweisen. Das war letztlich natürlich ein Denkfehler, weil die dcas etc. ja eh dort liegen müssen. Das gibt der symlink-Variante nochmal einen Vorzug. Danke für den Hinweis!

    Viele Grüße
    Moritz

    PS: Und ich muss es nochmal aussprechen: Composer rockt. An alle die das (noch) nicht haben: Ihr wollt das, wirklich.

  13. #13
    Contao-Urgestein
    Registriert seit
    07.07.2009.
    Beiträge
    4.107

    Standard

    Zitat Zitat von mvo Beitrag anzeigen
    PS: Und ich muss es nochmal aussprechen: Composer rockt. An alle die das (noch) nicht haben: Ihr wollt das, wirklich.
    Genau meine Rede. Ich will nicht mehr zum alten Extension Repository zurück.

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •