Contao Manager 1.1.0 verfügbar

Hallo,

nach dem Update auf die Version 1.1.1 ging leider das Installtool nicht mehr ("Es ist ein Fehler aufgetreten.") In der Fehlermeldung steht, dass ich einen SQL-Fehler habe.
Nach dem Update auf 1.1.2: Lage unverändert.
Dann habe ich auf der Konsole ein composer update gemacht, das hat mir dann auch gleich Contao geupdatet (4.4.30).
Jetzt ist wieder alles hübsch und funktioniert.

Und: Danke für die viele Arbeit, die Ihr hier unentgeltlich reinsteckt, beim Entwickeln und auch beim Testen. Sicherlich gibt es immer Szenarien, die dadurch nicht abgedeckt werden (können). Fehler passieren eben mal und wenn sie immer so schnell behoben werden, wie bei Contao und dem CM ist das schon ein wirklich toller Service!

Viele Grüße
Hella

Zitat:

---

Zitat von fusch

nach dem Update auf die Version 1.1.1 ging leider das Installtool nicht mehr ("Es ist ein Fehler aufgetreten.") In der Fehlermeldung steht, dass ich einen SQL-Fehler habe.

---

Das war ein zeitgleich auftretender Fehler mit Doctrine. https://community.contao.org/de/show...o-install-quot der in den neuesten Versionen von Contao 4.4 und 4.6 behoben wurde.

Zitat:

---

Zitat von planepix

Jepp Jawoll und allaff ;).

Ich habe in den Installationen bei allinkl - auch Business Paket - alles auf den Cloud Resolver umgestellt - damit lief es dann wieder weiter super durch!
#einfachmaldankesagen

---

Kann ich bestätigen. Bei mir geht es nur noch mit dem Cloud Resolver. Egal wo, selbst unter localhost mit XAMPP/Windows bekomme ich immer die Meldung "Console task terminated!"
mit dem Hinweis auf memory limit, was aber bis zum Manager 1.0.4 einwandfrei klappte ohne Resolver und ohne Memory Limit Meldungen

Hallo Bennie,

dann schau mal, wie das memory limit in Deiner lokalen Umgebung gesetzt ist. Das ist oft standardmäßig begrenzt.

Gruß
Hella

Das ist es nicht. Es geht auf keinem Hostingpaket mehr wo es mit 1.0.4 immer ohne Resolver klappte.
Mich wundert eher, dass es nur bei mir so sein soll (und planepix) ?

Ich probier das nachher mal bei Netcup, da ging es bisher immer ohne Cloud-Resolver :rolleyes:

So, habe es probiert und es hat funktioniert, eine Installation auf 4.6.10 gehoben. Wieviel RAM das gebraucht hat weiss ich leider nicht. Vielleicht gönnt sich der Composer ja neuerdings mal wieder ein Zusatzhäppchen RAM.

Je mehr Versionen auf dem Markt vorhanden sind, desto mehr RAM wird für die Auflösung der Abhängigkeiten benötigt. Habe ich zu mindestens so verstanden.

Zitat:

---

Zitat von Bennie

Das ist es nicht. Es geht auf keinem Hostingpaket mehr wo es mit 1.0.4 immer ohne Resolver klappte.
Mich wundert eher, dass es nur bei mir so sein soll (und planepix) ?

---

Der Speicherbedarf hängt ja nicht von der Version des Managers ab sondern davon, was Du da installieren möchtest, welche Abhängigkeiten das hat und wie hoch der Bedarf für diese individuelle Auflösung der Abhängigkeiten ist.

Davon abgesehen verstehe ich nicht, warum man partout ohne den Cloudresolver arbeiten möchte. Der ist doch aus genau diesem Grund da.

Ja, das ist definitiv so. Wenn also mehr RAM benötigt wird und es nicht gleich ein Quantensprung ist, dann kann das durchaus die Ursache sein.

Edit: Benutzt habe ich übrigens ein Webhosting 4000, mal schauen wie es beim 2000 aussieht :).

