HostEurope: Unable to write to the temporary system directory

[tab]

Also wenn ich dort (HE) Kunde wäre, dann müsste ich gar nicht kündigen, da würde mir HE wahrscheinlich zuvorkommen.

[goisko]

Ich habe vor ein zwei Wochen eine 4.13.x Installation bei HE aufgesetzt, das hat mit der php.ini Lösung und PHP 7.4 funktioniert. Mit PHP 8.0 ging das nicht. Jetzt trudeln gerade Mails von HE ein, dass im November PHP 7.4 abgeschaltet wird. Ich habe - da diese Website noch nicht online ist - im KIS auf PHP 8.0 umgestellt und das hat tatsächlich funktioniert. Frontend, Backend und CM lassen sich aufrufen.

Vielleicht möchte jemand mal diesen Weg ausprobieren und Bescheid geben, ob es auf diesem Weg tatsächlich funktionieren kann?

Und zweite Frage: Gibt es neuere Antworten vom HE-Support, ob sich das Problem von HE-Seite aus lösen lässt?

VG
Caro

Hallo Caro,

ja dieser Weg funktioniert. php.ini und Installation auf 7.4. Und dann über KIS auf 8.0. Allerdings kann ich dann nicht mehr fehlerfrei den contao-manager aufrufen. Bei mir. Gibt es bei Dir Neuigkeiten bzgl. HE mit Contao 4.13 UND PHP 8.0/1 (8.0 wird ja noch länger supported).

Lieben Gruß!

[Caro]

ja dieser Weg funktioniert. php.ini und Installation auf 7.4. Und dann über KIS auf 8.0. Allerdings kann ich dann nicht mehr fehlerfrei den contao-manager aufrufen. Bei mir. Gibt es bei Dir Neuigkeiten bzgl. HE mit Contao 4.13 UND PHP 8.0/1 (8.0 wird ja noch länger supported).

Vielen Dank fürs Bescheid geben. Ich konnte und kann den CM aufrufen.

Habe aber gerade eine Update von 4.13.6 auf 4.13.8 machen wollen mittels „alle Pakete aktualisieren". Aber die Installation bleibt hängen mit:
Fatal error: Uncaught ValueError: Path cannot be empty in ...

Jetzt bin ich froh, dass die Website wieder läuft, nachdem die kurzfristig futsch war.

Also leider ist dieser Umweg keine Dauerlösung.

LG
Caro

[goisko]

Vielen Dank fürs Bescheid geben. Ich konnte und kann den CM aufrufen.

Habe aber gerade eine Update von 4.13.6 auf 4.13.8 machen wollen mittels „alle Pakete aktualisieren". Aber die Installation bleibt hängen mit:
Fatal error: Uncaught ValueError: Path cannot be empty in ...

Jetzt bin ich froh, dass die Website wieder läuft, nachdem die kurzfristig futsch war.

Also leider ist dieser Umweg keine Dauerlösung.

LG
Caro

Ja absolut keine Dauerlösung. Aber wenn man nur Front- und Backend nutzt dürfte ja nichts passieren. Werde eine zweite Arbeitsinstallation einrichten. Und über diese regelmäßig testen ob Updates über den Manager laufen und was bei Abbruch mit der Seite passiert. Und hoffen dass diese path Fehlermeldung bald behoben wird.

Lieben Gruß!

[Caro]

Ja absolut keine Dauerlösung. Aber wenn man nur Front- und Backend nutzt dürfte ja nichts passieren. Werde eine zweite Arbeitsinstallation einrichten. Und über diese regelmäßig testen ob Updates über den Manager laufen und was bei Abbruch mit der Seite passiert. Und hoffen dass diese path Fehlermeldung bald behoben wird.

Ich glaube nicht mehr, dass sich daran etwas ändert wird. Aber falls jemand etwas mitbekommt, wäre es nett, wenn ihr das hier postet.
LG

[Truller500]

PHP Kommandozeilen-Programm
Unable to write to the temporary system directory.
This is most likely a problem with your hosting configuration. Make sure that either open_basedir does allow access to the temporary directory or that the sys_temp_dir is correctly configured.



Gibt es denn die Möglichkeit das anzupassen? ...der Servicemann von Host Europe meinte das wäre so.

Ich weiß nur nicht, wie und wo ich diese Anpassung vornehmen soll...

