Composer deinstallieren?

**brain1965** · 04.03.2014, 12:56

Liebe Community,

da ich einige Probleme bei der Umstellung auf Composer hatte möchte ich diesen deinstallieren. Leider genügt das Löschen des !composer Verzeichnisses aus den modules nicht. Die Seite zeigt nur noch Error-Meldungen.

Ich habe bereits ein Backup der Datenbank vor Composer-Installation eingespielt, dennoch sind sowohl Frontend wie Backend sind nicht mehr erreichbar.

Wie werde ich Composer los?

Danke für Tipps!

**Spooky** · 04.03.2014, 13:21

Es gibt den Punkt "Switch back to old client" in den Einstellungen der Paketverwaltung. Dies sollte wohl den Composer bzw. die Paketverwaltung sauber deinstallieren (habe es aber selbst noch nie getestet).

**brain1965** · 04.03.2014, 13:24

Hallo Spooky,

Danke für deine Antwort - da ich aber ein gecrashtes Backend habe, steht mir diese Funktion nicht zur Verfügung...

**Spooky** · 04.03.2014, 13:32

Naja, du solltest nicht nur das Datenbank-Backup zurückspielen, sondern auch das Datei-Backup, denke ich, da du ja die Composer Erweiterung einfach so gelöscht hast. Hast auch schon schon versucht die Composer Erweiterung einfach wieder neu hinzu zu fügen?

**brain1965** · 04.03.2014, 13:56

Ich habe jetzt sowohl DB wie FTP Daten zurückgespielt auf den alten Stand und damit geht natürlich alles wieder. Das Problem war, das Composer bereits bei der Migration gecrasht ist und damit keine Aktivierung des alten Zustandes mehr möglich war.

Ich hoffe, dass Composer in der finalen Version ähnlich einfach und anschaulich zu nutzen sein wird wie das Repository derzeit. Der Riesenvorteil bei Contao ist ja gerade, dass es so wunderbar einfach funktioniert und man sich nicht in 1000 Optionen verirren kann wie bei anderen CMS.

Eines ist mir noch aufgefallen: Ich musste meine PHP.ini umstellen auf "allow_url_fopen" um Composer nutzen zu können, was aber eine Sicherheitslücke darstellt. Ich hoffe, das ändert sich noch, bevor die Erweiterung das Repository ersetzt.

**Flex** · 04.03.2014, 14:27

allow_url_fopen ist keine Sicherheitslücke sondern eine reguläre Konfigurationsoption, die viele Hoster aus Bequemlichkeit deaktivieren...

Wie viele andere Funktionen auch, kann es natürlich als Einfallstor fungieren, wenn es nicht richtig verwendet wird.

**andreasisaak** · 04.03.2014, 14:42

Zitat von brain1965

Hallo Spooky,

Danke für deine Antwort - da ich aber ein gecrashtes Backend habe, steht mir diese Funktion nicht zur Verfügung...

Du hättest das Backup nicht mal einspielen müssen. Es hätte gereicht in dem Ordner rep_base und rep_client unter system/modules die .skip Datei zu löschen.

**brain1965** · 04.03.2014, 16:49

Zitat von Flex

allow_url_fopen ist keine Sicherheitslücke

Nicht per se, aber ein Angriff kann leichter werden – je nach technischer Umgebung, die eben unterschiedlich aussehen kann.

Es wäre doch besser, wenn dieses potenzielle Hintertürchen gar nicht erst aufgemacht wird - so wie es beim Repository auch war.

**brain1965** · 04.03.2014, 16:50

Zitat von andreasisaak

Du hättest das Backup nicht mal einspielen müssen. Es hätte gereicht in dem Ordner rep_base und rep_client unter system/modules die .skip Datei zu löschen.

Danke Andreas. Wenn man weiss wie's geht ist es einfach - wenn nicht dann nicht

**xtra** · 04.03.2014, 17:23

Zitat von brain1965

Nicht per se, aber ein Angriff kann leichter werden – je nach technischer Umgebung, die eben unterschiedlich aussehen kann.

Es wäre doch besser, wenn dieses potenzielle Hintertürchen gar nicht erst aufgemacht wird - so wie es beim Repository auch war.