Edit2: Auch das funktioniert, Update einer älteren Testinstallation von 4.5 auf 4.6 gemacht. Aufgefallen ist mir hier die Geschichte mit dem angeblich nicht installierten unzip. Ob das beim 4000er auch war weiss ich jetzt nicht, ist mir jedenfalls nicht aufgefallen.

Zitat:

---

Zitat von lucina

Davon abgesehen verstehe ich nicht, warum man partout ohne den Cloudresolver arbeiten möchte. Der ist doch aus genau diesem Grund da.

---

Naja, da wo es ohne geht, benutze ich ihn nicht. Er hat ja notgedrungen keine unendliche Kapazität, warum soll ich also die Ressourcen blockieren, die andere eventuell nötiger brauchen? Wenn das RAM jetzt freilich nicht mehr reichen würde, dann würde ich natürlich den Cloudresolver benutzen.

Zitat:

---

Zitat von tab

Naja, da wo es ohne geht, benutze ich ihn nicht. Er hat ja notgedrungen keine unendliche Kapazität, warum soll ich also die Ressourcen blockieren, die andere eventuell nötiger brauchen? Wenn das RAM jetzt freilich nicht mehr reichen würde, dann würde ich natürlich den Cloudresolver benutzen.

---

Ich habe auch so gedacht wie Du (bei meinem Hoster gehts auch ohne Cloudsresolver) aber auf unserer Heimfahrt vom Camp, hat mir Yanick erzählt, dass der Cloudresolver eigentlich am Däumchen drehen ist und mehr Kapazität vertragen könnte. Wenn eine neue Version von Contao veröffentlicht wurde, dann kann man (manchmal) sehen beim Updaten oder installieren im Manager, dass die Message sagt "dass gerade 5 Jobs am laufen sind und dass man 150 sek. warten muss" - dies ist mir bisher erst 1 x passiert.
Bezahlt wird der Server sowieso also kann man ihn auch benutzten, da er dafür gebaut worden ist.

Zitat:

---

Zitat von Bennie

Das ist es nicht. Es geht auf keinem Hostingpaket mehr wo es mit 1.0.4 immer ohne Resolver klappte.
Mich wundert eher, dass es nur bei mir so sein soll (und planepix) ?

---

Bin bei Webhostone - nur noch über Cloudresolver möglich. Hatte schon mal den Tarif wegen CM von 256RAM auf 512RAM erhöht. Reicht anscheinend nun nicht mehr.

Zitat:

---

Zitat von Tompaianer

Bin bei Webhostone - nur noch über Cloudresolver möglich. Hatte schon mal den Tarif wegen CM von 256RAM auf 512RAM erhöht. Reicht anscheinend nun nicht mehr.

---

Das hängt an den installierten Erweiterungen, wobei auch ich gefühlt mehr RAM brauche, als vor CM 1.1....

Zitat:

---

Zitat von lucina

Davon abgesehen verstehe ich nicht, warum man partout ohne den Cloudresolver arbeiten möchte. Der ist doch aus genau diesem Grund da.

---

Weil es vielfach nicht geht. Ich zB entwickle nicht lokal, daher habe ich path-repositories, die können (sollen) auch nicht mit CM. Aber das kann man nun wirklich niemandem vorwerfen, das hängt ja am persönlichen Setup. Wenn ich den CR benutzen will/muss, dann muss halt mein Setup anders.

Zitat:

---

Zitat von Tompaianer

Bin bei Webhostone - nur noch über Cloudresolver möglich. Hatte schon mal den Tarif wegen CM von 256RAM auf 512RAM erhöht. Reicht anscheinend nun nicht mehr.

---

Bei Webhostone hatte ich das auch, aber mittlerweile nach Löschen sämtlicher Caches geht es.

Zitat:

---

Das hängt an den installierten Erweiterungen, wobei auch ich gefühlt mehr RAM brauche, als vor CM 1.1....

---

Klar liegt es daran, nur wie gesagt bei mir ging es vorher ohne Probleme und außer enem Manager Update hat sich an den Paketen nichts geändert.
Aber wie schon erwähnt geht es bei mir mittlerweile auch ohne Cloud Resolver wieder , auch bei Webhostone.