[Truller500]

Moin nochmal,
habe es gemacht wie Caro - php.ini und Installation auf 7.4. - dann über KIS auf 8.0. Läuft.
Vor einem Update graust es mir...

[tab]

Moin nochmal,
habe es gemacht wie Caro - php.ini und Installation auf 7.4. - dann über KIS auf 8.0. Läuft.
Vor einem Update graust es mir...

Vor allem wenn es dann bald bei HE gar kein PHP 7.4 mehr gibt . Dann ist der Workaround wohl, "woanders" (z.B. lokal) das Update zu machen, eventuell mit ein paar passenden "platform" Einstellungen in der composer.json. Dann das Ergebnis zu HE zu transferieren und zu hoffen, dass es dann da läuft. Was durchaus nicht garantiert ist.

[Franko]

Moin nochmal,
habe es gemacht wie Caro - php.ini und Installation auf 7.4. - dann über KIS auf 8.0. Läuft.
Vor einem Update graust es mir...

Hm, und die Paket Aktualisierung läuft anschließend bei dir durch?

[Truller500]

Die Paketaktualisierung habe ich natürlich vermieden… wollte die funktionierende Installation nicht gleich wieder kaputt machen.
Ich muss bei Host Europe noch eine weitere Aktualisierung von Contao 3.5 auf Contao 4 durchführen. Die Site ist sehr umfangreich. Fazit: Ich werde den Umzug zu einem anderem Provider vorschlagen – alles andere wäre nicht sinnvoll. Ich glaube nicht, dass sich in näherer Zukunft bei Host Europe etwas ändert.

[Mark Knochen]

Die Paketaktualisierung habe ich natürlich vermieden… wollte die funktionierende Installation nicht gleich wieder kaputt machen.
Ich muss bei Host Europe noch eine weitere Aktualisierung von Contao 3.5 auf Contao 4 durchführen. Die Site ist sehr umfangreich. Fazit: Ich werde den Umzug zu einem anderem Provider vorschlagen – alles andere wäre nicht sinnvoll. Ich glaube nicht, dass sich in näherer Zukunft bei Host Europe etwas ändert.

Ich hatte gestern mal bei einem HE-Hosting Contao 4.13 auf PHP 7.4. installiert - das ging.
Umstellung auf PHP 8 geht mit dem Aufruf von Frontend und Backend auch
Im ContaoManager dann Pakete aktualisieren versucht - da knallt es dann und die Aktualisieurung schlägt fehl.

Ist eine blöde Situation und absolut unsinnig, dass Contao-User mit Hosting Paketen bei HE jetzt alle auf einen Server wechseln müssen.

[lucina]

¯\_(?)_/¯

[tab]

Ich hatte gestern mal bei einem HE-Hosting Contao 4.13 auf PHP 7.4. installiert - das ging.
Umstellung auf PHP 8 geht mit dem Aufruf von Frontend und Backend auch
Im ContaoManager dann Pakete aktualisieren versucht - da knallt es dann und die Aktualisieurung schlägt fehl.

Ist eine blöde Situation und absolut unsinnig, dass Contao-User mit Hosting Paketen bei HE jetzt alle auf einen Server wechseln müssen.

Niemand muss auf einen Server wechseln. Erstens sind eh schon alle auf einem Server, auch wenn es ein Shared Webosting Server ist . Zweitens gibt es genügend andere Shared Webhostings auf dem Globus, die solche Probleme nicht haben und allemal günstiger sind als ein vServer bei HE. Der Aufwand für den Umzug der Mailaccounts - sofern man das überhaupt tun will - wird sich wohl auch nicht gross unterscheiden. Oder bietet HE da einen Service an, beim Kunden alle Mailclient-Einstellungen zu ändern, oder haben die einen zentralen IMAP Server, auf dem alle Mails gespeichert sind und der sich beim Umzug aus dem Shared Hosting auf den Server nicht ändert?

[mlweb]

Ist eine blöde Situation und absolut unsinnig, dass Contao-User mit Hosting Paketen bei HE jetzt alle auf einen Server wechseln müssen.

