Mache ich dann nach meinen Tests am Wochenende natürlich auch, falls es bis dahin noch notwendig sein sollte ;).
Druckbare Version
Mache ich dann nach meinen Tests am Wochenende natürlich auch, falls es bis dahin noch notwendig sein sollte ;).
Habe gestern noch die Antwort bekommen, dass der Herr Möhring nicht mehr im Hause ist und sich Montag meldet... bin gespannt.Zitat:
Zitat von tblumrich
Gesendet von iPad mit Tapatalk
Habe das Ganze jetzt nochmal nachvollzogen. Einzige "neue" Erkenntnis hierbei ist, dass ein Update eines (manuell) frisch installierten Contao 4.4.4 auf Contao 4.4.16 mit der Manager-Version 1.0.0-beta16 im Platin-Kundenpaket auf 129.goserver.host problemlos durchgelaufen ist. Das hatte ich beim ersten Mal mit einer älteren Manager-Version gemacht und habe es deshalb nochmals mit der aktuellen Version probiert. Macht hier jedenfalls keinen Unterschied. Das Prozedere bei der Installation von Paketen war dann auch genau wie gehabt.
"Pakete installieren" endet bei jeder Erweiterung nach "updating dependencies" mit dem mmap-Fehler. Danach steht die neue Erweiterung erwartungsgemäß in der composer.json.
Nach dem mmap-Fehler einfach "Bestätigen und Schliessen", der Manager überprüft wieder das System und die Installation und läuft in das Fenster, in dem man zu installierende Pakete eingibt/sucht. Hier hinter dem Feld zur Eingabe der Erweiterung rechts das Kreuz anklicken. Jetzt bekommt man die Übersicht der installierten Pakete angezeigt. Nachfolgendes "Pakete aktualisieren" läuft dann problemlos durch, inklusive "updating dependencies".
Mal sehen ob ich heute noch Lust habe, alles wieder auf Null zu stellen und es mit dem Composer in der Konsole zu probieren.
Das warte ich dann erst mal ab bevor ich Webgo diesbezüglich kontaktiere, da sich unsere Pakete ahnlich oder gleich zu verhalten scheinen.Zitat:
Zitat von tblumrich
Hat er sich denn mittlerweile schon gemeldet?Zitat:
Zitat von tblumrich
Leider nicht. Schwankt im Moment leider etwas ... die Kommunikationsqualität.Zitat:
Zitat von tab
Gesendet von iPad mit Tapatalk
Hmm, seit heute habe ich jetzt im CMS-Power Paket das Problem, dass mir die Ausgabe im Konsolenfenster des Managers nicht mehr angezeigt wird. Keine Ahnung ob das jetzt von seiten Webgo kommt oder ob es an der Manager-Version 1.0.0-beta17 liegt. Ich bin mir aber fast sicher, dass ich die betreffende Installation über Ostern bereits mit dieser Manager-Version installiert habe. Und ich bin mir ganz sicher, dass während dieser Installation die Ausgaben angezeigt wurden. Es ist halt schon etwas nervig, jetzt jedes Mal einige Minuten zu warten, damit der Konsolentask sicher beendet sein sollte und dann ein Reload zu machen, womit ich nach Neustart des Managers dann die Ausgabe zu sehen bekomme :rolleyes:.
Edit: @tblumrich: Immer noch keine Antwort von Webgo?
Dieses Problem tritt bei vielen Hosting Umgebungen auf.
Doch vorgestern. Aufgrund Krankheit hat's wohl solange gedauert.Zitat:
Zitat von tab
Sinngemäß empfiehlt er mir auch den Wechsel ins Power Paket oder zu warten bis eine "ganzheitliche" Lösung da ist. Was auch immer das bedeutet.
Das Power Paket ist aber fast 4x so teuer - da bleibe ich ehrlich gesagt erstmal bei der Krücke mit dem zweiten Update-Anstupser über die Konsole.
Gruß Thomas
Ja, aber es trat bei mir jedenfalls bei Webgo nicht auf bisher. Da hatte ich das nur ein Mal bei einem Platin-Paket und bei weiteren Manager-Aufrufen war das dann weg, ohne dass ich irgend etwas wissentlich geändert hätte. Seitdem ist es bis heute nie mehr aufgetreten, auf keinem der mir zugänglichen Pakete.
Gerade teste ich es wieder auf dem Platin-Paket. Manager Version 1.0.0-beta17 und auch hier keine Ausgabe mehr zu sehen. Im Hintergrund ist dafür allerdings das Update auf Contao 4.4.17 ohne Fehler durchgelaufen :rolleyes:. Warum denn das jetzt wieder? Liegt das daran, dass beim Contao-Update das Lock-File mitgeliefert wird oder warum geht das jetzt plötzlich ohne Fehler trotz all der mittlerweile installierten Erweiterungen? Gerade mal auf dieser Testinstallation die Installation einer weiteren Erweiterung getestet... Puhhh, der mmap-Fehler ist noch da. Schon besser :rolleyes:, ich mag es nicht besonders, wenn Dinge mal funktionieren und mal nicht und ich keine Ahnung habe woran es liegt. Wenigstens ist jetzt halbwegs klar, dass das Problem mit dem mmap-Fehler bei Webgo im Platin-Paket weiterhin besteht. Ich gehe mal davon aus, die fehlende Ausgabe liegt dann wohl doch eher an der neuen Manager-Version :rolleyes::(
Edit: Nach einer nochmaligen Aktualisierung der Pakete wurde madeyourday/contao-rocksolid-custom-elements problemlos dazuinstalliert. Wie gehabt ... :rolleyes:
Hallo,
aus eigener leidvoller Erfahrung mit dem Platin-Paket kann ich einen Wechsel in dieses Paket empfehlen: https://www.webgo.de/cms/pakete/ (Power).
Wenn man mehrere Domains hat, wird es ein bisschen teuerer als das Platinpaket, aber der Wechsel lohnt sich. Kostet 7.95 € monatlich. Der Wechsel ging nicht über das Kundenmenü sondern nur über das Kontaktformular, weil im Kundenmenü nur die "normalen" Webhosting-Pakete zum Wechsel angeboten werden.
Viele Grüße
Hella
Hallo Hella,
genau dieses Paket habe ich für mich selbst. Da lief bisher alles problemlos. Die Installation von Erweiterungen funktioniert auch weiterhin, bloss habe ich jetzt keine Ausgabe mehr im Konsolenausgabefenster. Erst nach Reload der Seite wird mir dann alles angezeigt. Das ist natürlich unpraktisch, weil ich immer mehrere Minuten warten muss, damit der Konsolentask auch sicher beendet ist, bevor ich die Seite neu lade. Das hatte ich in dem Paket bisher noch nie.
Hallo.
So langsam nervt das Paket leider.
Jetzt geht auch der doppelte Anstupser nicht mehr. Die Konsole gibt jetzt immer Out of Memory aus, egal ob ich den globalen Composer nutze oder den CM über die Konsole ein Update machen lasse. Nichts geht mehr.
Kurze Frage zum empfohlenen Upgrade auf das o.g. Power Paket. Wie automatisch läuft das denn? Muss ich noch Daten hin und her schieben, E-Mail Accounts anlegen etc., Domains verbinden (hab einige extern aufgeschaltet)?
Gruß
Thomas
Mach deine Composer Operationen Lokal und führe am Server nur ein composer install aus. Es ist ohnehin nicht empfehlenswert solche Dinge ungetestet am Live Server zu machen.
Ja, das war zu befürchten :(. Ich habe die letzten Tage mal ein wenig getestet, eigentlich in der Hoffnung, einen Bug zu finden. Im Ergebnis sieht es allerdings so aus, dass das benötigte RAM beim "Pakete aktualisieren" bzw "composer update" etwa 120MB weniger ist als bei "Pakete installieren" bzw "composer require". Diese 120MB entscheiden dann im Endeffekt darüber, dass es im einen Fall nicht klappt und im anderen Fall reicht es halt noch. Aber es ist halt nur eine Frage der Zeit, bis entweder Contao noch mehr Pakete zieht oder die verfügbaren Versionen aller Pakete weiter wachsen, womit dann irgendwann bei "Pakete aktualisieren" auch nichts mehr geht.
Siehe auch https://community.contao.org/de/show...l=1#post470244 und die nachfolgenden Beiträge.
Darauf läufts wohl hinaus.Zitat:
Zitat von Spooky
Gut finde ich die Entwicklung auch nicht. Jetzt wird jede kleine Erweiterung zu einer großen Operation, die so einen Aktion und ein zweites lokales bzw. externes System auf potentem Server benötigt...
Zusatzfrage: Brauche ich überhaupt eine lokale/externe Contao Installation für die Erweiterungsupgrades? Ich will ja nur die Abhängigkeiten aufgelöst haben...
Gruß
Thomas
Es gibt leider keine Möglichkeit bei der composer.phar direkt nur das .lock file erzeugen lassen - also ohne die Pakete tatsächlich runterzuladen etc. Siehe dazu auch https://github.com/composer/composer/pull/4946Zitat:
Zitat von tblumrich
Aber alles was du brauchst ist die composer.json vom Server und PHP bei dir lokal. Dann kannst du ein composer update (oder sonst was) machen und dann die composer.json und composer.lock auf den Server kopieren und dort ein composer install ausführen.
Wie rufst Du denn die Befehle in der Konsole auf? Weiter oben hast du den Befehl mit "php71" aufgerufen, daher die Frage, hast Du es mal mit "/usr/bin/php7.2" versucht? Wobei Du die entsprechende php Version einsetzen musst, der richtige Pfad wird auch unter Serverkonfiguration im Contao-Manager angezeit.Zitat:
Zitat von tblumrich
Nur so aus Interesse (für den Befehl übernehme ich keine Verantwortung, habe ich mal aufgeschnappt und bisher noch nix kaput gemacht :) )
1. Aufruf: /usr/bin/php7.2 -r "echo ini_get('memory_limit').PHP_EOL;"
2. Aufruf: php7.2 -r "echo ini_get('memory_limit').PHP_EOL;"
(jeweils auf Deine php-Version angepasst)
Es wird das memory_limit für die Konsole angezeit, bzw. -1, wenn es kein eingetragenes Limit gibt.
Ja, habe ich versucht, Ergebnis immer "mmap() failed: [12] Cannot allocate memory".Zitat:
Zitat von andre.5tz
Es wird immer -1 ausgegeben.Zitat:
Nur so aus Interesse (für den Befehl übernehme ich keine Verantwortung, habe ich mal aufgeschnappt und bisher noch nix kaput gemacht :) )
1. Aufruf: /usr/bin/php7.2 -r "echo ini_get('memory_limit').PHP_EOL;"
2. Aufruf: php7.2 -r "echo ini_get('memory_limit').PHP_EOL;"
(jeweils auf Deine php-Version angepasst)
Es wird das memory_limit für die Konsole angezeit, bzw. -1, wenn es kein eingetragenes Limit gibt.
Ich nutze seit März ein neues Platin-Paket was bis jetzt problemlos funktionert, dann habe ich da vermutlich einfach nur Glück gehabt, oder noch zu wenig Erweiterungen.
Da wird bei dem Aufruf mit /usr/bin/php7.2 "-1" ausgegeben und mit php wird glaube das angegebene memory_limit für das Paket ausgegeben.
Habs jetzt endlich mal via Xampp ausprobiert und dadurch gleich das Composer Prinzip etwas besser verstanden. Funktioniert prima.Zitat:
Zitat von Spooky
Insofern kann ich das ja bei allen bockenden Installationen nutzen, richtig? Wenn ich das richtig aufgeschnappt hatte, ist die PHP Version wichtig, die sollte gleich sein (Lokal - Server)? Sonst noch was?
Danke und Gruß
Thomas
Falls sie nicht gleich ist, kannst Du das über
für die Auflösung vorgeben (PHP-Version anpassen).Code:"config": {"platform": {"php": "7.2.3"}}
Nachtrag: Hab es mal auf Grund des Hinweises von @Spooky (nächster Post) korrigiert.
Die Platform muss aber unter "config" definiert werden.
So liebe Community, nun möchte ich auch eine Frage stellen :)
Es ist ja der neue Contao Manger raus gekommen. Dieser arbeitet nun über eine Composer Cloud.
Ich habe selbst noch keine Tests gemacht und frage einmal ins Blaue:
Wenn man nun per SSH ein Composer Update anstößt , z.B. "/usr/bin/php7.1 /usr/bin/composer update" wird dann ebenfalls die Composer Cloud angesprochen oder muss man den lokalen Composer mit weiteren Parametern füttern um dieses verhalten zu erwirken?
Vielen Dank!
Nein es muss über den Contao Manager gemacht werden. Allerdings hat auch der Contao Manager ein CLI, evt. gibt es auch für das Cloud Resolving einen entsprechenden Parameter. Gute Frage auf jeden Fall ;)Zitat:
Zitat von daSilva
Werde ich die Tage dann einmal mit einem "strace" zerpflücken und hoffen, dass wir auch unseren SSH Jüngern eine Lösung anbieten können.
Auch wenn ich 127.0.0.1 im Install-Tool eintrage, wird keine Anbindung an die MySQL aufgebaut. Gibt es noch einen weiteren TrickZitat:
Zitat von daSilva
MySQL oder MariaDB?Zitat:
Zitat von HBR
MySQL - habe sämtliche Varianten durchprobiert, die hier im Forum auch versucht wurden, bekomme keine Verbindung.Zitat:
Zitat von Spooky
(contao 4.4.26, php 7.1 - Installation über Manager)
Für MySQL sollte es "localhost" sein, soweit ich weiß (mit default port 3306).
Sicher, dass du den richtigen Benutzernamen, Passwort und Datenbanknamen verwendest?
Ich würde mich an den Support wenden, per Mail oder über den Live-Chat. Das funktioniert gut. Die gleiche Kombination, PHP 7.1 + MySQL-Datenbank + Contao 4.4.26 habe ich erst vor einigen Tagen im Rahmen eines Updates problemlos ans Laufen bekommen in einem Platin-Paket. Aber es sind halt doch nicht alle Server/Pakete gleich, das habe ich gestern auch wieder gemerkt.
Ja kenne ich auch so bei webgo
-- ganz sicher, der Zugang mit phpMyAdmin Über die Hosterobefläche mit den gleichen Angaben funktioniert problemlos. Mehrmals gecheckt. Manuell eingegeben, kopiert usw.Zitat:
Zitat von Spooky
Bei mir beliebter Fehler DB-Name und Benutzer vertauscht.
Neuinstallation gemacht, alles nochmal frisch angelegt und jetzt hat es geklappt. Keine Ahnung voran es lag, aber wahrscheinlich war es doch irgendwo ein Copy & Paste Fehler. Sorry.Zitat:
Zitat von mlweb
Ich habe seit heute ein GoPaket "Platin" und versuche schon den ganzen Nachmittag meine Contao-4.4-Installation umzuziehen. Eigentlich keine große Sache, naja eigentlich...
Die Installation von 4.4LTS über den Contao-Manager (ohne Composer-Cloud) scheitert immer mit "Out of Memory", bei PHP 7.1 und 7.2 läuft die Installation an, bei PHP 7.3 bricht sie relativ kurzfristig ab.
Ich habe die Consolen-Logs für PHP 7.2 und 7.3 hier angehänt. Der webgo-Support ist kontaktiert. Bei meinem "alten" Webhoster läuft das problemlos und schnell durch, sogar mit memory_limit = 256M.
Das ist schon sehr betrüblich. Es wäre interessant zu wissen, ob das All-Inkl "Premium" besser hinbekommt, denn das hätte ich mir eigentlich als Alternative zu webgo ausgeguckt, mich aber heute für webgo entschieden.
Kann ich etwas tun? Gibt es Einstellungen oder ein anderes Vorgehen?
Anhang 22098Anhang 22099
Du musst im Contao-Manager den Cloud-Resolver aktivieren.
und was geschieht wenn Du die Composer Cloud benutzt ?
Die wäre ja da um solche Memory Errors zu vermeiden.
Lieben Dank für die schnelle Reaktion.
Die Composer-Cloud wollte ich aus Datenschutzgründen nicht benutzen, das war auch bisher nie nötig.
Bei meinem "alten" Webhoster (jweiland), dessen Paket hinsichtlich der Resourcen schlechter ausgestattet ist (aber wesentlich teurer) funktioniert es problemlos, auch ohne Composer-Cloud.
Ist das nun ein Problem des webgo-Platin oder ist es grundsätzlich so, dass man die Composer-Cloud aktivieren muss?
Liegt das am PHP memory_limit oder an einer Begrenzung der Server-Resourcen (RAM etc.)?
Du kannst es ja ab der Shell mittels composer versuchen.
Gib dazu den Parameter -d memory_limit=-1 mit
Ich habe den Composer noch nie manuell aufgerufen.
Mache ich das nach dem Fehlschlag?
Welche Datenschutzbedenken hast du bei der Installation mittels Contao Cloud Resolver? Zu dem Zeitpunkt ist das Einzige Datum, dass du auf einer bestimmten Domain Contao in einer bestimmten Version installierst. Hab ich was übersehen?
Bei webgo ist es aber nötig. Wenn Du diesbezüglich irgendwelche Bedenken hast, dann musst Du die Abhängigkeitsauflösung eben lokal auf Deinem Rechner (oder auf einem anderen Host) ausführen.Zitat:
Zitat von bejoro
Ja.Zitat:
Zitat von bejoro
Grundsätzlich nicht. In Deinem konkreten Fall hier aber schon.Zitat:
Zitat von bejoro
Letzteres.Zitat:
Zitat von bejoro
Tja, 2.5 GB sind halt schon eine Menge Holz. Die Webhosting die das bringen und weniger als das Doppelte kosten sind dünn gesät.
Vielen Dank für die Erklärungen.
Bedeutet das, dass das mit z. B. einem All-Inkl "Premium" auch nicht anders/besser laufen wird?
Das dürfte auch der Grund sein, warum mein aktueller Tarif bei jweiland (Business) so einen hohen Preis hat und dabei wenig Extras bietet. Offenbar ein rein auf hohe Typo3-Performance ausgelegter Tarif ohne jeglichen Schnickschack - für mich aber leider mittlerweile zu teuer für meine kleine Seite und mein kleines Geschäft.
Bei All-Inkl gäbe es u. a. auch einen Testaccount, wo Du das testen könntest: https://all-inkl.com/webhosting/test-account/
Lieben Dank, aber das hatte ich bei meinen Recherchen auch schon entdeckt.
Ich werde wohl nicht drumherum kommen und es ausprobieren oder mich mit der aktuellen Situation bei webgo zufrieden geben müssen.
Hoffentlich gibt es nicht noch weitere Überraschungen hinsichtlich des Betriebs von Contao mit webgo "Platin".
Webgo hat durchaus auch was zu bieten, was man anderswo in einem Webhosting nicht bekommt. Z.B. einen eigenen Apache, den man zu großen Teilen selbst konfigurieren kann. Ich habe mir vorgenommen mal zu versuchen, Contao 4 komplett ohne .htaccess zu betreiben. Sollte sich doch eigentlich alles komplett in der Serverkonfiguration einstellen lassen!? Das sollte dann nochmal ein Stückchen Performance bringen. Mal schauen.
Das war einer der Gründe, warum ich mich für webgo gegenüber All-Inkl entschieden hatte.
Mit aktiviertem Cloud-Resolver (Composer Cloud): Installation Contao 4.4LTS
Mit PHP 7.3STABLE funktioniert die Installation (Contao Manager) überhaupt nicht. Die Contao-Installation bricht nach wenigen Sekunden ab.
Mit PHP 7.2STABLE läuft die Installation durch.
Ich mache das nicht jeden Tag, deshalb alles in Ruhe, Schritt für Schritt eingerichtet (Tolle Anleitung: https://www.liquid-artwork.de/newsre...ingserver.html). Die Datenbank (nach Bereinigung 1,4M) habe ich per Shell (mysql) eingespielt, da phpmyadmin immer abgebrochen hat.
Die Website läuft! Was wirklich sehr interessant ist, dass sie ein gutes und sehr spürbares Stück auf webgo (Testdomain) schneller reagiert als meine Originalwebsite bei jeweiland. Der Unterschied ist sehr stark spürbar.
Ich habe beide Websites (Original und neue webgo-Site) per uptrends.com getestet, das Ergebnis ist sehr überraschend. Die Ladezeiten/Reaktionszeiten der Einzelelemente bei meiner webgo-Installation liegen bei ca. 1/4 bis zu 1/6 der Zeiten bei jweiland. Das ist beeindruckend. Die "Google PageSpeed Bewertung" bei webgo ist 77 bei jweiland 67 (was immer das aussagt).
Somit wäre das ein großer Fortschritt und meine Annahme, dass mein vergleichsweise sehr teurer jweiland-Tarif (20 Euro/Mon. mit 1 x SSL für 1 x Domain, 1 x freie Domain) nicht so performant ist, wie angenommen. Jetzt ärgere ich mich ein bisschen, dass ich das nicht schon viel früher in Angriff genommen habe. Aber so ist das im Leben. Wenn man um die Existenz kämpft, fallen manche Dinge einfach durch.
Sorry, ich schweife ab.
Frage: Muss ich mir nun Sorgen machen, dass PHP 7.3 nicht funktioniert hat (für die Zukunft)?
Der eigene Apache bei webgo ist schon schön, das reißt einen (hoffentlich) nicht in den Abgrund, wenn ein anderer Kunde auf dem Server etwas Seltsames anstellt. Was mich bei webgo stört, man kann die PHP-Version nur global festlegen. Es gibt keine Möglichkeit dies für die Domain/Subdomain einzustellen. Ich kann aber nicht beurteilen, ob das für zukünftige Anwendungen oder Contao-Updates ein Problem darstellt. Ich habe angefragt und es wurde mir mitgeteilt, dass das wohl in Planung wäre (Modernisierung).
Grundsätzlich wird man vermutlich bei allen Shared Hosting Paketen aller Hoster den Cloud Resolver benötigen.
Was war die Konsolen Ausgabe?Zitat:
Zitat von bejoro
Ja, das finde ich auch Schade.Zitat:
Zitat von bejoro
Die domainweise PHP-Konfiguration ist wohl schon länger in der Webgo-Pipeline. Meine Anfrage von vor ein paar Wochen wurde als Antwort beschieden, dass man Ende des Jahres anpeile. Vielleicht gibt es dann ja auch mal ein kosmetisches Update der Adminoberfläche …
Interessant finde ich, dass vor Erscheinen des Cloudresolvers C 4.4. auch ohne ihn installiert wurde, seither wird er aber benötigt.
Auf jeden Fall schlägt die Performance der Webgoseiten jeden anderen Hoster auf dessen Servern ich Webpräsenzen betreue – liegt wohl an der kurzen Leitung zum Backboen in Ffm.
Danke für die Info, das wäre ja schön, wenn diese Möglichkeit der PHP-Versionsfestlegung pro Domain mittelfristig eingeführt würde.
Bei PHP 7.3 wurde die Consolen-Task gestartet und mit "abgebrochen" sehr schnell wieder beendet, ohne dass der eigentliche Resolver-Prozess begonnen hat. Ich hätte das kopieren sollen, Sorry. Aber es wurden keinerlei zusätzlichen Informationen ausgegeben.Zitat:
Zitat von Spooky
Wie gefragt, ist oder könnte das ein Problem sein, dass ich PHP 7.3 nicht nutzen kann?
Ich muss mich ja aufgrund der Contao-Installation auf PHP 7.2 festlegen.
Ich muss mich in den nächsten Tagen entscheiden (vom Support zugesichertes Rücktrittsrecht), ob ich bei webgo bleibe.
Es gibt kein grundsätzliches Problem mit PHP 7.3. Daher wäre die Konsolen Ausgabe und das Log des Contao Managers interessant.
Ok, ich kann das gerne nochmal mit PHP 7.3 durchexerzieren, ist ja kein großes Problem.Zitat:
Zitat von Spooky
Wo finde ich das hierfür relevante Log des Contao Managers (ich finde hier mehrere)?
Sehr seltsam, gestern mit PHP 7.3 bestimmt fünfmal probiert und heute zweimal, es hatte nie geklappt.
Jetzt nochmal alles von vorne mit PHP 7.3, Cloud-Resolver (Composer Cloud) aktiviert gelassen und alles hat geklappt. Ich habe auch alles eingespielt und die Website läuft unter PHP 7.3STABLE.
Lieben Dank für den Anschub, dass ich es nochmal versuche.
Auch diese Anleitung ist sehr nützlich: https://erdmann-freunde.de/logbuch/contao-4-4-umziehen/
Die Variante mit der Shell hätte ich heute versucht, wenn es nicht funktioniert hätte.
Die funktioniert bei Webgo in den allermeisten Fällen leider auch nicht bei den GoPlatin Paketen.Zitat:
Zitat von bejoro
Doch, composer install sollte immer gehen.Zitat:
Zitat von mlweb
Ich bin mir jetzt wirklich nicht sicher, was ich machen soll. Ich habe so viel recherchiert und All-Inkl "Premium" oder webgo "Go Platin" haben sich herauskristallisiert.
Gibt es echte Erfahrungswerte, ob das All-Inkl "Premium" für Contao besser geeignet wäre? Auch Support etc.?
Der webgo-Support hat hinsichtlich meiner gestrigen, ausführlichen Contao-Manager-Anfrage (Out of Memory) bisher nicht geantwortet.
Aber die Composer-Shell-Methode nutzt auch den Cloud-Resolver (Composer Cloud)?
Hast Du den Memory Parameter (-d memory_limit=-1) beim Aufruf des Composer mitgegeben ?Zitat:
Zitat von mlweb
Bei meinem Hoster (Metanet) hat es ohne nicht funktioniert, kam auch Memory Error.
webgo ist ein Contao Partner.Zitat:
Zitat von bejoro
Da gibt es vermutlich auch nicht viel zu sagen ;).Zitat:
Zitat von bejoro
Nein - nur der Contao Manager kann das.Zitat:
Zitat von bejoro
Du kannst aber die composer.json und fertige composer.lock auf den Server spielen und dann ein composer install ausführen. Das wäre der gängigste Deployment Vorgang.
webgo hat mir angeboten, temporär den Hauptspeicher zu vergrößern, um die Installation mittels Contao-Manager ohne Composer-Cloud durchführen zu können.
Das Problem dürfte dabei nur sein, dass zwar die Installation durchläuft, später, wenn der Hauptspeicher wieder reduziert wurde, die Aktualisierungen aber möglicherweise wieder zu einem Fehler führen.
Sehe ich das richtig?
Ja, das siehst Du richtig! Welche datenschutzrechtlichen Bedenken hast Du denn gegen den Cloud-Resolver? Welche Bundles Du installierst ist doch eigentlich keine Information, die nicht z.B. packagist.org auch auf die eine oder andere Weise herausfinden kann.
composer install geht. Ich meinte composer update.Zitat:
Zitat von Spooky
Danke Dir für die Bestätigung.Zitat:
Zitat von tab
Ich hatte bisher den Cloud-Resolver nie benötigt (bei jweiland), installiere eher selten Contao und dachte mir, was sich an Außenkommunikation vermeiden lässt, das sollte vermieden werden. Außerdem wollte ich mein neues webgo-Paket vergleichbar installieren, um zu prüfen, was es taugt.
Sorry an die Profis, dass ich hier so lächerliche Fragen stelle. Ich muss alles selbst erledigen, kann aber nicht so tief einsteigen, wie ich gerne würde und führe solche Installations-Aktionen nur alle heilige Zeit durch (Aktualisierungen regelmäßig). Mir ist schon klar, dass so ein GoPlatin-Tarif für die meisten hier ein totaler Witz ist, aber für mich bedeutet es, wenn es einwandfrei funktioniert, eine erhebliche, jährliche Kosteneinsparung.
Übrigens: Mit aktiviertem SSL erreicht meine Website mit webgo ein "Google PageSpeed" von 99 (wie gesagt, was immer das aussagt).
Ja - mir ist erst dann aufgefallen, dass die Anleitung von EuF composer update statt install benutzt.Zitat:
Zitat von mlweb
Ja. Ich habe das bevor es die stable Funktion des Managers gab mit Webgo ausgiebig getestet. Damals konnte/wollte man nicht herausfinden, warum bei einigen Paketen insbesondere beim den GoPakten (Platin) auf der Konsole Probleme auftreten und bei anderen Paketen (CMS Power) nicht. Nachdem es den Cloud Resolver gibt, ist das Problem für mich überhaupt keins mehr und auch davor war es nur ein Luxusproblem, denn die Abhängigkeiten kann man auch lokal auflösen.Zitat:
Zitat von harley-rider
Ob besser oder schlechter ist etwas Ansichtssache. Einige Sachen gefallen mir bei Webgo sehr gut, andere finde ich bei All-Inkl. besser.Zitat:
Zitat von bejoro
Eine Sache, die für mich tatsächlich gegen All-Inkl. spricht ist die Tatsache, dass Cronjobs keine "echten" Cronjobs sind sondern nur PHP-Scripte mit starker Einschränkung bei den möglichen Befehlen. Das habe ich mal bei Einsatz des Updateskriptes von @fiedsch leidvoll erfahren müssen.
Support nimmt sich in meinen Augen nichts. Bisher hatte ich da bei beiden Anbietern nicht wirklich etwas zu beanstanden. Pannen passieren auch bei beiden, aber im Grunde arbeiten beide Anbieter lösungsorientiert und setzen kompetentes Personal ein.
Sehe ich nicht so. Ich habe lauter kleine Kunden. Da ich selbst nicht hoste, arbeite ich nur mit Hosting-Paketen im Bereich bis 10€. Meine Kunden habe ich bei Webgo, All-Inkl. und Netcup.Zitat:
Zitat von bejoro
Ja, Webgo macht einiges richtig, auch wenn es sicher noch Verbesserungspotenzial gibt. Aber wo gibt es das nicht? Das Go Platin ist nicht schlecht, habe ich wie geschrieben auch für Kunden im Einsatz. Keine supertollen Seiten, eher kleinere, relativ schlichte Seiten. Google Pagespeed gibt da sogar 100/100, sowohl mobil wie auch Desktop. Das klappt aber auch mit anderen Hostern. Google hat da seine Anforderungen wohl etwas an die durchschnittliche Wordpress-Realität angeglichen. :DZitat:
Zitat von bejoro
Wenn Du wirklich großen Wert darauf legst, den Contao-Manager ohne Cloud-Resolver nutzen zu können, in meinem Webhosting 4000 bei Netcup geht das (noch), habe gerade mal zum Test ein Update von 4.6 auf 4.7 gemacht. Allerdings habe ich da noch keine echt praxisrelevanten Erfahrungen. Da sind bisher nur Testinstallationen am Laufen, die dementsprechend natürlich keine Zugriffszahlen aufweisen. Die Geschwindigkeit ist mit Webgo vergleichbar, ebenso der Preis (wenn man bei Webgo das Go Platin vergleicht und nicht die aktuellen "offiziellen" Angebote, die ja eher etwas höher liegen im Preis). Wie überall gibt es aber auch da Höhen und Tiefen. Im direkten Vergleich Webgo/Netcup schätze ich den eigenen Apache und rsync in der Konsole bei Webgo sehr und vermisse praxistaugliches HTTP/2 (kein ALPN im Go Platin, somit verwenden aktuelle Browser eben kein HTTP/2). Soll aber kommen (wie so Vieles :rolleyes:). Und natürlich vermisse ich auch die individuell einstellbaren PHP-Versionen. Man kann halt nicht eben mal kurz z.B. PHP 7.3 an einer Kopie ausprobieren.
Das kann ich Webgo sagen. Das CMS Power bekommt offenbar auf der Konsole einfach mehr RAM als der Go Platin. Beim Platin ist nach meinen Erfahrungen bei 1 GB Schluss. Mag aber natürlich auch mal wieder von Server zu Server variieren, was ja nichts Schlechtes sein muss. Wenn auf einem Server nicht viel los ist, dann freue ich mich, dort mehr Ressourcen nutzen zu dürfen. Ich frage mich allerdings ob das Absicht ist oder Zufall ;). Insgesamt mache ich mir momentan ein wenig Sorgen, ob die sich nicht gerade ein wenig zuviel gleichzeitig vorgenommen haben und deswegen nirgends wirklich weiterkommen. Gerade das mit der Oberfläche höre ich da seit Tag eins. Und das sind mittlerweile demnächst zwei Jahre.Zitat:
Zitat von mlweb