Druckbare Version
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