Druckbare Version
Der Manager ist ja immer derselbe. Spannend wäre vermutlich die Frage, weshalb unter PHP7 mit identischem Script der Aufruf ankommt.
Für mein diesbezügliches Ticket warte ich jetzt seit 12 Tagen auf Antwort.
Was für ein Saftladen.
Gesendet von iPhone mit Tapatalk
Wer hat sonst noch Kontakt zu Host Europe? Mit dem aktuellen Ticket komme ich nicht weiter :mad:
Zitat:
Dass PHP 8.1 durch die getätigten Änderung den Tmp-Pfad nicht erneut inkludieren möchte, muss so hingenommen werden. Da der Pfad in der bash_profile auf Ihrem derzeitigen Webhosting Paket nicht geändert werden kann, bleibt Ihnen hier
a) bei Contao anzufragen, ob die Problematik der Abfrage des Tmp-Pfades unter PHP 8.1 bereits bekannt ist und behoben wird oder
b) auf einen Webserver zu wechseln.
Heute in meiner Post:
Zitat:
Bitte entschuldigen Sie die verspätete Rückmeldung, aufgrund des
ausführlichen Tests zu Ihrem Anliegen, kam es leider zu der
verzögerten Antwort.
Bei unserem Test haben wir versucht, mithilfe des Contao Managers
und der PHP Version 8.1, Contao auf einem Internen WebHosting
Produkt zu installieren.
Dabei haben wir zunächst einmal geprüft, ob das sys_temp_dir
von PHP ausgelesen wird, wenn eine php.ini Datei inkludiert
wird.
Inhalt der php.ini: sys_temp_dir=/tmp/testumgebung
Konsole:
php8.1 -c php.ini -a
php > echo sys_get_temp_dir();
Ausgabe:
/tmp/testumgebung
Anhand der Ausgabe ist zu erkennen, dass das sys_temp_dir
korrekt von PHP ausgelesen werden kann.
Bei der Installation von Contao erhalten wir folgenden Fehler:
(Bitte beachten Sie, dass die vertraglichen Informationen durch
ein x ersetzt worden sind)
Notice: tempnam(): file created in the system's temporary directory in /is/htdocs/wpxxxxxxxx_xxxxxxxxxx/www/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php on line 680
Fatal error: Uncaught ValueError: Path cannot be empty in /is/htdocs/wpxxxxxxxx_xxxxxxxxxx/www/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php:689
Eine manuelle Analyse hat ergeben, dass bereits "file created in the system's
temporary directory" bei der Installation fehlschlägt. Das Tempfile sollte
in der Datei mit dem folgenden Befehl angelegt werden:
$tmpfile = tempnam(sys_get_temp_dir(), 'symfony');
Da dieser Befehl in einem normalen PHP Webskript und manuell beim Aufruf
der PHP cli mit einer php.ini Datei funktioniert, scheint Contao das
Skript ohne die php.ini Datei erneut zu inkludieren, aufzurufen.
Dadurch ist das tmp_dir nicht gesetzt und es kann auch keine Datei
dorthin geschrieben werden.
Ob eine Änderung in Contao oder in Symfony zu den Problemen mit der
PHP Version 8.1 führt, können wir nicht sagen, daher müsste dies
einmal seitens der Entwickler geprüft werden.
Daher ist eine Nutzung auf einem WebHosting Produkt nicht möglich
und wir empfehlen auf die WebServer Generation zu wechseln, da
man den Pfad in der bash_profile definieren kann.
Für weitere Fragen stehen wir Ihnen gern zur Verfügung.
Die sind leider m.E. immer noch einen Schritt vom eigentlichen Problem entfernt. Stichwort passthru ...
Ja, sind sie, und ich würde das gerne beantworten. Ich kann das aber nicht so aufschreiben dass es zweifelsfrei, inhaltlich klar und absolut zielführend ist.
Feel free für Textvorschläge.
EDIT: Ich bin jetzt nicht so firm in den Interna des Managers, aber wenn der Haken bei $tmpfile = tempnam(sys_get_temp_dir(), 'symfony'); liegt, können wir das nicht einfach noch einmal setzen?
Nein, Symfony/Contao verlässt sich darauf (wie jede andere PHP Applikation), dass sys_get_temp_dir() immer ein korrektes Directory liefert, egal wie der PHP Prozess gestartet wurde. Der Fehler ist, dass wenn der PHP Prozess über passthru() gestartet wird, dann nicht mehr das korrekte Temp Dir seitens des Hoster gesetzt ist. Und das muss HostEurope beheben (nicht die Applikation).
Das hiesse ganz konkret, dass sie PHP-CLI mitgeben müssen, wo sich das Tempdir befindet, unabhängig davon, wie es gestartet wurde?
Was genau der Hoster machen muss weiß nur der Hoster...
Das ist schon klar - aber die CLI-Version muss wissen wo sich das (userspezifische) Tempdir befindet?
So sieht die Implementation von sys_get_temp_dir() aus: https://github.com/php/php-src/blob/...le.c#L203-L279
Also:
- Ist die sys_temp_dir .ini Einstellung definiert, wird dieser Pfad zurück gegeben.
- Unter Windows wird eine entsprechende Win32API Funktion genutzt.
- Ist (unter non-Windows) die TMPDIR Umgebungsvariable definiert, wird dieser Pfad zurück gegeben.
- Ansonsten wird ein Standard Directory zurück gegeben.
Ich finde es absolut beschämend was da bei Hosteurope abgeht.
Wenn die Mehrzahl der Hoster mit Contao 4 und PHP8.1 keine Probleme hat (nicht mal Strato hat ein Problem), dann sollte man sich als Hoster nicht auf das hohe Ross setzen und sagen Contao ist Schuld.
Der letzte Satz ist eben der große Irrtum. Es gibt eben mehr als zwei Möglichkeiten, diesen Befehl aufzurufen. Nicht nur per normalem Webskript oder per CLI. Das Webskript sollte von einem anderen Webskript mittels passthru() aufgerufen werden und damit als Konsolenprozess laufen.Zitat:
Zitat von HE-Support
Leider bin ich jetzt nicht der große PHP-Entwickler habe die beiden Skripte nicht mehr verfügbar, die mir @ausi mal anlässlich eines verwandten Problems bei All-Inkl geschickt hatte. Das hat damals auch mehrere Anläufe beim Support gebraucht, bis das Problem komplett verstanden und dann auch prompt korrigiert wurde. Solche Skripte bräuchte man jetzt eben wieder, damit sie nur die beiden relativ einfachen Skripte hernehmen und dasjenige, welches das andere per passthru() aufruft, im Browser aufrufen müssen, um den Fehler zu bekommen. Es sollte dann freilich jemand in einem betroffenen Webhosting verifizieren, dass mit PHP 8.1 beim Aufruf des Skripts auch der Fehler auftritt und mit einer anderen, nicht betroffenen PHP-Version eben nicht. Sonst stehen wir hinterher noch schlechter da als jetzt ;)
Der erste Teil des Satzes gilt leider immer noch, aber die beiden Skripte bzw deren Inhalt habe ich jetzt in dem entsprechenden Issue auf Github wiedergefunden. Ich versuche mal, die beiden Skripte an das aktuelle Problem anzupassen, kann das dann allerdings nur bei mir ausprobieren, wo es vermutlich funktionieren wird.Zitat:
Zitat von tab
Edit:
So könnten die beiden Dateien z.B. aussehen, der Pfad zum PHP 8.1 CLI müsste natürlich auf HE angepasst werden. Wenn ich die in die document root oder in ein Unterverzeichnis davon lege, kann ich sie im Browser aufrufen und bekomme den Pfad der erzeugten temporären Datei angezeigt.
Edit2:
Sowohl createTmpfile.php als auch execute_createTmpfile.php können im Browser aufgerufen werden. Der Aufruf von createTmpfile.php wird bei HE funktionieren, der von execute_createTmpfile.php wird vermutlich einen Fehler werfen, weil die Datei nicht erzeugt werden kann.
Aber wahrscheinlich kommt dann sowieso wieder der lapidare Kommentar, dass hier ja die php.ini vergessen wurde. Schliesslich ist immer der Kunde schuld und niemals die Hostingumgebung fehlkonfiguriert. :rolleyes:
Auch wenn es bei den anderen PHP-Versionen funktioniert hat und bei anderen Hostern sowieso.
Edit3: Halbe Datei vergessen :rolleyes:PHP-Code:<?php
// execute-createTmpfile.php
passthru('/opt/keyhelp/php/8.1/bin/php '.__DIR__.'/createTmpfile.php');
PHP-Code:<?php
// createTmpfile.php
$tmpfile = tempnam(sys_get_temp_dir(), 'symfony');
if ($tmpfile !== false) {
echo "Datei ".$tmpfile." wurde erzeugt!";
}
else
{
echo "Es ist ein Fehler bei der Erzeugung der temporären Datei aufgetreten!";
}
Bei einem Kundenprojekt: WebHosting MediumZitat:
Zitat von Ainschy
C4.9.33 kann mit 7.4 installiert werden sobald auf 8 umgestellt wird kracht es.
Am besten man wechselt zu einem anderen Anbieter, oder alternativ Mails bleiben bei HE und das Hosting mit Contao per DNS Eintrag.
Heute kam wieder ein ReminderDann müssen wir in den nächsten Wochen wohl einen neuen Hosting Partner suchen. Ich frage mich wieviel Contao Instanzen bei Host Europe nicht mehr laufen werden.Zitat:
Host Europe informiert: Deaktivierung PHP 7.4 am 14.11.2022
Das Unterforum Erfahrungen mit Webhostern > Host Europe kann dann auch gelöscht werden :o
Tja, das kann ne Menge sein - ich habe heute (dir mir schon bekannte) Info zu ca. 70 Installationen bekommen, zuzüglich derer, die mir Kund:innen nicht weiter geleitet haben. Über 120, schätze ich.
Ich bin heilfroh, dass ich außer einem Kunden, der aller 2 Jahre mal bei mir mit irgendeinem Problem aufschlägt keine Kunden bei Hosteurope habe. Dem einen Kunden habe ich schon mitgeteilt, dass er entweder den Hoster wechselt oder auf mich verzichten muss.
Nächste Woche werde ich mal bei meinem einzig verbliebenen Kunden bei Domainfactory testen auf PHP 8.1 umzustellen. Da dort ja auch Hosteurope/GoDaddy mit drinhängt, rechne ich mit dem Schlimmsten.
Hallo Community,
Frage 1: Wie weiter oben erwähnt habe ich Contao 4.13.8 auf HE mit PHP 7.4.X erfolgreich installiert; danach PHP auf 8.1 umgestellt und die kleine Präsentationshomepage ohne viel Schnickschnack läuft ohne Probleme. Was spricht dagegen diese Seite einfach laufen zu lassen - also den Contao Manger einfach nicht zu starten. Backend klappt, man kann ändern usw. Das müsste doch eigentlich ohne Probleme weiterlaufen bis man den Manager startet und der nach Updates sucht und versucht zu installieren. Sehe ich das falsch?
Frage 2: Gibt es kein Möglichkeit notfalls irgendwie den Manager lokal laufen zu lassen und dann auf die 8.1er HE Installation aufzuspielen - denke das wird aber mit den Symlinks etc. nicht klappen?
Lieben Gruß!
PS Hoffe aber immer noch dass HE das Problem löst. Oder ein Contao-Batch der dann auch die HE Installation ermöglicht.....
Nette Idee, aber vermutlich nicht dauerhaft hilfreich.
Zu 1
Der Sinn einer Paketverwaltung ist ja, die zum System passenden Pakete zusammenzustellennund zu installieren. Also ist in den allermeisten Fällen ein Contao, das für PHP 7 zusammengebaut wurde ein anderes als eines, dass für PHP 8 gebaut wurde. Vieles davoin siehst du nicht, aber es spielt sich in den Abhängigkeiten, der Symfony-Version, etc ab.
Es kann gutgehen, wenn du einfach die PHP-Version umstellst, es muss aber nicht gutgehen. Im Verlauf der Zeit werden wir immer mehr Dinge sehen, die in diesem Zusammenhang nicht gutgehen. Manche Extensions und vermutlich auch der Core machen schlicht andere Dinge, nutzen andere Funktionen - und wenn diese Funktionen nicht da sind, dann knallt es halt auch mal.
Wenn es eine reine Präsentationsseite ist, an der sich nichts ändert und auf der auch keine interaktiven Elmente vorhanden sind, dann würde ich da vermutlich eher mal einen Crawler drüber laufen lassen und das Ergebnis als statisches HTML speichern, um das dann auf den Server zu spielen.
Zu 2.
Der Manager verwaltet das System rudimentär und löst Abhängigkeiten auf, um die dann an Composer zu verfüttern. Was er verfüttert steht dann im Ergebnis des Auflöseprozesses -> in der composer.lock. Die kannst Du natürlich auch woanders unter gleichen Voraussetzungen erstellen.
Es knallt allerdings bei Composer, der aus dem zu installierenden Set (in der composer.lock) rauszieht, welche Pakete er downloaden und installieren soll. Das funktioniert allerdings bei HE nicht, weder, indem der Manager Composer aufruft noch über (bei mir, auch auf einem Webserver nicht) die Kommandozeile, weil sie ihm die Ablage temporärer Dateien verwehren, indem sie ihm nicht verraten, wo er sie ablegen soll.
Ich sehe da eigentlich nur die Lösung, den Hoster zu wechseln (und ich bin munter dabei, weil ich nicht wo sein möchte wo ich mich nicht drauf verlassen kann dass die ihren Job machen).
Und sie werden es nicht ändern:
Auf meinem WebServer übrigens das selbe Spiel.Zitat:
Beim Installationsversuch erkennt der Composer/Contao Manager zwar das
Tempdir Verzeichnis, besitzt aber nicht die benötigten Schreibrechte.
Dass der Zugriff auf unseren Shared-Hosting Umgebung auf das Temp Verzeichnis
nicht möglich ist, ist von der Konfiguration her gewollt und aus Datenschutzgründen
unumgänglich. Andernfalls könnten dort abgelegten Daten von anderen Kunden
eingesehen werden.
Zuvor hatte man bei PHP 7.4 die Möglichkeit mithilfe einer im Installationsverzeichnis
des Contao Systems abgelegten php.ini, das Kunden Temp Verzeichnis zu definieren, welches
vom Composer bei der Ausführung der Installation berücksichtigt wurde. Dieser
Workaround funktioniert nun bei PHP 8 nicht mehr, da die Pfad Bestimmung durch
die php.ini Datei vom Composer ignoriert wird.
Um Contao auf unseren gemanagten Produkten mit PHP 8 nutzen zu können,
empfehlen wir weiterhin die Produktreihe "WebServer".
Glauben die das wirklich, was die da schreiben. Falls ja, was haben die genommen und wo bekommt man das?Zitat:
Zitat von lucina
Ich habe heute bei meinem Kunden bei DF die Umstellung auf PHP 8.1 problemlos durchgeführt. Vielleicht können sich die Techniker bei Hosteurope etwas Nachhilfe bei DF holen :D. Zu einem Konzern gehören sie ja, wenn ich recht informiert bin.
Ich habe mir heute nochmal meine Korrespondenz mit All-Inkl durchgelesen. Dabei ist mir aufgefallen, dass die Argumentation des All-Inkl Supports derjenigen von HE gar nicht so unähnlich war. Sie schlugen erst mal vor, den Pfad zum mysqld.sock doch im Skript anzugeben. Dort konnte ich den Support auch erst überzeugen, als ich ihnen den Pfad zur entscheidenden php.ini geschrieben habe, in der sie vergessen hatten, den Defaultwert durch den korrekten Pfad zu ersetzen, der in all ihren anderen php.ini Dateien drinstand. Welche php.ini verantwortlich war, habe ich damals durch Aufruf der phpinfo() durch passthru() (oder durch Aufruf von php -i, bin ich mir nicht mehr sicher, sollte aber beides ausreichen) herausgefunden. Den Output hatte ich mir in eine Datei schreiben lassen, die ich dann in Ruhe durchsuchen konnte. So konnte ich zum Einen verifizieren, dass da der entscheidende Wert (Pfad zum mysqld.sock) anders war als in den anderen php.ini Dateien - und zum Anderen auch schauen, welche php.ini Dateien bei dieser Art des Aufrufs von PHP berücksichtigt wurden. Erst als ich das Ergebnis dann dem Support zuschickte und nachfragte, ob man das nicht durch Änderung der php.ini fixen könnte, was ja dann allen Kunden zugute kommt. Anstatt das jeder betroffene Kunde den Pfad in seinem Skript selbst richtig setzen muss. Das hat man dann eingesehen und das Problem war sehr zügig behoben.
Trotzdem glaube ich nicht, dass man HE auf diese Weise zur Änderung bewegen wird, weil die Contao-Kunden ja schon den ersten Workaround , die zusätzliche php.ini, gefressen haben. Das war bei All-Inkl anders, weil da im Webprozess und beim direkten Aufruf in der Konsole alles funktioniert hat ohne jeglichen Workaround. Und außerdem, weil man All-Inkl auch nicht ernsthaft mit HE vergleichen kann.
Sie machen es ja mit Absicht so - haben sie gesagt.
Ich bin mittlerweile auf einen VPS bei der Hetzner Cloud umgestiegen. Damit sind solche Probleme Geschichte. Debian 11, HestiaCP. Hestia kümmert sich um fast alles und bietet eine recht logische Benutzerführung. Wer Contao 4 installieren und warten kann, für den ist der Sprung zum VPS nicht weit. Ich habe vor, den Vorgang mal auf meinem Blog zu beschreiben inkl. zusätzlicher Sicherheits- Performance- und externer Backupeinstellungen.
Gesendet von meinem 2109119DG mit Tapatalk
Ist noch jemand mit Host Europe in Kontakt? Wenn die Probleme nicht gelöst werden, müssen wir unsere WebHosting Verträge kündigen. Die Kosten für ein Webserver Produkt sind für eine Vereinshomepage nicht gerechtfertigt.
Was ich mitbekommen habe ist, dass sie sämtliche Tickets dazu geschlossen haben. Ziehe selbst deine Schlüsse.
Bin gerade erst mit einem fehlgeschlagenen Update auf diese miserable Situation bei Hosteurope gestoßen.
Etwas Neues gibt es vermutlich nicht, oder?
Liebe Grüße, Petra
habe die letzten 7 Kundenaccounts gekündigt und ziehe um...
Hallo Zusammen,
ich hatte mit mehreren Seiten Probleme bei HE und habe den Support kontaktiert und Antwort bekommen:
Das Verhalten des Webservers und auch Seitens PHP hat sich zwischen den Versionen 7.4 zu 8.x nichts Relevantes geändert. Im Framework Symphony, welches von Contao für den Manager nutzt, wird jedoch auf die PHP-Version 8 explizit geprüft und unter diese versucht in das Temp-File zu schreiben.
Auf unseren WebServer Paketen ist dies grundsätzlich möglich, da dem Webserver alle Variablen zur Verfügung stehen. Contao macht dies jedoch als CLI-Aufruf, wo diese, ohne Weiteres, nicht zur Verfügung stehen. Beim CLI-Aufruf muss daher entweder das system_tmp_dir per php.ini mitgegeben werden oder im Skript durch den folgenden Befehl vor dem ersten Aufruf:
putenv("TMPDIR=/is/htdocs/...");
Der Tmp-Pfad zu bei Ihrem WebServer ist: /is/htdocs/user_tmp/wpxxxxxxxxxxxxxx/
Hier kopiert der Webserver für Child-Prozesse die von uns schon korrekt gesetzte Variable in die Systemvariable für die CLI. Dies geht leider nur zur Laufzeit und ist auch nur dann gültig.
Unsererseits haben wir keine Möglichkeit das oben beschrieben Verhalten zu ändern, da dies in der Funktionsweise des technischen Aufbaus der Platform mit ModPHP verankert ist.
Grundsätzlich ist es nicht unüblich, dass sich Hostingumgebungen unterscheiden und Webanwendungen gegebenenfalls an diese angepasst werden müssen.
Interessanterweise habe ich es jetzt nochmal versucht, auf einem WebServer Paket Contao 4.13 zu installieren unter PHP 8.0 und es funktioniert problemlos (Stand 19.10.22).
Hey @k63,
hast Du diese PHP.INI Sache angewendet und wenn ja wo und wie genau?
Welches Paket hast Du bei Hosteurope?
Hast Du andere Tipps für uns?
Ich persönlich, bin noch vor ein paar Tagen an der Installation gescheitert - deswegen bin ich sehr an einer Lösung interessiert :-)
Gruß,
Whitedrow
Wenn ich es richtig verstehe dann hat @k63 ein Webserverpaket und kein Shared-Hosting-Paket.
Hallo whitedrow,Zitat:
Zitat von whitedrow
ich habe einen Kunden, der ein einfacheres, ziemlich altes Paket hat (ich glaub er zahlt 9 Euro / Monat).
Hier musste ich die php.ini erstellen und in den Ordner Contao-Manager ablegen. Das ist allerdings etwa 3 Wochen her.
Hier läuft zwar Contao 4.13 - aber nur mit PHP 7.4. Ob ich das jetzt hier auch auf die 8.0 hochziehen kann, habe ich noch nicht getestet.
Jetzt neu habe ich in einem anderen Kundenpaket mit einem WebServer Basic eine Installation mit 4.13 und PHP 7.4 installiert. Im Anschluss habe ich getestet, ob die Installation auch mit PHP 8.0 noch funktioniert.
Bisher gab es keine Probleme, die Seite läuft auch mit PHP 8.0.
Und das ganz ohne die PHP.INI
Genau deshalb habe ich mich ja gewundert, denn bis vor wenigen Wochen war die Auskunft vom Support, dass es ohne die PHP.INI nicht geht.
Ich habe noch so einige Baustellen in dieser Richtung und teste weiter.
Hallo k63,
vielen Dank für Deine Rückmeldung. Mit einem Webserver funktionierte es wohl bislang immer, das Problem sind die Webhosting-Pakete. Und da scheiterte es letzte Woche bei mir auch noch mit PHP 8.0. Dann bleibt der Kundin wohl auch nur ein Umzug, wie ärgerlich.
Herzliche Grüße, Petra
Die Aussagen von Host Europe sind jedenfalls nicht korrekt.
Du kannst die Installation auf PHP8.0 stellen ABER ein Update oder allein das Aufbauen des Systemcaches führt zu dem besagten Fehler.Zitat:
Zitat von k63
Und es geht bei der Problematik um die WebHOSTING Pakete nicht um die WebSERVER Paket.
Aber das würde bedeuten: Meine aktuell jetzt laufenden (mit angepasstem php.ini usw) Seiten mit Contao 4.13.X und PHP 8.1 auf HE (Webhosting) laufen auch weiterhin ohne Probleme - solange ich nichts update (bis zum Umzug....)? Backend funktioniert alles, Artikel können gepflegt werden usw.Zitat:
Zitat von Ainschy
Das funktioniert dann halt genau bis zum nächsten Sicherheitsupdate. "Solange ich nichts update ..." ist ja eher ein hypothetischer Satz, nicht wahr?
Zitat:
Zitat von lucina
Absolut :-)
Aber kostbarer Zeitgewinn bis zum Umzug.
Heute war ja der große Tag der Abschaltung von PHP7.4. Die meisten meiner Kunden hatten im Vorfeld den Provider gewechselt und ein paar Kunden sind geblieben, haben aber den Tarif auf WebServerBasic umgestellt. Dort habe ich alle Installationen getestet, manuell auf PHP 8.1 umgestellt und alle verfügbaren Updates für Contao und verbaute Module eingespielt.....
....tja und dann klingelt heute alle paar Minuten das Telefon und die bei HE gebliebenen Kunden berichten mir, dass es eine Fehlermeldung gäbe. Was ist passiert? HE hat auf PHP 8.0 umgestellt, obwohl es vorher manuell auf 8.1 eingestellt war! Dann passen die Composer-Abhängigkeiten natürlich nicht mehr.
Also X mal für jeden Kunden in das KIS und alles wieder auf PHP 8.1 umgestellt......unfassbar.
Hatte gestern auch einen Kunden, der uns kontaktiert hatte, dass seine Website nicht mehr geht.
Habe von C4.6 zu C4.9 unter 8.0 migriert.
Es ist wichtig, dass man nicht PHP 8.1 vorausgewählt nimmt, sondern 8.0. PHP8.1 war bei mir auch irgendwie kaputt. Mit 8.0 ging es dann auch auf der CLI Ebene. Installation klappte irgendwie ...
Man musste die Symlinks noch per Comandozeile nachreichen, die wurden nämlich nicht erstellt.
Freude hat es trotzdem nicht gemacht.
Selbes Thema auch bei uns. Webserver Basic funktioniert alles prima, Webhosting Pakete machen alle Probleme.
Jetzt werden wir auch von Hosteurope wegziehen. Danke für die guten Jahre, aber jetzt reichts uns auch. :-P
Ich hatte das selbe Problem, seit der Umstellung von HostEurope :mad:
Da bei mir auch das temp-Verzeichnis Probleme machte, hatte ich folgendes bei meinem Kunden gemacht:
- php.ini im contao-manager Verzeichnis angelegt mit dem Pfad zum Tempverzeichnis
Danach erhielt ich beim composer update aber immer noch den Fehler:
Da ich keine ansatzweise funktionierende Lösung gefunden hatte und auch nicht stundenlang für den Bockmist, den HostEurope mal wieder baute, zeit verschwenden wollte, hatte ich mir die XmlFileLoader.php angesehen und die beiden Stellen, wo "sys_temp_dir" aufgerufen wurde, kurzerhand mit einem String des korrekten temp-Verzeichnises ausgetauscht und die Datei wieder hochgeladen.Code:Notice: tempnam(): file created in the system's temporary directory in /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php on line 673
Fatal error: Uncaught ValueError: Path cannot be empty in /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php:683
Siehe da, es funktionierte und ich konnte soweit alles updaten :cool:
Ist zwar jetzt keine schöne Lösung, aber sie funktioniert...
Der nächste Schritt wird nun sein, meine Kunden von HostEurope z.B. zu Strato umzuziehen.
Viele Grüße,
Tobi
Nein, bitte nicht zum Service-Weltmeister. :rolleyes:
Du hast am Markt eine bessere Auswahl als nur Pest oder Cholera...Zitat:
Zitat von Kronos
Warum nicht? Du hast doch selbst Strato im Stresstest :DZitat:
Zitat von tab
Ich habe vor kurzem meine 4.9 LTS in eine 4.13 LTS verwandelt: Null Probleme bisher ...
Weil es von der Performance her wirklich wesentlich bessere Hoster gibt als Strato, ganz besonders wenn es um die Webhostingpakete geht. Zu den Servern kann ich nichts sagen.
Ja, und um das zu merken braucht es keinen Stresstest oder Dauertest. Wenn ich mit exakt der selben Website bei Strato regelmäßig bei Google in puncto Pagespeed um einige Punkte schlechter bewertet werde als anderswo, egal wie oft ich den Test starte, dann heißt das eben, dass die Performance bei Strato schlechter ist. Ich sage ja nicht, dass sie unbrauchbar und unterirdisch ist, immerhin vergleiche ich mit einigen der m.E. performantesten Webhostingpakete im selben Preisbereich. Dazu kommen hier im Forum auch Berichte, dass es zeitweise Probleme bei Installationen und Updates mit dem Contao-Manager kommt. Du schreibst, in der Konsole funktioniert es und ist schnell. Ok, damit könnte ich notfalls leben und bei mir sind die Probleme mit dem Contao-Manager bisher auch nicht aufgetreten. Potenzielle Kunden, die im Strato Shared Webhosting gehostet werden wollen werde ich also nicht deswegen ablehnen, sondern sie lediglich vorab auf die möglichen Nachteile ansprechen und abklären, ob andere Dinge, wie die kostenpflichtigen Zertifikate für Subdomains, im Einzelfall überhaupt relevant sind. Bei Host Europe sieht das Ganze sicher deutlich schlechter aus, das würde ich definitiv momentan ablehnen.Zitat:
Zitat von mlweb
Die Berichte, die ich von Strato Servern so höre in puncto Performance, verheißen leider auch nicht viel Gutes in dieser Richtung. Keine Ahnung, was die mit dem Geld machen, das sie eigentlich in Hard- und Software stecken sollten. Oder machen die etwa Fernsehwerbung? :D