An den Paketen kann sich zwischenzeitlich schon 'was geändert haben. Im Contao Manager siehst Du ja nur die Pakete der Contao Grundinstallation und jene, welche Du selbst installiert hast. Es gibt aber jede Menge weiterer Paketabhängigkeiten, die bei einer Paketaktualisierung im Hintergrund mit upgedatet werden müssen und somit ggf. die Speicheranforderung für das Auflösen dieser Abhängigkeiten entsprechend höher sein kann.

Ich nutze lokal u.a. die Docker Images von ctsmedia: https://github.com/ctsmedia/docker-contao

Vor CM 1.1./01.12 brauchte ich den Resolver nicht (mit memory_limit = 512M) - keine ext. Erweiterungen, nur Contao.
Klappt mit der aktuellen CM Version nicht mehr ohne Resolver.

Habe dann das memory_limit im Container auf -1 gesetzt. Damit scheint es auch ohne Resolver wieder durchzulaufen ...

Nach "Update Packages" unter gegeben Einstellungen (Standard) wurde 4.6.10 installiert, nicht 4.4.x geupdated!
Anbei ein Screenshot, als es durchgelaufen ist.

Anhang 21661

Zitat:

---

Zitat von Tim G

Nach "Update Packages" unter gegeben Einstellungen (Standard) wurde 4.6.10 installiert, nicht 4.4.x geupdated!
Anbei ein Screenshot, als es durchgelaufen ist.

Anhang 21661

---

Du hattest keine Standard Einstellungen. "Contao Open Source CMS" (contao/manager-bundle) sollte auf 4.4.*, nicht ^4.4 stehen. Durch deine Einstellung wurde das Update auf 4.6 erlaubt. Siehe https://github.com/contao/managed-ed...poser.json#L18

Nein, tut es nicht, siehe mein Link.

Danke. Hast recht!

Muß noch einmal nachhaken.
In einer Docker Umgebung (PHP 7.2) mit memory_limit=512M für die PHP-Cli (php -i | grep memory_limit) und PHP-Composer Version 1.8 kann ich in der Console/im Container:

- eine vollständige Contao Neu-Installation durchführen
- ein Update auf die aktuelle Contao Version durchführen
- eine o. mehrere Erweiterungen installieren

Mit dem CM 1.1.2 kann ich dies alles ohne den Resolver nicht. Warum?
Erst wenn ich das memory_limit für die PHP-CLI auf -1 setze geht es im CM auch ohne den Resolver ...

Aktuell braucht eine composer update Operation einer regulären Contao Managed Edition in Version 4.4.x bspw, ganz knapp über 1536 MiB an Arbeitsspeicher. Wenn dein memory_limit auf 512M gesetzt ist, erkennt das Composer und erhöht das Limit automatisch auf 1536 MiB, siehe https://github.com/composer/composer...mposer#L43-L45 . Aber wie schon gesagt ist das um ein paar Megabyte zu wenig.

Es ist jedoch vorstellbar, dass je nach Umgebung der Speicherverbrauch während der Abhängigkeitsauflösung doch ein paar Megabyte darunter bleibt und es daher trotz memory_limit funktioniert.

In einer korrekt konfigurierten Server Umgebung, ist das memory_limit für das PHP CLI immer -1. Andernfalls muss man das memory_limit per Parameter setzen.

Zitat:

---

Zitat von Spooky

...Wenn dein memory_limit auf 512M gesetzt ist, erkennt das Composer und erhöht das Limit automatisch auf 1536 MiB, siehe https://github.com/composer/composer...mposer#L43-L45 ...

---

Hm,
gut zu wissen - Danke.

Dennoch verstehe ich nicht warum der CM dann meckert, zumal es mit der CM 1.0.0 in dieser Umgebung (512M z.B. für komplette 4.4.28) auch ohne den Resolver fluppte ...
Für die lokale Umgebung ist es mir egal - setze es dann halt auf -1 ...

Zitat:

---

Zitat von Franko

zumal es mit der CM 1.0.0 in dieser Umgebung (512M z.B. für komplette 4.4.28) auch ohne den Resolver fluppte ...

---

