Druckbare Version
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!
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).
Hallo Spooky,
Danke für deine Antwort - da ich aber ein gecrashtes Backend habe, steht mir diese Funktion nicht zur Verfügung...
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?
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.
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.
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.Zitat:
Zitat von brain1965
Nicht per se, aber ein Angriff kann leichter werden – je nach technischer Umgebung, die eben unterschiedlich aussehen kann.Zitat:
Zitat von Flex
Es wäre doch besser, wenn dieses potenzielle Hintertürchen gar nicht erst aufgemacht wird - so wie es beim Repository auch war.
Danke Andreas. Wenn man weiss wie's geht ist es einfach - wenn nicht dann nicht :)Zitat:
Zitat von andreasisaak
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.Zitat:
Zitat von brain1965
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
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.Zitat:
Zitat von brain1965
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. ;)
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.Zitat:
Zitat von andreasisaak
Was tun ?
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?
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 ?
Anhang 13321
Gibt's bei Dir die MultiColumnWizardHelper.php in \system\modules\multicolumnwizard\ ?Zitat:
Fatal error: Class 'MultiColumnWizardHelper' not found in /kunden/408201_24114/webseiten/system/modules/core/library/Contao/System.php on line 110
nope
Dann würde ich den multicolumnwizard nochmal richtig installieren.
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
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.
ok, ich habe alle fehlenden Extension folders vom Filebackup per ftp wieder hergestellt. Lüppt ! dank dir für die Hilfe
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)
Erst die Datei .skip im Ordner /system/modules/repository entfernen, dann die Erweiterung "!composer" unter System -> Einstellungen deaktivieren.Zitat:
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.
Anschließend wurde mir das alte Repository wieder angezeigt, dort dann den Composer deinstalliert.
(Das ganze lief so auf einer Contao 3.2er Version)
Hat bei mir gerade auch unter 3.4.5 zum Glück funktioniert.Zitat:
Zitat von Flaschenzug
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.
Anmerkung nebenbei - wenn ihr bestimmte Hostingpaket für Composeruntauglich testet, tragt es bitte hier nach: http://de.contaowiki.org/Composer/Hosting
Definiere "aufgehaengt". Welche Fehlermeldung hattest du auf dem Schirm oder im log?Zitat:
Zitat von marebe
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,Zitat:
Zitat von xtra
anbei meine Veranschaulichungsbemühungen:
Screenshot:
Anhang 15788
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
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.
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.
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. :D
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...Zitat:
Zitat von tab
Ö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 :)
Naja, mit Google kann man das nicht mal ansatzweise vergleichen. Da steckt schon ein klein wenig :D mehr Hardware dahinter. 2011 wurde die Gesamtzahl der dazugehörigen Server auf eine knappe Million geschätzt.
@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.
und scheibchenweise per AJAX abarbeiten geht auch nicht? Muss der ganze Baum in einem Rutsch durch geackert werden?Zitat:
Zitat von xtra
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.
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
Ich denke nicht, dass das irgendwas mit der Paketverwaltung zu tun hat. Generell solltest du erst mal rausfinden, warum keine Mails verschickt werden.Zitat:
Zitat von Thoni
Ja, das wurde entfernt, siehe https://github.com/contao-community-...ent/issues/232Zitat:
Zitat von Thoni
Eine genauere Anleitung wie man es manuell machen kann gibt es hier: https://github.com/contao-community-...ki/Switch-back
Das beste Lösung für alle scheint Composer zu deinstallieren. Ich hör nur negatives?
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.
...trotzdem würde ich den Composer gerne deinstallieren.
Gibt es da eine Möglichkeit?
» https://community.contao.org/de/show...l=1#post432086Zitat:
Zitat von Truller500
...vielen Dank für die Tipps.
Leider ist jetzt alles im Eimer... naja, habe ja ne Sicherung, aber vom Composer lasse ich weiterhin die Finger.