Auf einem "sauber konfigurierten Webhoster" stellt dies keinerlei Problem dar, da diese i.d.R. in der Konfiguration auch "allow_url_include" (seit PHP 5.2.0 verfygbar) sauber eingestellt haben.
Somit ist die "Hintertyr" rein akademischer Natur, da eine direkte Code injection verboten ist.
Wenn wir das dennoch noch als Hintertyr sehen wollen, dann ist das ER2 genauso unsicher, da dort auch "ausgehende Verbindungen" vorgenommen werden (SOAP) und somit dasselbe Problem besteht.

Abgesehen davon, dass dies per se keine Sicherheitslycke bzw. Hintertyr ist, ist diese Notwendigkeit ausserhalb unseres Einflussbereiches, da dies im Composer Hauptprojekt (https://github.com/composer/composer) so definiert ist, dass die Daten per fopen() ybertragen werden. Es gibt jedoch auch schon einen PR welcher curl einbinden wird, das mergen desselbigen jedoch wird vermutlich noch ne Weile dauern (https://github.com/composer/composer/pull/2696).

My 2 cents.
Chris

**tab** · 04.03.2014, 17:32

Zitat von brain1965

Nicht per se, aber ein Angriff kann leichter werden – je nach technischer Umgebung, die eben unterschiedlich aussehen kann.

Es wäre doch besser, wenn dieses potenzielle Hintertürchen gar nicht erst aufgemacht wird - so wie es beim Repository auch war.

Das Hintertürchen entsteht erst durch schlechte Programmierung (der Website, des CMS, ...), nicht durch die Möglichkeit an sich. Man kann es auch so nutzen, dass keine Hintertürchen dabei entstehen. Ist in etwa so, wie mit der deserialize Funktion bei der Sicherheitslücke neulich.
Dein Argument könnte man so auf die Spitze treiben, dass man sagt: "Am sichersten ist es, wenn gar keine Dateien auf den Webspace geschrieben werden dürfen, also weg mit den Schreibrechten auf dem Webspace!"

(Webseiten? Bäh! Das braucht doch keiner!)
Im speziellen Fall hier ist es doch wohl so, dass die wirklich gefährliche Nutzung (require, include), durch die in PHP 5.2 neue Direktive "allow_url_include" ausgeschlossen werden kann, während die ungefährliche Nutzung wie file_get_contents oder fopen weiterhin möglich bleibt.
Also:
allow_url_fopen On
allow_url_include Off
Und schon sind alle glücklich und zufrieden, man muss das Kind nicht mehr mit dem Bad ausschütten.

**taktell81** · 25.03.2014, 19:27

Zitat von andreasisaak

Du hättest das Backup nicht mal einspielen müssen. Es hätte gereicht in dem Ordner rep_base und rep_client unter system/modules die .skip Datei zu löschen.

Mir ist im Zuge der Migration der Zugriff aufs Back -/Frontend entschwunden. Seitenweise Warning: include(): Failed opening. Nun wollt ich Andreas o.g. Tip folgen, um eine Neuinstallation zu umgehen. In meiner Contao 3.1.1 Installation finden sich jedoch keine rep_base und rep_client Verzeichnisse unter Modules sondern lediglich ein reposity ordner dessen .skip Datei zu löschen keine Besserung beschert.

Was tun ?

**andreasisaak** · 25.03.2014, 19:37

rep_base und rep_client sind noch die alten Module, seit neuestem wurde das in repository zusammengefasst. Das stimmt also soweit.

Kannst du die genauen Fehler hier veröffentlichen?

**taktell81** · 25.03.2014, 19:42

Jo, scheinen inkompatible Erweiterungen zu sein. Fehlermeldungen sind auch nur auf den Front End Seiten zu finden, die entsprechende Erweiterungen nutzen. gibts einen Lösungsansatz ?

errors.txt

**KlausGrenoble** · 25.03.2014, 19:53

Fatal error: Class 'MultiColumnWizardHelper' not found in /kunden/408201_24114/webseiten/system/modules/core/library/Contao/System.php on line 110

Gibt's bei Dir die MultiColumnWizardHelper.php in \system\modules\multicolumnwizard\ ?

**taktell81** · 25.03.2014, 19:55

nope

**KlausGrenoble** · 25.03.2014, 19:58

Dann würde ich den multicolumnwizard nochmal richtig installieren.

**taktell81** · 25.03.2014, 20:01

da der backend Zugriff auf das ER nicht funktioniert - meinst du einfach die entprechenden Ordner Multicolumnwizard per ftp upzuloaden ?
es fehlen ja dennoch Tabcontrol / googlemaps laut Fehlermeldung. Ich hatte auf eine einfachere Möglichkeit gehofft auf die ursprüngliche ER zu switchen

**KlausGrenoble** · 25.03.2014, 20:07

Ja, einfach alle Dateien mit dem github-Multicolumnwizard überschreiben.
https://github.com/menatwork/MultiColumnWizard
So würde ich das machen. Ausserdem hab' ich gerade nachgeschaut: dort existiert die fehlende Datei MultiColumnWizardHelper.php.
Und dann install.php aufrufen.

**taktell81** · 25.03.2014, 20:20

ok, ich habe alle fehlenden Extension folders vom Filebackup per ftp wieder hergestellt. Lüppt ! dank dir für die Hilfe

**Flaschenzug** · 16.12.2014, 12:08

Hatte folgendes Problem bei All-Inkl: Safe Mode hack nicht aktiviert. FTP Daten waren aber eingefügt. Dennoch ging es nicht.
Habe dann versucht über die Besitzrechte vorzugehen, auch das hat nichts gebracht. Die Lösung war dann folgendes (etwas abgewandelt von der Beschreibung von andreasisaak)

Du hättest das Backup nicht mal einspielen müssen. Es hätte gereicht in dem Ordner rep_base und rep_client unter system/modules die .skip Datei zu löschen.

Erst die Datei .skip im Ordner /system/modules/repository entfernen, dann die Erweiterung "!composer" unter System -> Einstellungen deaktivieren.
Anschließend wurde mir das alte Repository wieder angezeigt, dort dann den Composer deinstalliert.

(Das ganze lief so auf einer Contao 3.2er Version)

**marebe** · 23.04.2015, 21:15

Zitat von Flaschenzug

Erst die Datei .skip im Ordner /system/modules/repository entfernen, dann die Erweiterung "!composer" unter System -> Einstellungen deaktivieren.
Anschließend wurde mir das alte Repository wieder angezeigt, dort dann den Composer deinstalliert.

Hat bei mir gerade auch unter 3.4.5 zum Glück funktioniert.
Wollte auf einem HostEurope Webpack testen, aber die Composer-Installation hat sich aufgehängt, obwohl ich phar bei der php_suhosin_executor_include_whitelist hinzugefügt hatte.
Da kam keine Fehlermeldung mehr, nur endloses Rödeln.

**cliffparnitzky** · 23.04.2015, 22:24

Anmerkung nebenbei - wenn ihr bestimmte Hostingpaket für Composeruntauglich testet, tragt es bitte hier nach: http://de.contaowiki.org/Composer/Hosting

**xtra** · 24.04.2015, 12:12

Zitat von marebe

Hat bei mir gerade auch unter 3.4.5 zum Glück funktioniert.
Wollte auf einem HostEurope Webpack testen, aber die Composer-Installation hat sich aufgehängt, obwohl ich phar bei der php_suhosin_executor_include_whitelist hinzugefügt hatte.
Da kam keine Fehlermeldung mehr, nur endloses Rödeln.

Definiere "aufgehaengt". Welche Fehlermeldung hattest du auf dem Schirm oder im log?
Es ist ganz normal dass der composer lange braucht um Abhaengigkeiten aufzuloesen, da er es im Gegensatz zum ER2 auch wirklich macht.

Das dauert einfach da er sich alle Paketinfos ziehen muss und anschliessend aufloest welche Kombination der gewynschten Pakete bei dir passend ist.

**marebe** · 24.04.2015, 12:45

Zitat von xtra

Definiere "aufgehaengt". Welche Fehlermeldung hattest du auf dem Schirm oder im log?
Es ist ganz normal dass der composer lange braucht um Abhaengigkeiten aufzuloesen, da er es im Gegensatz zum ER2 auch wirklich macht.

Das dauert einfach da er sich alle Paketinfos ziehen muss und anschliessend aufloest welche Kombination der gewynschten Pakete bei dir passend ist.

Hallo xtra,

anbei meine Veranschaulichungsbemühungen:

Screenshot:
kapott.jpg

system/logs/error.log

Code:

[24-Apr-2015 13:33:45 Europe/Berlin] PHP Fatal error:  Uncaught exception 'Exception' with message 'Query error: MySQL server has gone away (UPDATE tl_user SET session='a:20:{s:7:\"referer\";a:24:{s:8:\"939cb7a7\";a:2:{s:4:\"last\";s:0:\"\";s:7:\"current\";s:27:\"contao/main.php?do=composer\";}s:8:\"05bef68b\";a:2:{s:4:\"last\";s:0:\"\";s:7:\"current\";s:15:\"contao/main.php\";}s:8:\"67ad1eaf\";a:2:{s:4:\"last\";s:15:\"contao/main.php\";s:7:\"current\";s:40:\"contao/main.php?do=settings&ref=05bef68b\";}s:8:\"6910193f\";a:2:{s:4:\"last\";s:15:\"contao/main.php\";s:7:\"current\";s:40:\"contao/main.php?do=settings&ref=05bef68b\";}s:8:\"f8be4b4a\";a:2:{s:4:\"last\";s:15:\"contao/main.php\";s:7:\"current\";s:40:\"contao/main.php?do=settings&ref=05bef68b\";}s:8:\"332bbe4e\";a:2:{s:4:\"last\";s:0:\"\";s:7:\"current\";s:15:\"contao/main.php\";}s:8:\"317aae89\";a:2:{s:4:\"last\";s:15:\"contao/main.php\";s:7:\"current\";s:50:\"contao/main.php?do=repository_manager&ref=332bbe4e\";}s:8:\"dcc51875\";a:2:{s:4:\"last\";s:0:\"\";s:7:\"current\";s:56:\"contao/main.php?do=reposito in /is/htdocs/wp12085990_IRPNEGHECP/www/contao-latest/system/modules/core/library/Contao/Database/Statement.php on line 293

**xtra** · 24.04.2015, 15:04

Yo, da hat sich dein MySQL Server verabschiedet, da kann aber Composer nix zu.
ich vermute mal dass dein MySQL Server idle Verbindungen zu schnell kappt und somit nach dem durchlauf von Composer resolving kein Query mehr abgesetzt werden kann.

Das ist aber wiedermal kein Problem von composer, da wir hierauf einfach keinen Zugriff haben.

Tut mir leid wenn ich hier nun ein wenig saeuerlich klinge, aber jeder der auf Composer schimpft dass es nie klappt hat zumeist den konkreten Fehler dann meist doch ganz wo anders.

Bei dir konkret ist der Fehlereintrag beispielsweise das Speichern der Benutzersitzung am Ende eines Seitenaufrufs im Contao backend. Da sollte ein redirect erfolgen, der kommt jedoch danach nicht mehr da ja schon der Fehler ausgegeben wurde.

**tab** · 24.04.2015, 15:29

Könnte man sowas nicht abfangen? Es scheint ja nicht außergewöhnlich zu sein, dass das Composer resolving schon mal ne Weile dauern kann. Wäre es also nicht machbar, danach erst mal zu testen, ob die Verbindung noch besteht - und falls nicht, eine neue Verbindung aufzubauen? Je mehr Erweiterungen da zusammenkommen und je komplexer die ganzen Abhängigkeiten werden, desto länger wird es dauern. Irgendwann wird auch ein "geduldigerer" Server vielleicht doch die Verbindung kappen. Da könnte es doch nützlich sein, wenn das dann nicht gleich zu Problemen führt.

**xtra** · 28.04.2015, 18:27

Das geht in Contao leider nicht, da die Session des Benutzer unter 2.11-3.1 im "__destruct" des Objekts vorgenommen wird und ab 3.2 (glaube ich) als shutdown function.

In letzterem Umfeld koennte man diese explizit unregistrieren was aber ggf. das referermanagement im Backend durcheinander bringen koennte.

Muss ich mal ausprobieren. Seltsam finde ich jedoch, dass du der Erste bist bei dem MySQL die Graetsche macht und nicht PHP in einen maximum execution timeout rennt, normalerweise ist es naemlich eher so rum.

**marebe** · 28.04.2015, 19:13

Zitat von tab

Je mehr Erweiterungen da zusammenkommen und je komplexer die ganzen Abhängigkeiten werden, desto länger wird es dauern.

ja, seh ich auch so. Wenns jetzt schon mehrere Minuten dauert und es ist ja nicht nur die Anzahl Extensions, sondern bei jedem Core-Release wirds ja auch komplexer...
Öffnet der jedes Paket und schaut sich die composer.json an oder was?
Da müsste es doch auch sowas wie ein caching geben, das zügig antwortet.
Ok, der macht mehr als das ER2, aber es gibt sicherlich noch viel komplexere Abfragen im Netz, die in einem Bruchteil der Zeit abgearbeitet werden. Ich denk da nur mal an Google

**tab** · 28.04.2015, 19:31

Naja, mit Google kann man das nicht mal ansatzweise vergleichen. Da steckt schon ein klein wenig

mehr Hardware dahinter. 2011 wurde die Gesamtzahl der dazugehörigen Server auf eine knappe Million geschätzt.

**xtra** · 28.04.2015, 19:41

@marebe: wenn du als Webserver einen Cluster hin stellst und obendrein PHP multithreading beibringst, dann wird das auch im Bruchteil einer Sekunde ablaufen.

Cachen kannst du da nicht wirklich was, denn die Versionsinformationen aendern sich ja jedesmal, das ist ein ziemlich komplexer Baum der da gebaut und durchgeackert wird. Das ist schon ziemlich krass optimiert, viel Luft ist da nicht drin.

**marebe** · 29.04.2015, 08:19

Zitat von xtra

Cachen kannst du da nicht wirklich was, denn die Versionsinformationen aendern sich ja jedesmal, das ist ein ziemlich komplexer Baum der da gebaut und durchgeackert wird. Das ist schon ziemlich krass optimiert, viel Luft ist da nicht drin.

und scheibchenweise per AJAX abarbeiten geht auch nicht? Muss der ganze Baum in einem Rutsch durch geackert werden?
Wenn mans aufteilen würde, dann könnte man dem Anwender ja eine "Fortschrittsanzeige" bieten und hätte immer die Kontrolle über Erfolg/Misserfolg/Retry und könnte entsprechend darauf reagieren.

**Thoni** · 09.02.2017, 13:39

Hallo,

ich habe mich mal an den Composer rangetraut und nun werden keine Mails verschickt.
Ich möchte probieren, den Composer zu deinstallieren, finde aber "Switch back to old client" nicht.
Geht das überhaupt noch?

Contao 3.5.18
Composer-Client 0.16.5

Danke
Thoni

**Spooky** · 09.02.2017, 13:46

Zitat von Thoni

ich habe mich mal an den Composer rangetraut und nun werden keine Mails verschickt.

Ich denke nicht, dass das irgendwas mit der Paketverwaltung zu tun hat. Generell solltest du erst mal rausfinden, warum keine Mails verschickt werden.

Zitat von Thoni

Ich möchte probieren, den Composer zu deinstallieren, finde aber "Switch back to old client" nicht.
Geht das überhaupt noch?

Ja, das wurde entfernt, siehe https://github.com/contao-community-...ent/issues/232

Eine genauere Anleitung wie man es manuell machen kann gibt es hier: https://github.com/contao-community-...ki/Switch-back

**iainmacnab** · 14.02.2017, 14:56

Das beste Lösung für alle scheint Composer zu deinstallieren. Ich hör nur negatives?

**Thraile** · 14.02.2017, 15:18

Also wir setzen den Composer schon seit einigen Jahre erfolgreich ein. Ein vernünftiges Hosting-Setup mal vorausgesetzt funktioniert Composer prima. Wenn man bedenkt, dass es sich hierbei um ein Tool für die Konsole handelt, klappt die Integration ins Backend erstaulich gut, auch wenn ich persönlich ein Update lieber direkt auf der Shell anwerfe.

Die meisten Probleme, die ich hier so im Forum gelesen habe, lassen sich auf ein eher suboptimales Hosting zurück führen. Ja, Composer hebt die Anforderungen und mit einem 2,99€ Paket aus der TV-Werbung wird das wohl nix, aber mit Paketen von unter 10€/Monat kommt man gut über die Runden.