Wenn schon dieser Satz, dann muss der m.E. an die Adresse von HE gehen.
Die Contao Core-Entwickler haben zunächst einen Workaround gefunden um die Fehler (zu mindestens sind es nach meinem bisherigen Verständnis solche) in der Serverkonfiguration von Hosteurope zu umgehen. Statt sich mit den Problemen zu befassen hat sich HE aber ausgeruht und schiebt auch jetzt, wo das Workaround nicht mehr greift wieder den "schwarzen Peter" zu Contao.

Es kann für mich eigentlich nicht sein, dass ein Provider hier versucht etwas als richtig und unvermeidbar zu erklären, was offenbar alle anderen Hoster anders handhaben.

Die einzige Antwort an HE ist m.E. ein Hosterwechsel.

[Mark Knochen]

Wenn schon dieser Satz, dann muss der m.E. an die Adresse von HE gehen.
Die Contao Core-Entwickler haben zunächst einen Workaround gefunden um die Fehler (zu mindestens sind es nach meinem bisherigen Verständnis solche) in der Serverkonfiguration von Hosteurope zu umgehen. Statt sich mit den Problemen zu befassen hat sich HE aber ausgeruht und schiebt auch jetzt, wo das Workaround nicht mehr greift wieder den "schwarzen Peter" zu Contao.

Es kann für mich eigentlich nicht sein, dass ein Provider hier versucht etwas als richtig und unvermeidbar zu erklären, was offenbar alle anderen Hoster anders handhaben.

Die einzige Antwort an HE ist m.E. ein Hosterwechsel.

Dann war das falsch verstanden worden, die Kritik ging ausschliesslich an die Adresse von Host Europe.
Was den Mailumzug angeht - es gibt auch Hoster, die relativ automatisert alle Email-Konten migrieren, dass das auch manuell geht ist klar, ist nur eine sehr nervige Angelegenheit.

[lucina]

Was den Mailumzug angeht - es gibt auch Hoster, die relativ automatisert alle Email-Konten migrieren, dass das auch manuell geht ist klar, ist nur eine sehr nervige Angelegenheit.

Das muss nicht nervig sein: https://imapsync.lamiral.info/

Adressen aus Liste exportieren -> an Batchfile verfüttern -> Magic.

[nicknack]

Ich habe eben nochmal einen Chat mit einem Hosteurope-Mitarbeiter gehabt, das war seine einzige Lösung:

"Also das geht schon, jedoch erst ab einem Webserver. Sie nutzen unser aktuell kleinstes Paket und da ist das tatsächlich nicht möglich. Sie können Ihr aktuelles Paket gerne in einen Webserver wechseln. Das würde funktionieren. Hier finden Sie eine Übersicht der Pakete:

https://www.hosteurope.de/WebServer/"

Ich werde nun auch alle Seiten zu einem neuen Provider umziehen müssen.
Wer also Contao bei Hosteurope installieren will braucht mindestens Webserver für 19,99. Dafür hat man dann aber sagenhafte 100 GB Webspace, die so viele Kunden brauchen...

[tab]

Das erinnert mich fatal an das Ende meiner Zeit bei 1&1. Da wurde mir auch gesagt, dass ich einen vServer nehmen solle, da wäre das alles kein Problem, aber im Shared Webhosting geht das nicht. Ich bin damals dann zu Webgo gegangen, wo das, was ich gebraucht habe, im Shared Webhosting alles ganz problemlos ging.

Heute hat man ja reichlich Auswahl, mittlerweile auch wieder 1&1 und sogar Strato. Alle können das im Shared Webhosting. Außer HE eben. Wenn du wenig Webspace brauchst, ist Hostingwerk "All In" sicher eine gute Adresse. Sehr einfach zu bedienen, da kein großer Schnickschnack, den keiner braucht. Und sehr flott. Oder auch All-Inkl, je nach Webhosting-Server auch Webgo, sogar netcup als Billiganbieter kann das. Was bei HE unter 19,99€ nicht funktioniert, geht in meinem 50 Cent Webhosting dort problemlos. Ich kann mir echt nur vorstellen, die versuchen dort, Contao loszuwerden. Warum auch immer, vielleicht weil diese Kunden immer so absurde Ansprüche stellen.

[mlweb]

Ich kann mir echt nur vorstellen, die versuchen dort, Contao loszuwerden.