Das ist ja jetzt schon wieder eine Zeit her. Jede neue Abhängigkeit, jede neue Paketversion, erhöht den Speicherverbrauch. Damals mit dem CM 1.0.4 (vermutlich) und einer neuen 4.4.28 Installation war der Speicherverbraucht vielleicht knapp unter 1536M. Jetzt ist er knapp über 1536M. Mit dem Contao Manager hat das nichts zu tun.

Zitat:

---

Zitat von Spooky

Das ist ja jetzt schon wieder eine Zeit her. Jede neue Abhängigkeit, jede neue Paketversion, erhöht den Speicherverbrauch. Damals mit dem CM 1.0.4 (vermutlich) und einer neuen 4.4.28 Installation war der Speicherverbraucht vielleicht knapp unter 1536M. Jetzt ist er knapp über 1536M. Mit dem Contao Manager hat das nichts zu tun.

---

Ja, Sorry - macht Sinn.
Aber welcher Hoster kommt da dann noch ohne den Resolver aus?

Habe eben mal auf z.B. hostingwerk via SSH gechecked: memory_limit=1G
Auch hier benötige ich jetzt den Resolver. Ist ja da und eine feine Sache, allerdings wollte ich den Resolver nicht unnötig strapazieren ...

Wir benutzen weder den Resolver, noch machen wir direkt am Hosting composer updates. Composer updates werden lokal geamcht, updates werden lokal geteste, es wird lokal entwickelt und am Server wird nur deployed.

Zitat:

---

Zitat von Franko

allerdings wollte ich den Resolver nicht unnötig strapazieren ...

---

Achwo, der Composer Cloud Resolver langweilt sich eh die meiste Zeit, z. B. jetzt gerade. :D

Zitat:

---

Achwo, der Composer Cloud Resolver langweilt sich eh die meiste Zeit, z. B. jetzt gerade.

---

:-)

Zitat:

---

Zitat von Spooky

Wir benutzen weder den Resolver, noch machen wir direkt am Hosting composer updates. Composer updates werden lokal geamcht, updates werden lokal geteste, es wird lokal entwickelt und am Server wird nur deployed.

---

Ja - OK,
wenn ich meine finalen, lokalen composer.json/.lock auf den den Zielserver setze und via CM installiere (Systemwartung/Composer Abhängigkeiten "Installer ausführen") flutscht es wie geschnitten ...
Denke nur das viele User es nicht spontan nachvollziehen können - aber naja - der Resolver ist ja per default aktiviert - von daher ...

Vielen Dank

Zitat:

---

Zitat von xchs

Achwo, der Composer Cloud Resolver langweilt sich eh die meiste Zeit, z. B. jetzt gerade. :D

---

Wenn sich noch eine Möglichkeit fände, wie man path- und private-repositories mit dem CR nutzen kann, dann, ja dann wäre da nix mehr mit Langeweile. :D

path wird nie funktionieren können. private repos gehen unter Umständen, wenn die Authentifizierungsinformationen in der composer.json direkt stehen, statt in einer auth.json. Habe ich aber noch nicht selbst ausprobiert.

Ich weiss, leider. Ich suche im Moment nach einer Möglichkeit, trotzdem Updates über den CR zu machen, ohne jedesmal die composer.json "manuell" bearbeiten zu müssen (und das path repository raus und wieder rein nehmen zu müssen). Irgendwannn finde ich da noch einen Weg, es zumindest leichter zu machen...

Edit: das mit den private geht genauso wie Du schreibst. Du hattest das mal irgendwo erwähnt, und ich hab's natürlich probieren müssen. Bei gitlab mit drei repos getestet, kein Problem, läuft anstandslos (wenn man die Token richtig hernimmt <- Notiz an mich: kopieren, nicht abschreiben :D )

Was bringt es dir die Path repositories immer zu entfernen und wieder hinzu zufügen? Warum brauchst du überhaupt path repositories?

