Hat jemand praktische Erfahrungen mit den Hostingpaketen von Webgo?
Druckbare Version
Hat jemand praktische Erfahrungen mit den Hostingpaketen von Webgo?
Hallo,
bin erst vor kurzen zu Webgo mit einigen Projekten umgezogen.
Es läuft alles schnell und problemlos, in der kurzen Zeit einmal Kontakt mit dem Support gehabt der auch sehr kompetent wirkte.
Ich hatte nur bei der Einrichtung den Fehler begangen alles mit dem Haupt-FTP User anzulegen. Als ich jetzt zusätzliche FTP-User für einzelne Domains anlegen wollte habe ich festgestellt das dann einige Rechteprobleme auftreten.
Also wenn nötig für jede Domain einzelne FTP-Zugänge anlegen. Vielleicht läßt sich das Problem auch anders lösen, aber ich kann damit leben.
Offtopic:
War vorher bei TopHoster und eigentlich sehr zufrieden, bis auf einmal die PayPal-Kommunikation in einem Shop nicht mehr funktionierte.
TopHoster reagierte so träge das ich es leid war und zu Webgo umzog.
Gruß Michael
Bin schon seit Jahren bei Webgo, bin zufrieden. Guter Service.
Mich überzeugen gerade LetsEncrypt-Integration und SSD-Hosting. Was ich nicht so cool finde, ist, dass im Webhosting Domains inklusive sind. Sowas mag ich persönlich ja nicht.
Bevor ich umziehe: hat noch jemand mehr Erfahrungswerte?
Wer nutzt Composer über die Kommandozeile? Gibt es darüber keine PHP-Restriktionen (memory_limit etc)?
Funktioniert die Lets-Encrypt-intergration easy?
Externe Domains können easy und ohne Extrakosten aufgeschaltet werden?
Gibt es eine max. Postfachgröße. Diese ist ja frei wählbar. Ist der Postfachspeicher extra oder wird der Speicher des Hostings genommen?
Gleiche Frage für Datenbanken.
Bin seit einigen Monaten bei https://www.serverprofis.de/ und super zufrieden.
Transparente Daten, erstklassiger Support, Umstellung auf https problemlos.
VG
KDF
@KDF - die Frage war, ob jemand praktische Erfahrungen mit den Hostingpaketen von Webgo hat und nicht welchen Webhoster empfiehlt ihr.
Einfacher geht es nicht, läßt sich über das Kundenportal schnell und easy umsetzen und steht relativ schnell zur verfügung.Zitat:
Funktioniert die Lets-Encrypt-intergration easy?
Gruß Michael
Ich bin seit ein paar Wochen bei Webgo und musste den Support schon etwas nerven (weil immer bestimmte Tabellen beim Import von WordPress Datenbank unterschlagen wurden). Die Herren waren immer freundlich und schließlich haben Änderungen gegriffen. Let’s encrypt funktioniert schnell und einfach. Schnell ist überhaupt das Aufälligste. Komme aber auch von Strato. Angeblich soll es demnächst auch domainspezifische PHP-Versionen geben. Contao funktioniert bislang unauffällig.
So long
Michael
Hier ein paar Antworten auf meine eigenen Fragen ;-)
Hätte ich noch weiter geschaut, dann hätte ich erfasst, dass Webhostone ziemlich das gleiche bietet (auch gleiches Admin Panel etc), aber statt 6 kostenlosen Domains nur 1 kostenlose Domain bietet. Die Pakete sind dann auch günstiger. Ein Testaccount hat dann aber ergeben, dass bei Webhostone scheinbar die OpenSSL-Version oder so zu alt ist. Kann mich aber auch täuschen. Naja, ich drifte ab.
Ich verwende sowieso nur composer install und nicht composer update und kann mich deswegen nicht beschweren. Der Prozess "php" zeigt auf eine PHP5.6 Version, es stehen aber unter "/usr/bin" von "php55" bis "php71" alle denkbaren PHP-Versionen zur Verfügung. Und das trotz der chroot-Umgebung bei webgo. Bei 1&1 gab es auch eine chroot-Umgebung und ich hatte nur eine PHP 4-Executable zur Verfügung. Ging natürlich gar nicht, und das war der Kündigungsgrund für dieses eine Projekt.
An sich ja, aber keine Third-Level-Domains. Also wenn man nur eine Subdomain dort hosten will. Das ist sehr schade! Der Hoster geht wohl doch davon aus, dass man bei ihm die ganzen Domains registrieren will.
EDIT: alles in allem bin ich gerade zufrieden. Und wenn man sich ein bisschen bei den Hostern umschaut, dann weiß man, wie schwer es ist, einen guten Hoster zu finden. Ich persönlich habe echt lange gesucht. Das Admin-Panel wirkt noch etwas antiquar, aber der Support hat sich bereit gezeigt, meine Verbesserungsvorschläge zu berücksichtigen.
Sind die Pfade irgendwo auf der webgo Website dokumentiert? Gibt es für die Benutzung mit dem detached mode noch weiteres, was man bei webgo beachten kann oder muss? Wenn ja, bitte ergänzen: https://github.com/contao-community-...on-modes#webgo
Ist das wirklich so? Ich habe zwar auch festgestellt, dass man im Kundenportal direkt über Domains hinzufügen keine Subdomains angeben kann. Das ist für mich durchaus wichtig und wäre ein Argument gegen ein separates Hosting der Domains. Aber ich habe festgestellt, dass man für die hinzugefügten Domains auch Subdomains hinzufügen kann. Wer hindert mich also daran, meine externe Domain hier hinzuzufügen, die gewünschte Subdomain zu erzeugen und dann im DNS des Domainhosters nur die Subdomain an meinen Webgo-Server weiterzuleiten und die Domain selbst da zu lassen wo sie ist? Ich werde das nachher mal ausprobieren, bevor ich entscheide, wo ich mit meinen Domains hingehe.
Test erfolgreich beendet. Es funktioniert mit der Einstellung wie oben beschrieben. Ich habe jetzt eine bei 1&1 gehostete Domain, bei der die Hauptdomain auf den 1&1 Webspace zeigt, eine Subdomain auf meinen Uberspace und die andere Subdomain auf den Webgo-Webspace. Also alles gut und ich kann meine Domains beruhigt separat hosten.
Man kann den Hoster alle Nase lang wechseln, ohne die Domains umziehen zu müssen. Denn wenn man einmal einen guten Domain-Registrar gefunden hat, bleibt man da erfahrungsgemäß länger als bei jedem Hoster. Man ist flexibler und die Kosten sind transparenter.
Außerdem kannst du verschiedene "Teile" der Webseite bei verschiedene Hostern hosten. Brauch die www-Seite nur einen Billighoster, für eine Subdomain brauchst du aber ein Cloud-App-Hosting? No
Hier noch weitere Lektüre: https://wiki.uberspace.de/philosophy:domains
Hmm, wahrscheinlich habe ich jetzt den ersten Fall für den Webgo-Support. Ich habe eine meiner bestehenden Websites von Uberspace bei Webgo "dupliziert". Wollte einfach mal sehen, wie das mit der Performance aussieht. Das war anfangs auch ganz gut, jetzt habe ich plötzlich immer einen Fehler "502 Bad Gateway" und drunter steht in kleinerer Schrift "nginx". Hatte das schon mal jemand bei Webgo oder ist das eine Störung?
Ich habe mittlerweile festgestellt, dass ich auf statische Dateien noch zugreifen kann, nur dynamisch erzeugte gehen nicht. Soweit ich das glaube zu verstehen, ist nginx bei Webgo als Loadbalancer zwischen den Apache und das Internet geschaltet und für die Auslieferung von statischen Inhalten zuständig, während der Apache die dynamischen Inhalte liefert - oder eben auch nicht. Auch ins Backend meiner Contao 4.4.0 Testinstallation komme ich nicht mehr, auch wenn da eine andere Fehlermeldung - von Contao - kommt. Auch das hat schon mal funktioniert. Die contao-manager.phar.php kann ich aufrufen, Backend und Installtool nicht. Auch nicht über den Manager.
Aha, hängt wohl mit der eingestellten PHP-Version zusammen. PHP 5.6 und 7.0 funktioniert, 7.1 nicht - obwohl angeblich alle "stable" sind. Hatte vorhin die PHP-Version hochgesetzt zwecks Geschwindigkeitsvorteil, dabei aber den Apache nicht neu gestartet. Das hat er dann wohl zwischendurch mal selbst erledigt und danach ging dann nichts mehr.
PHP 7.1 hat in irgendeiner alpha oder frühen beta prinzipiell funktioniert, aber immer mit einer Fehlermeldung wegen fehlendem ioncube_loader. Die Fehlermeldung hatte ich auch schon in der 3er-Version mit Composer. Kann sein dass Andreas das irgendwann mit abgefangen hat.
Die 3.5.27 funktioniert da aber auch nicht mit dem PHP 7.1. Ist zwar mit Composer, aber ich habe den Paketmanager noch nicht angerührt hier bei Webgo. Wenn man wenigstens wüsste, woran es scheitert. Das Server Errorlog sagt nur
Code:[Fri Jun 30 22:11:32 2017] [notice] [client AH00052: child pid 9912 exit signal Segmentation fault (11)
Die 3.5.27 habe ich bei Webgo mit Composer laufen. Bei der Paketinstallation kommt halt immer die ioncube-Loader-Warnung.
Vielleicht muss ich auch nur mal die Erweiterungen updaten, habe ich länger nicht mehr gemacht. Vielleicht ist auch eine komplett inkompatibel damit. Teste ich heute nach dem Frühstück mal. Komisch ist allerdings, dass auch das Installtool und das Backend meiner frisch mit dem Contao-Manager installierten 4.4.0 mit der PHP 7.1 bei Webgo nicht laufen.
Ich teste nacher noch einmal eine ältere Version des Managers. Ich glaube da ging die 7.1. Aber eventuell hat Andreas irgendwann den fehlenden ioncube Loader mit abgefangen beim Manager.
Komische Sache, habe mir gerade mal die phpinfo der beiden PHP Versionen 7.0 und 7.1 aufgerufen und gespeichert, um sie in Ruhe zu vergleichen. Dann habe ich die 3.5.27 Website nochmal aufgerufen mit PHP 7.1 - und es hat funktioniert! Kein "502 Bad Gateway" mehr. War dann wohl doch eine Störung.
Dafür habe ich jetzt festgestellt, dass die Testinstallation Contao 4.4.0 immer noch nicht wieder läuft, allerdings auch nicht mit PHP 7.0 :confused:. Da scheint also grundsätzlich was nicht mehr zu funktionieren. Fehlermeldung sieht so aus:
Mit PHP 5.6 kann ich das Installtool aufrufen. Ich glaube, PHP 5.6 war auch aktiv, als ich Contao über den Manager installiert habe. Kann es damit was zu tun haben?Code:[2017-07-01 22:39:22] app.CRITICAL: An exception occurred. {"exception":"[object] (Doctrine\\DBAL\\Exception\\ConnectionException(code: 0): An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:103, Doctrine\\DBAL\\Driver\\PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:47, PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /home/www/meine-domain.de/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43)"} []
Gerade mal bei den anderen Beta-Testern gefragt: Antwort von @Bugbuster: "Der soll das merken und anpassen. Wird wohl öfters geprüft. Hatte ich hier auch schon gefragt."
Ansonsten mal in der manager.json nachschauen und ggf. den Pfad anpassen.
Ich habe gerade noch mal in meine Tests geschaut und folgendes gefunden. Reproduzierbar konnte ich bei webgo feststellen, dass ich bei PHP 7 nur mit MariaDB das Installtool aufrufen konnte. Da das Installtool selbst aber nicht zum Manager gehört, sind wir dieser Ursache auch nicht weiter auf den Grund gegangen.
Der Manager selbst funktioniert ja, auch nachdem ich die PHP-Version wechsle. Aber das installierte Contao funktioniert dann halt nicht mehr, da kann der Manager ja auch nichts dran machen, ohne dass er aufgerufen wird. Falls es wirklich an der PHP-Version liegt, die zur Installation verwendet wurde, was wäre dann die korrekte Vorgehensweise nach Änderung der PHP-Version, damit Contao wieder läuft?
Nach einer Änderung der PHP Version musst du potentiell auch ein composer update mit der richtigen PHP Version durchführen - bzw. die Platform Definition in der composer.json ändern und dann ein composer update durchführen (egal mit welcher PHP Version). Kommt aber einfach auf die Abhängigkeiten an, ob das notwendig ist.
Was du bei einer PHP Versions Umstellung aber in jedem Fall machen solltest ist den internen/Symfony Cache zu löschen.
Zu deinem aktuellen Problem: die Datenbank Verbindung funktioniert nicht. Rufe das Install Tool mal mit app_dev.php auf.
Ich bin da jetzt grade wieder dran, nachdem meine Webspace- und Domain-Umzugsaktionen weitestgehend abgeschlossen sind. Das Problem besteht nach wie vor. Contao und das Installtool laufen nur mit PHP 5.6. Contao wurde über den Manager mit PHP 5.6 installiert. In der composer.json steht nichts zum Thema "platform". Wie update ich den Composer und den internen symfony cache? Ist das das Zeug unter /var/cache/prod? Das habe ich alles gelöscht und es wurde neu aufgebaut. Und wie rufe ich das Installtool mit app_dev.php auf? Wieso kommt da die Datenbankverbindung nicht zustande? Ich glaube nicht, dass die Datenbankzugangsdaten nicht stimmen. Vielleicht ist es das einfachste, ich lösche das ganze Zeug und installiere nochmal komplett neu mit 7.1. Ist ja eh noch nicht viel passiert außer der Installation und den Systemeinstellungen.
Habe ich gerade auch gemacht. Auf webgo mit dem Manager Contao installiert. Nimm PHP 7.0. In der 7.1 fehlen noch ein paar Dateien bzgl. ioncube und no-debug-non-zts-20160303/ssh2.so.
Die Installation verlief einwandfrei, so wie im Video von Christian https://www.youtube.com/watch?v=Ov0JTctrbSE gemacht. Der Pfad zu PHP ist /usr/bin/php70.
Edit: Ging aber auch vorher mit PHP 5.6.
Hmm, ja, ionCube Loader hatte ich vorhin auch mal ne Meldung mit 7.1. Dann auf 7.0 umgestellt, aber da bekomme ich meine bestehende Installation auch nichts ans laufen. Ich lösche mal eben alles bis auf die contao-manager.phar...
Hast du ne MySQL oder mariaDB? Du weißt ja, dass bei der mariaDB der Host und der Port anders sind.
Host 127.0.0.1
Port 3307
Ich gebe auf für heute :mad:. Bei der Installation hatte ich wieder Meldungen dass irgenwelche Abhängigkeiten die falsche Version haben.
Trotzdem lief die Installation durch und ich konnte das Installtool aufrufen. Aber jetzt ist die Datenbankverbindung fehlgeschlagen, obwohl die Verbindungsdaten definitiv alle stimmen. Mit den Einstellungen komme ich z.B. per phpMyAdmin an die Datenbanken ran. Ich benutze überall den Hauptbenutzer, der sollte doch eigentlich für alle Datenbanken das selbe Passwort haben?!?!? :confused: Wahrscheinlich ist es einfach zu heiß hier, da funktioniert das Gehirn nur noch mechanisch :D.Code:Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zval_update_constant_inline_change
SourceGuardian requires Zend Engine API version 220131226.
The Zend Engine API version 320151012 which is installed, is newer.
Contact SourceGuardian Ltd. at http://www.sourceguardian.com/ for a later version of SourceGuardian.
Failed loading /usr/local/ZendGuardLoader-php-7.0-linux-glibc23-x86_64/ZendGuardLoader.so: /usr/local/ZendGuardLoader-php-7.0-linux-glibc23-x86_64/ZendGuardLoader.so: undefined symbol: zval_used_for_init
Bei meinen Tests mit dem Manager habe ich mir aufgeschrieben, dass es bei PHP 7 Probleme mit MySQL gab und ich habe deshalb in allen Installationen 7.0 (siehe Anmerkung von Andreas) und MariaDB im Einsatz. PHP 5.6 hatte ich nur mal in einer ganz frühen Phase des Managers der Vollständigkeit halber getestet (dort mit MySQL). Lief problemlos.
Meine Probleme sind mit 7.0 und 7.1, allerdings nicht mit MariaDB. PHP 5.6hat jedenfalls schon mal funktioniert. Mit dem neuesten Contao-Manager und PHP 5.6 probiere ich die Installation heute später nochmal.
ich werde heute auch mal das ganze testen... habe einige webgo goPakete.. von kleine bis ganz große...
mal schauen, ob es mir gelingt..
Hallo,
vom Webgo Support habe ich heute die Information bekommen, dass "im laufe der kommenden Woche die Ioncube und Zend-Guard Loader Meldungen bei Webgo behoben werden".
VG
André
Das sind gute Neuigkeiten, ich warte jetzt einfach mal. Die Fehlermeldungen bei PHP 7.0 ändern sich gerade mal wieder. ich habe aktuell seit heute Morgen noch eine zusätzliche Warnung bzgl. ImageMagick:
Ich hoffe doch, dass ImageMagick irgendwann wieder geladen werden kann, damit sich die Vorteile der neuen Contao-Version diesbezüglich auch auswirken können.Code:webxx@sxxx ~ # php70 -v
Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zval_update_constant_inline_change
SourceGuardian requires Zend Engine API version 220131226.
The Zend Engine API version 320151012 which is installed, is newer.
Contact SourceGuardian Ltd. at http://www.sourceguardian.com/ for a later version of SourceGuardian.
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/share/extensions/no-debug-non-zts-20151012/imagick.so' - libMagickWand-7.Q16HDRI.so.0: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 7.0.16 (cli) (built: Feb 22 2017 14:17:42) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
Edit: Wobei man natürlich erst mal testen muss, ob sich die Auswirkung nicht nur auf die Kommandozeile beschränkt und ansonsten alles läuft.
Bei mir ist PHP 7.0 eingestellt und Contao läuft auf einer MariaDB. Nachdem mir der Webgo Support heute freundlicherweise das Problem mit dem ZendLoader im WebHosting behoben hat, habe ich aktuell gar keine Fehlermeldungen.
Ist vielleicht auch abhängig von den Erweiterungen.
Ist bei mir momentan alles Standard wie von Webgo vorgegeben. Das mit imagick.so hatte ich gestern noch nicht auf der Kommandozeile. Wahrscheinlich werden sie deine Änderungen jetzt nach und nach auf die anderen Server übertragen. Deswegen warte ich jetzt erst mal ab, solange meine 4.4.1 Testinstallation läuft und keine Zicken macht.
Im Webspace-Admin kann man unter
Server - php.ini Konfiguration - Eigene php.ini Kofiguration
nachsehen, welche Erweiterungen aufgesetzt sind. Das unterscheidet sich, je nachdem, welche PHP-Version man eingestellt hat.
Letzte Woche war der ioncube_loader in 5.6 und 7.1 aufgesetzt. In 7.1 lief er nicht (Fehlermeldung), weil die Dateien für 7.1 noch nicht existieren. Für 7.0 war er nicht aufgesetzt.
Falls man da jetzt keine Fehlermeldungen bekommt, kann es auch daran liegen, dass ioncube_loader nicht mehr geladen wird ;). Also einfach mal in den php.in im Webspace-Admin nachsehen.
Die Dateien kann man per FTP sehen in
usr/local/
oder auch in
usr/share/extensions/
ssh2.so gab bei mir auf 7.1 auch ne Fehlermeldung weil die Dateien für 7.1 noch nicht verfügbar sind.
Gelten die Einstellungen der eigenen php.ini eigentlich auch für die Kommandozeilenversion?
Habe ich gerade mal ausprobiert. Mitbekomme ich PHP 5.6.3, egal wie der Server eingestellt ist. Möchte ich ich dort PHP 7 ausführen muss ich das wohl so machen.Code:php -v
Code:php70 -v
php71 -v
Ja, soweit klar. Aber ich meine, ob die eigene phpp.ini-Konfiguration aus dem Webspace Admin da hergenommen werden. Habs gerade eben ausprobiert und die Antwort ist: Ja! Jedenfalls konnte ich so das memory_limit ändern auch in der Kommandozeile.
Ah, ok. Danke für den Test.
Moin,
bei dem letzen PHP Update (7.1) wurde das php.ini Template der Version 5.6 in die Versionen 7.0 und 7.1 eingebunden, daher werden derzeit einige extensions bei PHP 7.0 und 7.1 geladen welche nicht existent sind.
Ich habe den Auftrag in der kommenden Woche dies auf allen Servern abzugleichen, so dass diese Meldungen nicht länger erscheinen.
Auf den generellen Gebrauch hat dies keinerlei Einfluss, die Warnung kann bis zu der Anpassung also ignoriert werden.
Gerne könnt ihr mich hier mit Fragen zu webgo löchern, ich versuche alle Fragen so gut es geht zu beantworten :)
Na dann erst mal willkommen im Forum.
Ich hätte dann auch gleich mal eine Frage. Mehrere Webgo-Kunden inklusive mir selbst haben festgestellt, dass bei der Installation von Contao über den Contao-Manager zumindest bei Verwendung von PHP 7.0 ein Problem besteht mit MySQL-Datenbanken. Ruft man das Installtool auf nach der Installation, kommt trotz korrekt eingegebener Datenbank-Zugnagsdaten keine Verbindung zur Datenbank zustande. Bei MariaDB dagegen funktioniert das. Das muss aber an der Art und Weise hängen, wie das Contao 4.4 Installtool versucht, die Verbindung herzustellen. Denn bei meinen Contao 3.5 Installationen funktioniert der Zugriff problemlos auf MySQL-Datenbanken. Hat irgend jemand eine Idee oder Lösung? Sei es von seiten Contao oder auch Webgo? Irgendwas scheint da nicht zusammen zu passen. Momentan benutze ich halt MariaDB, was bisher keine Probleme zu machen scheint. Habe das aber auch noch nicht sehr intensiv getestet bisher.
Ich habe das gleiche Problem. Bedenken habe ich wegen MariaDB prinzipiell keine. XAMPP in meiner lokalen Entwicklungsumgebung läuft ja seit einiger Zeit auch nur noch mit MariaDB, aber komisch ist das schon. Ich kann mich auch erinnern, dass ich am Anfang mal versucht habe Contao 3.5 (ich glaub mit PHP 5.6) mit MariaDB zu installieren und dort war es genau umgekehrt MySQL lief und MariaDB nicht.
Bei MariaDB ab Version 10.2.4 besteht allerdings derzeit noch dieses Problem, was man im Hinterkopf haben sollte.
Also ich bilde mir ein, kurz nach Freigabe von 4.4.0 eine funktionierendes Contao 4.4.0 mittels Contao-Manager bei WebGo mit PHP 5.6 installiert zu haben, die eine MySQL-Datenbank verwendet hat. Wenn ich mich recht erinnere, konnte ich auch Erweiterungen über den Manager installieren. Deswegen glaube ich nicht, dass es nur an Contao 4.4 liegt. Kann es ja auch nicht, läuft ja anderswo auch mit MySQL-Datenbanken. Gibt es eine Möglichkeit, die PHP-Version für eine Domain anders zu wählen als die globale Einstellung? Dann kann ich das gern nochmal ausprobieren mit PHP 5.6. War allerdings auch eine ältere Beta des Managers (Beta1 oder Beta4? weiss ich nicht mehr genau) Aber das sollte ja eigentlich keinen Unterschied machen. Ändert ja wohl am Installtool nichts?!?.
Brauchst Du nicht noch einmal ausprobieren hatte ich mir notiert:
- PHP 5.6, Contao 4 und MySQL hat funktioniert
- PHP 7.0 und 7.1, Contao 4 und MySQL hat nicht funktioniert
- PHP 7.0 und 7.1, Contao 4 und MariaDB hat funktioniert
- PHP ? Contao 3.5 und MariaDB hat nicht funktioniert
Alle Tests mit Contao 4 wurden mehrfach durchgeführt und waren reproduzierbar. Contao 3.5 habe ich damals nicht mehrfach getestet und mir auch die PHP-Version nicht notiert. Deswegen kann ich da einen Fehler meinerseits nicht ausschließen.
Die PHP-Versionen lassen sich leider nicht pro Domain einstellen, aber der Support hatte mir mal gesagt, dass das dieses Jahr noch etwas werden soll. Vielleicht kann da @daSilva was zu sagen.
Wie gesagt bei der 3.5 kann ich einen Fehler nicht ausschliessen. Es war eine meiner ersten Installationen für einen Kunden bei webgo. Die PHP-Version war aber definitiv 5.6 oder höher.
Danach hatte ich immer von vornherein MySQL genutzt. Erst bei den Tests für den Contao Manager kamm dann wieder Maria DB ins Spiel.
Seit gestern sollten alle Probleme behoben sein. Ich habe auf allen Servern die PHP Versionen angepasst.
Wenn es weiterhin Probleme gibt, lasst es mich wissen.
Also ich habe auf Server 124 noch
Code:web48@s124 ~ # php70 -v
Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zval_update_constant_inline_change
PHP 7.0.21 (cli) (built: Jul 17 2017 13:03:30) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
Code:web48@s124 ~ # php71 -v
Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zend_block_interruptions
PHP 7.1.7 (cli) (built: Jul 17 2017 12:46:43) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
Server 122 passt, Server 124 kann ich bestätigen, dass der Fehler noch auftritt.
Sollte jetzt passen:
EDIT: Damit PHP 7.1 in CLI ohne Probleme läuft, müsste man auch die PHP Version im webgo Webspace-Admin unter "Server -> Webserver Einstellungen" auf PHP 7.1 setzen.Code:web48@s124 ~ # php70 -v
PHP 7.0.21 (cli) (built: Jul 17 2017 13:03:30) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v6.1.0 (), Copyright (c) 2002-2017, by ionCube Ltd.
Danke, passt jetzt.
Server 86, bei Verwendung des global installierten Composers kommt bei composer update noch folgende Fehlermeldung:
Eingestellt ist PHP 7.0.Code:Failed loading /usr/local/ioncube/ioncube_loader_lin_7.0.so: /usr/local/ioncube/ioncube_loader_lin_7.0.so: undefined symbol: zend_ce_devision_by_zero_error
Wann wird es die PHP-Einstellungen domainbezogen geben?
composer greift leider mit "composer" auf die standard php Version in der CLI zurück (PHP 5.6) und verwendet die php.ini für php 7.0, daher der Fehler.
Man kann dies z.B. so umgehen: "/usr/bin/php70 /usr/bin/composer"
Dazu kann ich leider nichts sagen. In diesen Prozess bin ich leider nicht involviert.
@tab kannst du mal auf dem Server 124 die app_dev.php probieren? Ich hab zwar Benutzername und Passwort gesetzt - jedoch präsentiert mir der Webserver immer noch immer wieder die Anmeldemaske und lässt mich nicht einloggen. Derartige Probleme gibt es auf manche Apache Konfigurationen gern mal, daher wollte ich wissen ob das auf dem Server 124 generell passiert. Auf dem Server 122 funktioniert es.
Also ich hab zuerst Benutzername und Passwort gesetzt
Dann habe ich die Startseite aufgerufen mitCode:php70 vendor/bin/contao-console contao:install-web-dir --user=tab --password=mein_passwort
Ich musste User und Passwort eingeben, dann wurde die Seite angezeigt mit einer Leiste mit Informationen am unteren Rand des Browserfensters. Danach konnte ich normal die Navigation benutzen ohne Username und Passwort nochmal eingeben zu müssen.Code:http://meinedomain.de/app_dev.php
Hm, ok, komisch. Keine Ahnung woran es bei der einen Installation auf Server 124 hapert.
Konntest Du dieses Problem lösen?
Bei mir hat das m.E. auf dem Server 86 schon mal funktioniert. Heute wollte ich das für eine zweite Domain setzen und erhalte genau wie Du immer wieder nur die Anmeldemaske. :confused:
Nachtrag: Gerade noch einmal getestet. Gleicher Server zwei verschieden Domain. Bei einer funktioniert es. Hier wurde das Passwort vor ein paar Tagen gesetzt. Bei der anderen nicht. :mad:
Browserneustart und selbst Rechnerneustart und anderer Browser haben nicht geändert.
Kann ich eigentlich einfach ein neues Passwort setzen oder muss ich da vor her etwas löschen?
Sollte gehen. Sonst lösche einfach die .env Datei im Root.