Das kann ich mir nun eher nicht vorstellen. Das wäre ja zielgerichtetes handeln.
Ich denke es ist viel banaler.
Man macht es so, weil man es schon immer so gemacht hat. Ich glaube sogar, das sich die Erklärungen niemand wirklich genau angeschaut hat. Es interessiert einfach niemanden wirklich.

Wie heißt es doch so schön - Kunden stören das Geschäft.

[tab]

Wahrscheinlich ist der letzte kompetente Mitarbeiter, der das Problemchen in 5 Minuten behoben hätte, mittlerweile von der Konkurrenz abgeworben worden. Ist ja auch nicht so, dass die das schon immer so gemacht hätten. Bei den älteren PHP-Versionen konnten sie es ja noch. Da ging es komischerweise auch noch im Shared Webhosting. Also ist vielleicht auch PHP 8 schuld! Dann ist ja alles gut, Hauptsache man ist nicht selbst dran schuld, jetzt dürfen sich Contao und PHP 8 drum streiten, wer Schuld hat.

Je mehr ich von dem Laden höre, desto mehr bin ich froh, dort kein Kunde zu sein und auch keine Kunden dort zu haben.

[tblumrich]

Hallo,
also ich hab jetzt hier eine Kundeninstallation von 4.4 auf 4.13 gebracht (eigentlich nur zur Übernahme der Struktur, weil die Seite eh komplett relauncht wird).
Das ganze auf Hosteurope, kein Server, noch so ein altes Shared-Hosting-Paket, die es vor den Webpacks gab. Die PHP.ini brauchte ich natürlich auch.
Nach den Updates und dem Aufräumen der Altlasten (Backup) hab ich einfach mal auf PHP 8.0 gestellt um zu sehen was passiert.

Kann es sein, das sich das nur oder eher auf PHP 8.1 bezieht? Der Manager läuft eigentlich... installieren, updates... geht.
Wobei das einzige was auffällt, das bei Installationen generell kein Datenbankupdate angeboten wird. Ich muss immer erst manuell den Prod. - Cache erneuern, dann zeigt der Manager an, das da was zu tun ist.

Kann das damit zu tun haben? Oder, wenn nicht, was kann das sein?

[rusty]

sorry, nicht zuende gelesen

[zonky]

Ich werde nun auch alle Seiten zu einem neuen Provider umziehen müssen.

Jo, ich bin durch... die letzten bei HE verbliebenen Kunden sind umgezogen.. bb HE

[mlweb]

Ich habe gerade bei einem Neukunden abgelehnt, seine Installation auch nur genauer anzuschauen bevor er nicht die Entscheidung trifft umzuziehen.

Da kam die Aussage: "Wir waren schon immer bei HE und da gab es nie Probleme."

"Jetzt gibt es aber ein Problem. Deswegen haben Sie sich ja an mich gewendet" war meine einzige Antwort.

[zonky]

Da kam die Aussage: "Wir waren schon immer bei HE und da gab es nie Probleme."

können ja bei HE bleiben - aber dann auf einem der Serverpakete...

[MrLumbergh]

Legt Euch im /web Verzeichnis eine temp.php an und kopiert folgenden Inhalt rein:

<?php
// Create a temporary file in the temporary 
// files directory using sys_get_temp_dir()
$temp_file = tempnam(sys_get_temp_dir(), 'Tux');

echo $temp_file;
?>

Dann ruft ihr die Datei im Browser auf.
Dort steht dann sowas in der Art:

/is/htdocs/user_tmp/wp12345678_KTPMS1UVKH/TuxRlIO94

Davon ist der letzte Teil nicht zu kopieren. Also nur:

/is/htdocs/user_tmp/wp12345678_KTPMS1UVKH

Dann geht ihr in das contao-manager Verzeichnis und legt eine php.ini an.
Dort schreibt Ihr dann dies rein:

open_basedir = none
sys_temp_dir = /is/htdocs/user_tmp/wp12345678_KTPMS1UVKH
allow_url_fopen = 1 

Nun läuft der Contao Manager durch!

[mlweb]

Auch unter PHP 8 bzw. 8.1?

[MrLumbergh]

Auch unter PHP 8 bzw. 8.1?

Gute Frage. Ist bei uns auf dem Server noch nicht eingerichtet.

[jst]

Guten morgen zusammen

hab div. Paketgrössen bei HE, habs gestern auf einem der kleinen Pakete (web basic) gemacht und danach auf PHP 8.1.11 umgestellt, bei mir läufts, auf den grossen wie schon erwähnt gings eh.