Wir arbeiten am Support für lokale Artifacts (https://getcomposer.org/doc/05-repositories.md#artifact). Die Cloud wird das auch können indem der Manager ihr die composer.json's aller Artifacts mitliefert.
Sowas wäre theoretisch auch für "path" möglich. Aber eins nach dem andern. *schwitz*

Weil ich im Moment bei einem (sehr speziellen Kunden-) Projekt nur auf dem Server arbeiten kann (darf). Heisst für mich, ich entwickle eine Erweiterung die ich auf dem Server unter /_ext/meinBundle/ liegen habe, und diese binde ich mit dem Composer einfach per Symlink ein. Daher die Notwendigkeit des path. Nicht ideal, I know, aber was will man machen.

Ich hatte schon überlegt, ob ich mir nicht eine "Hilfskrücke" mittels gitlab bastele, aber das macht ja auch keinen Sinn, wenn man für jeden noch so kleinen Mist einen Commit bastelt, und sich den dann über den Composer zieht. Da werde ich ja nicht mehr fertig. Im Moment ist es daher die einizgste mir einfallende Möglichkeit.

Das heisst dann, wenn der RAM beim Server nicht mehr reicht, composer.json aufrufen, manuell die require Zeile löschen, den Verweis auf den path rausnehmen, speichern. CM öffnen, umstellen auf CR, update machen, und alles wieder zurück, nochmal updaten (da klappt es mestens, vermutlich weil ja nix mehr geprüft werden muss), dann passt wieder alles....

Wenn Du bessere Ideen für meinen Workflow hast, immer her damit! :) :) :)

Zitat:

---

Zitat von Toflar

Wir arbeiten am Support für lokale Artifacts (https://getcomposer.org/doc/05-repositories.md#artifact). Die Cloud wird das auch können indem der Manager ihr die composer.json's aller Artifacts mitliefert.
Sowas wäre theoretisch auch für "path" möglich. Aber eins nach dem andern. *schwitz*

---

Yes, yes, yes! Das sollte es zumindest einfacher machen. Wobei das ändern der Dateien auf dem Server schon echt angenehm ist, Du speicherst und hast direkt das Ergebnis.... Alles hat halt Vor- und Nachteile! :)

Zitat:

---

Zitat von PaddySD

Weil ich im Moment bei einem (sehr speziellen Kunden-) Projekt nur auf dem Server arbeiten kann (darf). Heisst für mich, ich entwickle eine Erweiterung die ich auf dem Server unter /_ext/meinBundle/ liegen habe, und diese binde ich mit dem Composer einfach per Symlink ein. Daher die Notwendigkeit des path. Nicht ideal, I know, aber was will man machen.

Ich hatte schon überlegt, ob ich mir nicht eine "Hilfskrücke" mittels gitlab bastele, aber das macht ja auch keinen Sinn, wenn man für jeden noch so kleinen Mist einen Commit bastelt, und sich den dann über den Composer zieht. Da werde ich ja nicht mehr fertig. Im Moment ist es daher die einizgste mir einfallende Möglichkeit.

Das heisst dann, wenn der RAM beim Server nicht mehr reicht, composer.json aufrufen, manuell die require Zeile löschen, den Verweis auf den path rausnehmen, speichern. CM öffnen, umstellen auf CR, update machen, und alles wieder zurück, nochmal updaten (da klappt es mestens, vermutlich weil ja nix mehr geprüft werden muss), dann passt wieder alles....

Wenn Du bessere Ideen für meinen Workflow hast, immer her damit! :) :) :)

---

Hm... naja wird die Erweiterung von mehreren Contao Installationen am selben Server benutzt? Wenn nicht, dann würde ich das einfach als lokales Bundle innerhalb der Contao Installation umsetzen.

Hmm, da hast Du durchaus Recht, so hab ich das noch gar nicht betrachtet. Während der Entwicklung wird nur in dieser Installation darauf zugegriffen. Wenn's fertig ist, dann natürlich nicht mehr (so hoffe ich, soll ja auch irgendwer kaufen :D :D :D :D :D).

Jo, dann macht es meiner Meinung nach keinen Sinn das als extra Paket zu integrieren :)

Das kommt wohl noch aus dem Contao 3.5-Denken wo alles ein Modul sein musste. In Contao 4 gehört applikationsspezifische Entwicklung gem. Symfony Best Practice nach "src" und in den Namespace "App" (ja, auch das "AppBundle" gehört längst schon wieder der Vergangenheit an) :)