Paketverwaltung Problem open_basedir, composer

[k-webdesign]

@k-webdesign versuche mal die /composer/composer.phar auf Version 1.0.2 zu aktualisieren: https://getcomposer.org/download/1.0.2/composer.phar

sry fürs tote Frau spielen - der war aktuell. Indem ich dann einfach wieder deinen Workaround genutzt habe, ging alles wieder. Hoffe, bald kommt das 0.16.4 release, eben musste ich in einem Theme auch den Composer rein machen und es knallt immer noch dadurch.

[Spooky]

0.16.4 wurde vor 2 Tagen auf GitHub veröffentlicht

[BugBuster]

Die 0.16.4 ist draussen.

[k-webdesign]

Über das ER wird noch die 0.16.3 gezogen. Durch den Workaround kam ich jetzt zwar wieder an die Migration, doch die schlägt vollkommen fehl und jetzt ist das Backend hinüber *argh* Egal, andere Baustelle...

[Spooky]

Du brauchst das ER2 ja nicht unbedingt, du kannst dir ja den 0.16.4 release auch von GitHub runterladen und den !composer Ordner nach /system/modules kopieren und dann im Backend die Paketverwaltung für die Migration aufrufen (denke ich).

[k-webdesign]

Das war mir jetzt zu umständlich, weil ich dachte "kommentier einfach die Zeilen aus und lad die neue phar hoch, dann passt alles". Doch jetzt hat mir die Migration alle Extensions aus /system/modules gehauen, immerhin hab ich ein Backup.

[Spooky]

Das war mir jetzt zu umständlich, weil ich dachte "kommentier einfach die Zeilen aus und lad die neue phar hoch, dann passt alles". Doch jetzt hat mir die Migration alle Extensions aus /system/modules gehauen, immerhin hab ich ein Backup.

Das heißt das war eine bestehende Installation ohne composer?

[k-webdesign]

Es ist das Oneo Theme von Rocksolid, das hat per default das ER drin. Dann wollte ich Composer über das ER installieren, dabei hat es mir dann die 0.16.3 des Composer Clients angeboten.

[clavis]

Ich fürchte ich bin gerade in dieselbe Falle getappt.
Bei einer halbfertigen 3.5.8 dahintergekommen, dass ich Bootstrap brauche (gibt es ja leider nur per Composer). Über die ER2 vor 20 Minuten composer 0.16.3 installiert. Fehlermeldung. ClientBackend.php geändert wie erklärt. Andere phar eingespielt wie erklärt. Dann ging es zumindest wieder wieder.

Und jetzt - nach der Migration - werden zwar sämtliche bislang installierten Extensions im Composer angezeigt, aber aus dem BE sind sie verschwunden. Ein Update auf 0.16.4 ist leider auch nicht möglich, da er auch bei einem Testlauf präventiv ein DB-Update machen will, und das beinhaltet leider die Löschung sämtlicher Tabellen der alten Extensions (ein fertig konfigurierter Isotope!). Ohne diese Tables zu löschen lässt er mich aber auch nicht weitermachen.

frustloswerd
Mein Problem mit dem Composer sind nicht seine häufigen Fehler, Unübersichtlichkeit und Speicheranforderungen - für eine Beta ist das ganz natürlich. Mein Problem ist, dass dieses Teil für Entwickler _so_ praktisch ist, dass viele Extensions jetzt schon nur noch für den Composer erscheinen, und ich damit auch mit Produktivsystemen in den Betatest gezwungen werde.
/frustloswerd

[Spooky]

Ein Update auf 0.16.4 ist leider auch nicht möglich, da er auch bei einem Testlauf präventiv ein DB-Update machen will, und das beinhaltet leider die Löschung sämtlicher Tabellen der alten Extensions (ein fertig konfigurierter Isotope!). Ohne diese Tables zu löschen lässt er mich aber auch nicht weitermachen.

Das stimmt nicht. Du musst die tables nur löschen, wenn du es willst. Wenn die Tables nach jedem Update gelöscht werden wollen, dann sind die Extensions einfach nicht installiert worden. Entferne mal alle requirements aus der composer.json (außer natürlich "contao-community-alliance/composer-client": ">=…"), mache ein Update, und füge sie dann wieder hinzu und mache wieder ein Update.

Du musst nie irgendwelche Fields oder Tabellen löschen, unabhängig vom composer.

[clavis]

Ok - jetzt hat es geklappt. Problem war der Testlauf, der immer wieder die isotope Tables löschen wollte. Ein tatsächliches aktualisieren der Pakete hat mir die Extensions wieder aktiviert. Allerdings waren dazu zwei Durchläufe nötig. Keine Ahnung weshalb...

lg
clavis

PS@spooky: Nein natürlich zwingt mich der Composer nicht zum löschen der Tables, das war schlecht ausgedrückt. Es war bei einem Testlauf nur die einzige Option die mir angeboten wurde.

[Spooky]

Ok - jetzt hat es geklappt. Problem war der Testlauf, der immer wieder die isotope Tables löschen wollte.

Du verwechselst hier etwas. Der Testlauf will dir keine Tables löschen. Das Datenbank Update von Contao bietet dir das an. Und das macht Contao deshalb, weil die Extensions, die diese Tabellen benutzen, in /system/modules nicht vorhanden sind (oder deaktiviert sind). Der Testlauf bzw. das reguläre Paket Update und das Datenbank Update haben prinzipiell nichts miteinander zu tun.

Ein tatsächliches aktualisieren der Pakete hat mir die Extensions wieder aktiviert.

Ist ja auch logisch, der Testlauf ist ja nur ein Testlauf, der installiert dir keine Erweiterungen.

Allerdings waren dazu zwei Durchläufe nötig. Keine Ahnung weshalb...

Das ist normal.

[rflx]

Hallo Spooky,

betreffend Composer Warnung:

Warning: System certificate bundle not readable, will try to use embedded certificate list.

Ja, das kannst du ignorieren.

Woher kommt die Warnung und was ist genau damit gemeint?

Cheers,
rflx

[Spooky]

Um Verbindungen über SSL aufbauen zu können, brauchst du ein lokales Zertifikat. Diese Zertifikate sind unter Linux bspw. in einem bestimmten Ordner hinterlegt. Wenn die Konfiguration des Webservers es untersagt, dass PHP Applikationen darauf zugreifen können, muss ein Fallback benutzt werden. In diesem Fall wird das lokale Zertifikat welches im Composer integriert ist benutzt. Diese Warnung weist dich darauf hin.