c_manager_1.61_php8.1.11.jpg

[jst]

Ich will HE hier nicht in Schutz nehmen, im Gegenteil, so was nervt mich auch total, aber es nutzt wenig wenn wir hier nur Provider-bashing machen, nutzbare Lösungen sind doch viel wichtiger.

Denke man kann davon ausgehen, das die bei HE dann doch nicht alle auf den Kopf gefallen sind oder Contao hater sind etc, sondern das es aus deren Sicht scheinbar Gründe dafür gibt das es ist wie es ist, deren Hintergründe wir nicht alle kennen. Und Contao macht ja auch nicht alles 1000% nach allen Regeln und Vorgaben richtig. Ich finde Contao grossartig, aber im Laufe der Jahre hab ich auch schon ordentlich viele Probleme bishin zu totalen Verzeifelung damit gehabt

Es wurde schon gesagt das es den "einen" Provider nicht geben kann, weil jeder unterschiedliche Ansprüche hat und das das Setting in das passen muss sehr unterschiedlich ist. Da draußen gibts so viele grottige Backends, zu wenig Plattenplatz, zu wenige Datenbanken, kein externe Zugriffe auf die DBs, Email oder FTP-Einschränkungen, keine Jahresrechnungen, keine .ini, keine .htaccess,.. etc pp., die Liste ist lang.

Dazu kommt, das mal eben "schnell kündigen und umziehen" sicher eben für viele keine Lösung ist, in unserem Fall aufgrund reinen der Anzahl der Pakete sicher einen grösseren 4-stelligen Betrag an Arbeitskosten genieren würde.

Da stellt sich für mich dann die Frage, ob dann so ein Workaround via php.ini das wichtigste Kriterium für die Providerauswahl ist, mit dem Wissen das bei dem neuen Anbieter auch neue Probleme lauern. Niemand wird garantieren, das bei Provider XYZ nächstes Jahr nicht anderes klemmt.

Ich fände es besser statt der im Prinzip doch recht ergebnislosen Grundsatzdiskussionen (denen ich ja im Kern voll zustimme), lieber auf pragmatische Lösungen zu setzen, so das man diese und kommende Probleme weiterhin (gerne auch mit Handarbeit) in den Griff bekommt, ohne das man gleich alles abreissen und neu machen muss, nur weil ein Parameter nicht richtig gesetzt ist.

vG
Jörg

[Ainschy]

Guten morgen zusammen

hab div. Paketgrössen bei HE, habs gestern auf einem der kleinen Pakete (web basic) gemacht und danach auf PHP 8.1.11 umgestellt, bei mir läufts, auf den grossen wie schon erwähnt gings eh.

c_manager_1.61_php8.1.11.jpg

Und schon mal versucht den Systemcache neu aufzubauen oder ein Update zu fahren? ... an der Stelle knallts in der Regel nach er Umstellung auf PHP8.X

[jst]

oha.. jap. Mist. Zu früh gefreut.

In ScriptHandler.php line 97: An error occurred while executing the "contao:install-web-dir" command:
...
# Process terminated with exit code 1
# Result: General error

Hatte kein gestern mehr Update gemacht nach der Umstellung, weil ich da schon auf 4.9.35 war

Dank für den Hinweis

[mlweb]

Gute Frage. Ist bei uns auf dem Server noch nicht eingerichtet.

Um die Server-Pakete ging es nicht, soweit ich mitgelesen habe. Das Problem sind die Webhostingpakete bei denen es mit PHP 7 noch Workarounds gab, die aber mit PHP 8.1 nicht mehr funktionieren.
Da gibt es nur die Möglichkeit HE mit Webserver-Paket oder Umzug zu einem anderen Provider.

[jst]

abgesehen davon das man sowas in der Regel nat. nie nicht niemals machen sollte, weil unsauber, was spräche dagegen als quick+dirty fix für den Moment dem Scripthandler.php an der Stelle den fehlenden Pfad händisch mitzugeben? Ist das nur diese Funktion "private static function getBinDir(Event $event)" in Zeile 91-99 die da ein Problem hat? Oder kommt dananch dann noch mehr hinterher? Welche Rückgabewert wird da erwartet? Habs mir noch nicht so genau angeschaut (bin auch nicht der ober-php-crack).
Wechseln kann man dann ja noch immer, die Umstellung auf PHP 8.1 kommt nächste Woche.

[Spooky]

Also wenn dann müsste man

putenv("TMPDIR=/is/htdocs/user_tmp/wp…"); 

oder

@ini_set('sys_temp_dir', '/is/htdocs/user_tmp/wp…'); 

vermutlich in folgende Dateien schreiben:

• public/index.php
• vendor/contao/contao/manager-bundle/bin/contao-setup

[dan-com]

Hallo zusammen,
ich habe nach der Umstellung auf PHP 8.0 und dem Fix

open_basedir = none
sys_temp_dir=/is/htdocs/user_tmp/wpxxx
allow_url_fopen = 1

folgendes Problem:
Contao_Systemwiederherstellung.JPG

Wenn ich dann "Reparatur ausführen" klicke, wird dieser Fehler geworfen:

$ /usr/bin/php8.0 -q -c /is/htdocs/wpxxx_xxx/www/xxx/manager1/web/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -ddisplay_errors=0 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wpxxx_xxx/www/xxx.de/manager1/web/web/contao-manager.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader
The "contao-components/installer" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.2.0"). You may need to run composer update with the "--no-plugins" option.
The "contao/manager-plugin" plugin was skipped because it requires a Plugin API version ("^1.1") that does not match your Composer installation ("2.2.0"). You may need to run composer update with the "--no-plugins" option.
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Your lock file does not contain a compatible set of packages. Please run composer update.
  Problem 1
    - contao-components/installer is locked to version 1.2.7 and an update of this package was not requested.
    - contao-components/installer 1.2.7 requires composer-plugin-api ^1.0 -> found composer-plugin-api[2.2.0] but it does not match the constraint.
  Problem 2
    - contao/manager-plugin is locked to version 2.4.1 and an update of this package was not requested.
    - contao/manager-plugin 2.4.1 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.2.0] but it does not match the constraint.
  Problem 3
    - lib-xsl is present at version 1.1.28.0 and cannot be modified by Composer
    - Only one of these can be installed: lib-libxslt[1.1.32], lib-xsl[1.1.28.0]. lib-libxslt replaces lib-xsl and thus cannot coexist with it.
    - lib-libxslt is present at version 1.1.32 and cannot be modified by Composer
# Process terminated with exit code 2
# Result: Misuse of shell builtins

Wäre super, wenn jemand weiterhelfen könne

Jetzt bin ich doch selbst auf die Lösung gekommen:
PHP Version von 8.0 zurück auf 7.4 gesetzt, Composer Update durchgeführt, jetzt läuft alles auf PHP 8.1

[jst]

danke für deinen Tip. Hilft leider nicht.

Also wenn dann müsste man

putenv("TMPDIR=/is/htdocs/user_tmp/wp…"); 

oder

@ini_set('sys_temp_dir', '/is/htdocs/user_tmp/wp…'); 

vermutlich in folgende Dateien schreiben:

• public/index.php
• vendor/contao/contao/manager-bundle/bin/contao-setup

in public/index.php hat es leider keinen Effekt (ist bei mir noch /web) , in vendor/contao/manager-bundle/bin/ gibt es kein contao-setup, nur contao-console & contao-api, habs mal testweise in letzeres geschrieben, ohne Auswirkungen

[Spooky]

Meine Anweisung gilt nur für Contao 4.13. Für 4.9 müsste man das vermutlich auch noch am Anfang von Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication setzen.

[jst]

ah.. das ist der Weg. Update geht ja so nicht wg dem Fehler unter PHP8.

Erst auf PHP 7.x zurück, dann das Contao Update von 4.9 auf 4.13 und dann wieder auf PHP 8.x.. wird sofort gestestet.

Danke

[jst]

ich hab das HE-Paket auf PHP 7.4 zurückgestellt (geht zzt ja noch), dann das Contao-Update von 4.9 auf 4.13.12 gemacht.

Danach in vendor/contao/contao/manager-bundle/bin/contao-setup

@ini_set('sys_temp_dir', '/is/htdocs/user_tmp/wp…'); 

gesetzt. Und siehe da es geht. inkl. Cache leeren etc. Super. Vielen Dank für den Support!!