Contao 4.x und PHP 8.x bei Host Europe

Hallo Contao-Gemeinde,

Host Europe hat angekündigt, dass PHP 7.4 am 14.11.22 abgeschaltet wird. Ich mal anhand meiner Webseite getestet, ob die manuelle Umstellung irgendwelche Probleme verursacht. JA und zwar massiv!

Egal was ich mit dem Contao-Manager (1.6.0) machen will:
- Pakete desintallieren
- Pakete installieren
- Composer-Update durchführen

es endet immer in dieser Fehlermeldung:

@php vendor/bin/contao-setup
Script @php vendor/bin/contao-setup handling the post-install-cmd event returned with error code 255

Dann habe ich das mal bei 10 Kundenwebseiten geprüft (unterschiedliche Contao Versionen 4.4x, 4.9.x, 4.13.x), die ebenfalls bei Host Europe sind. Überall mit dem gleichen Ergebnis.

Ich habe den HE-Support dazu angeschrieben und warte noch auf eine Antwort.

Kann mir jemand sagen, was es mit dieser Fehlermeldung auf sich hat? Hat jemand die gleichen Erfahrungen gemacht und evtl. schon einen Lösungsansatz?

Danke und LG
Oliver

Der Lösungsansatz des HostEurope Supports ist: Umstieg auf einen Server Tarif.
Mein Lösungsansatz wäre ein anderer, der HostEurope eventuell nicht ganz so gut gefällt wie ihr eigener.
Gerade habe ich Contao 4.13.8 mit PHP 8.1 über den Contao-Manager auf meinem Billigsthosting (6,-€ - pro Jahr) installiert, was man mittlerweile leider nicht mehr neu bestellen kann.
Meine Schlussfolgerung, frei nach Loriot: Ein Leben ohne HostEurope ist möglich - und eventuell sogar sinnvoll! :D;)

Edit: Gerade eben habe ich mal ein Update auf 5.0.1 gemacht, absolut problemlos!

Zitat:

---

Zitat von ollikoeln

Ich habe den HE-Support dazu angeschrieben und warte noch auf eine Antwort.

---

Denke ich kenne die Antwort - s.a.: https://community.contao.org/de/show...l=1#post562287

Werde für meinen Kunden den Hoster wechseln.

Das war ja schon bei dem Problem mit dem sys_temp_dir so....Schuld ist natürlicht nicht HE. Immerhin gab es DAFÜR einen workaround.

Ich habe es bei div. anderen Providern ausprobiert...nirgendwo anders gibt es Probleme mit PHP 8.x.

Nur um das Bild mal zuvervollständigen, ohne Herumgejammer, ohne Wunsch nach Hilfestellung aus dem Forum: Auf meinem älteren Webserver Basic klappt das alles ohne Verrenkungen solange ich PHP 8.0 einstelle. Mit 8.1 startet noch nicht einmal der Manager, weil er sein PHP-CLI nicht mehr findet.

Der Support meint, ich solle mich an den Hersteller des Scriptes wenden. Die einzige Richtung, in die ich mich wenden werde ist: ab.

Wir hatten jahrelang unseren Kunden HE empfohlen, waren dort auch selbst Kunde. Seit die damals von GoDaddy geschluckt wurden ging es massiv abwärts. Seitdem sind wir selbst und ein Großteil unserer Kunden zu all-inkl und es gab ne wieder Probleme :cool:

Sehe ich genauso wie BennyBorn
Vor 10 Jahren war der Service vorbildlich - jetzt gibt es zu viele Probleme. Ich rate ab jetzt auch zum Providerwechsel.

Roland

Der HE Support besteht auf den PHP.ini Eintrag.

So weit so gut für den Webprozess ...

Jedoch wird beim Composer Update (über den Manager) der CLI Prozess gestartet und dieser kennt die Angabe aus der PHP.ini nicht.
Folglich misslingt das Update.

Das tückische daran ist das Symfony erst ab PHP8 eine Funktion aufruft die auf mittels PHP Funktion sys_get_temp_dir() das TMP Verzeichnis holt um dort eine Datei anzulegen. Das fehlschlägt das der Rückgabewert null ist.

Wenn HE das nicht fixed, wird es sehr vielen beim nächsten Update unter PHP8 um die Ohren fliegen.

Ergänzung:
Es geht um diesen Symfony Part: https://github.com/symfony/dependenc....php#L661-L688

Das temporäre Verzeichnis irgendwie als Parameter des PHP Aufrufs zu setzen (-d...) hat schon jemand versucht?

Zitat:

---

Zitat von tab

Das temporäre Verzeichnis irgendwie als Parameter des PHP Aufrufs zu setzen (-d...) hat schon jemand versucht?

---

Das Problem ist nicht der Aufruf vom Manager, der zieht die php.ini und läuft. Das Problem entsteht wenn der ScriptHandler aus dem ManagerBundle aufgerufen wird.

Code:

---

$ /usr/bin/php8.0 -q -c /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/web/cm.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader

Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Package patchwork/utf8 is abandoned, you should avoid using it. Use symfony/polyfill-mbstring or symfony/string instead.
Package swiftmailer/swiftmailer is abandoned, you should avoid using it. Use symfony/mailer instead.
Package symfony/debug is abandoned, you should avoid using it. Use symfony/error-handler instead.
Package symfony/swiftmailer-bundle is abandoned, you should avoid using it. Use symfony/mailer instead.
Package true/punycode is abandoned, you should avoid using it. No replacement was suggested.
Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
Generating optimized autoload files
composer/package-versions-deprecated: Generating version class...
composer/package-versions-deprecated: ...done generating version class
contao/manager-plugin: Dumping generated plugins file...
contao/manager-plugin: ...done dumping generated plugins file
Class Contao\ManagerPlugin\PluginLoader located in ./vendor/contao/manager-plugin/src/Resources/PluginLoader.php does not comply with psr-4 autoloading standard. Skipping.
104 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication


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
Stack trace:
#0 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php(683): file_put_contents('', 'shouldEnableEntityLoader()
#2 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/config/Util/XmlUtils.php(89): Symfony\Component\DependencyInjection\Loader\XmlFileLoader->validateSchema(Object(DOMDocument), false)
#3 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/config/Util/XmlUtils.php(146): Symfony\Component\Config\Util\XmlUtils::parse('parseFileToDOM('/is/htdocs/wp10...')
#6 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/swiftmailer-bundle/DependencyInjection/SwiftmailerExtension.php(50): Symfony\Component\DependencyInjection\Loader\XmlFileLoader->load('swiftmailer.xml')
#7 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Compiler/MergeExtensionConfigurationPass.php(76): Symfony\Bundle\SwiftmailerBundle\DependencyInjection\SwiftmailerExtension->load(Array, Object(Symfony\Component\DependencyInjection\Compiler\MergeExtensionConfigurationContainerBuilder))
#8 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/http-kernel/DependencyInjection/MergeExtensionConfigurationPass.php(39): Symfony\Component\DependencyInjection\Compiler\MergeExtensionConfigurationPass->process(Object(Contao\ManagerPlugin\Config\ContainerBuilder))
#9 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Compiler/Compiler.php(94): Symfony\Component\HttpKernel\DependencyInjection\MergeExtensionConfigurationPass->process(Object(Contao\ManagerPlugin\Config\ContainerBuilder))
#10 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/ContainerBuilder.php(762): Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object(Contao\ManagerPlugin\Config\ContainerBuilder))
#11 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/http-kernel/Kernel.php(594): Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#12 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/contao/manager-bundle/src/HttpKernel/ContaoKernel.php(326): Symfony\Component\HttpKernel\Kernel->initializeContainer()
#13 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/http-kernel/Kernel.php(136): Contao\ManagerBundle\HttpKernel\ContaoKernel->initializeContainer()
#14 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/framework-bundle/Console/Application.php(169): Symfony\Component\HttpKernel\Kernel->boot()
#15 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/framework-bundle/Console/Application.php(75): Symfony\Bundle\FrameworkBundle\Console\Application->registerCommands()
#16 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/console/Application.php(149): Symfony\Bundle\FrameworkBundle\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/contao/manager-bundle/bin/contao-console(38): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput))
#18 {main}
  thrown in /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php on line 683
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-install-cmd event terminated with an exception


In ScriptHandler.php line 97:
                                                                         
  An error occurred while executing the "contao:install-web-dir" command: 
                                                                         


install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [...]




# Process terminated with exit code 1
# Result: General error

---

Exakt das habe ich denen auch schon zu erklären versucht.

Vielleicht machen wir da mal was offizielles? Wenn Du da als User:in eine Beschwerde schreibst, dann ist denen das vollkommen egal.

sys_get_temp_dir() wird sicher viel öfter gebraucht, nicht nur in einer Funktion und nicht nur unter PHP 8.

Zitat:

---

Zitat von Spooky

sys_get_temp_dir() wird sicher viel öfter gebraucht, nicht nur in einer Funktion und nicht nur unter PHP 8.

---

Das Problem mit

PHP-Code:

---

sys_get_temp_dir() 


---

existiert bei HE nur in der CLI Version.

Mich dünkt die Annahme das diese Beschränkung einfach gewollt ist und HE sich nicht darum kümmern will. Wenn sich nichts ändert fliegt dem Support im November der Mist gehörig um die Ohren.

Also "gewollt" kann ich mir nicht vorstellen. Schon deswegen, weil klar ist, dass denen das um die Ohren fliegen wird. Und auch deswegen, weil es mit den "alten" PHP Versionen ja funktioniert. Eher denke ich, dass auf dem bisher erreichten Level des Support das notwendige Wissen fehlt um zu begreifen, worum es überhaupt geht.

Das sys_get_temp_dir sollte sich auch über die Umgebungsvariable TMPDIR setzen lassen, folgender Aufruf sollte /foo/bar ausgeben:

Code:

---

TMPDIR=/foo/bar php -r 'echo sys_get_temp_dir();'

---

Wenn jemand testen könnte ob das das problem behebt könnte man so etwas eventuell in den Manager einbauen.

Code:

---

$ TMPDIR=/is/htdocs/user_tmp/wp12345678_XXXXXXXXXXXX /usr/bin/php8.0 -q -c /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/web/cm.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader

---

Zitat:

---

Zitat von ausi

...
Wenn jemand testen könnte ob das das problem behebt könnte man so etwas eventuell in den Manager einbauen.

Code:

---

$ TMPDIR=/is/htdocs/user_tmp/wp12345678_XXXXXXXXXXXX /usr/bin/php8.0 -q -c /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/web/cm.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader

---

---

Mein Problem ist das der gesamte Aufruf eine weiße Seite liefert. -i geht, mehr wird scheinbar nicht akzeptiert. Ggf. kann ein anderen HE Kunde das testen. TMP-Pfad und CM-Dateiname sind anzupassen.

Die sollen das doch einfach fixen, kann ja nicht so schwer sein!? (Ja, ich weiss, gute, 20-Jährige Minijobber mit 30 Jahren Berufserfahrung sind schwer zu bekommen). Oder, alternativ, wenn sie unbedingt wollen, dann halt mit dem Kopf gegen die Wand laufen. Vielleicht führt der Schmerz ja irgendwann zur Erleuchtung.

Zitat:

---

Zitat von Ainschy

Mein Problem ist das der gesamte Aufruf eine weiße Seite liefert.

---

Wie meinst du das? Das ist ja ein Konsolenbefehl.

Da es bei dem Hosting-Paket keinen SSH-Zugang gibt, rufe ich den CLI Prozess mittels URL auf.

PHP-Code:

---

<?php 
echo "<pre>";
passthru('TMPDIR=/is/htdocs/user_tmp/wp12345678_XXXXXXXX /usr/bin/php8.0 -q -c /is/htdocs/wp12345678_XXXXXXXX/www/contao4/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wp12345678_XXXXXXXX/www/contao4/web/cm.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader');
echo "</pre>";

---

Das wird nicht gut funktionieren. Ohne SSH Zugang wirst du hier wohl keine Chance haben.

Zitat:

---

Zitat von Spooky

... Ohne SSH Zugang wirst du hier wohl keine Chance haben.

---

Da hast du absolut Recht. Ohne SSH würde ich heute kein Projekt mehr starten. Problem hier sind die alten Kunden die nun vor dem Problem stehen das ihre Contao Installation nicht mehr aktualisiert werden kann.

Übrigens, das Kommando ist nur ein Beispiel. Hast du den überprüft, ob die Pfade überhaupt stimmen? Bspw. wird es wohl contao-manager.phar.php sein und nicht cm.phar.php.

Ist die Abschaltung von PHP 7.4 und älteren Versionen bei HE denn überhaupt in Stein gemeißelt? Oder ist es so wie bei 1&1 Ionos, dass man eine nette Mail bekommt in der dann sinngemäß drinsteht: "PHP 7.4 wird nach dem xx.xx.xxxx nur noch im Rahmen des Extended Support unterstützt, Kostenpunkt x,-€/Monat. ..." Bietet also HE eventuell analog dazu einen extended Support kostenpflichtig an? Ok, ich würde mal vermuten eher nicht, aber wer weiss?!?

Nach allem was ich dort bisher erlebt habe: Dar Termin ist fest, es sei denn, man flutet sie mit Supportanfragen. 5.6 haben sie dann mal geschoben.

Ja, schätze auch mal, die lassen sich nicht mal mit Geld dazu zwingen. Abgesehen davon, das eigentliche Problem würde es ja auch nicht lösen, sondern bestenfalls aufschieben und dabei noch Zusatzkosten verursachen, welche die Kosten für die Verschiebung der Websites zu einem anderen Anbieter (unter Beibehaltung des HE Webhostings für Mail) übersteigen würden.

Zitat:

---

Zitat von Spooky

Übrigens, das Kommando ist nur ein Beispiel. Hast du den überprüft, ob die Pfade überhaupt stimmen? Bspw. wird es wohl contao-manager.phar.php sein und nicht cm.phar.php.

---

Ich benenne den contao-manager.phar.php bei meinen Installationen immer um.
1. um den Link zum CM im BE zu verbergen.
2. weil es kürzer zu schreiben ist. :cool:

Zitat:

---

Zitat von tab

Ja, schätze auch mal, die lassen sich nicht mal mit Geld dazu zwingen. Abgesehen davon, das eigentliche Problem würde es ja auch nicht lösen, sondern bestenfalls aufschieben und dabei noch Zusatzkosten verursachen, welche die Kosten für die Verschiebung der Websites zu einem anderen Anbieter (unter Beibehaltung des HE Webhostings für Mail) übersteigen würden.

---

Ein Umzug würde bei den meisten Kunden gehen, wenn diese nicht ihre Mail-Konten auf "hostet Exchange Postfach" eingestellt hätten.

Dann ist HE eben ab November ein reiner Mailhoster und die Kunden brauchen ein Webhosting extra. So hatte ich das gemeint, ansonsten würden ja gar keine Zusatzkosten anfallen, so günstig ist HE dann auch wieder nicht.

Ich schreibe jetzt seit Tagen mit dem HE-Support hin-und-her. Mal wurde mir der Trick mit der php.ini als "Lösung" verkauft (ohne das startet der Contao Manager erst gar nicht aber darum geht es im aktuellen Fall überhaupt nicht). Heute hieß es, man kann das Problem nicht nachvollziehen und was ich denn konkret gemacht hätte. Ich habe dem HE-Support jetzt auf meinem Account (!) eine Testumgebung eingerichtet und den Ablauf und das Problem genau beschrieben. Eigentlich kann man danach nicht mehr sagen, es gäbe kein Problem. Na mal abwarten.

Was mir aufgefallen ist: wenn die Fehlermeldung

@php vendor/bin/contao-setup
Script @php vendor/bin/contao-setup handling the post-install-cmd event returned with error code 255

beim Installieren der Composer-Pakete erscheint, kann man die tasks.json per FTP löschen und der Contao Manager läuft wieder. Erstaunlicher Weise ist es mir so gelungen, ein Contao-Update durchzuführen. Und der CM meckert auch nicht, dass es ein Problem in der Installation gäbe. Es bleibt aber ein ungutes Gefühl, denn ohne Grund wird es die Fehlermeldung nicht geben und ich kann einfach nicht nachvollziehen, WAS genau passiert und WO die Installation aussteigt.

Hier ein letztes Update:

Mal war es meine Schuld, weil ich noch /web und nicht /public verwende (der HE-Support hat es auf /public geändert und dann lief es). Blöd nur, dass dieser Ordner PHP 7.4 zugewiesen hatte und eben nicht PHP 8.x. und es ist kaum zu glauben, dass ich als Kunde sie darauf hinweisen muss. Außerdem sagt https://docs.contao.org/manual/de/in...raussetzungen/ dazu
"ab 4.12 Dem Standard von Symfony folgend, wurde der öffentlich erreichbare Unterordner von /web in /public umbenannt. Falls in deiner Installation ein Verzeichnis /web existiert, wird dieses von Contao automatisch anstelle von /public verwendet."

Beim der nächsten Mail konnte anhand meiner Testinstallation angeblich gar kein Problem festgestellt werden. Der Support hatte die Fehlermeldung im CM ganz einfach ignoriert und ihn neu gestartet. Bei der Contao-Grundinstallation kann man sich damit tatsächlich "durchmogeln", weitere Pakete danach zu installieren geht aber definitiv nicht.

Dann habe ich konkret gefragt, ob es nun einen Workaround gibt, ob es auf einem bestimmten Paket (z.B. Server) definitiv läuft oder ob nur ein Providerwechsel bleibt. Hier die Antwort:

"Auf dem Shared-Hoting System und den damit verbundenen WebHosting Produkten unterstützen wir weiterhin kein Contao. Dies wurde auf diesen Systemen nie offiziell unterstützt. Unter anderem, weil es dort immer wieder erhebliche Probleme mit dem Tmp-Pfad gibt, den Contao so nicht nutzen will. Ein Workarround war nur möglich, wenn man die Dateien vom CMS selbst anpasst hat. Eine sichere Unterstützung ist aber damit nicht gewährleistet. Unter einem WebServer Produkt sollte die jedoch ohne Probleme laufen, wenn der tmp-Pfad in der bash_profile gesetzt ist. "

Das heißt für mich
1. Wir wollen Contao nicht
2. Contao hat Schuld und wir nicht
3. Es könnte auf WebServer laufen...weiß man aber nicht 100%

Ich bin jetzt tatsächlich seit 20 Jahren Kunde bei HE aber das war es dann für mich ...

Viel Glück allen, die sich weiter um eine Lösung bemühen ...

Das ist ja - mit Verlaub - Kokolores. Ich betreibe Contao seit Version 2.4 auf Webpacks von Hosteurope, ab den 3er-Versionen auch mit Composer, und dabei hat es noch nie irgendwelche Klimmzüge benötigt. Auch die bisherigen 4er-Versionen waren dabei ohne Ausnahme bis PHP 7.4 lauffähig, und ich meine mich zu erinnern, dass 4.12 im Frühjahr auch unter PHP 8.0 keine Schwierigkeiten bereitet hat.

Im Übrigen sei doch mal angesichts der Aussage "Dies wurde auf diesen Systemen nie offiziell unterstützt" mal auf deren eigenes Blogposting aus dem Jahr 2017 verwiesen, in dem eine Installation exemplarisch (wenn auch noch ohne Manager und mit einigen Fehlern) erläutert wird. Wenn sie dazu sogar bloggen, dann würde ich auch davon ausgehen, dass es unterstützt wird.

Insgesamt empfinde ich die Antwort als eine Unverschämtheit.

Zitat:

---

Zitat von ausi

Das sys_get_temp_dir sollte sich auch über die Umgebungsvariable TMPDIR setzen lassen, folgender Aufruf sollte /foo/bar ausgeben:

Code:

---

TMPDIR=/foo/bar php -r 'echo sys_get_temp_dir();'

---

Wenn jemand testen könnte ob das das problem behebt könnte man so etwas eventuell in den Manager einbauen.

Code:

---

$ TMPDIR=/is/htdocs/user_tmp/wp12345678_XXXXXXXXXXXX /usr/bin/php8.0 -q -c /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/contao-manager/php.ini -dmax_execution_time=0 -dmemory_limit=-1 -dallow_url_fopen=1 -ddisable_functions= -ddate.timezone=Europe/Berlin /is/htdocs/wp12345678_XXXXXXXXXXXX/www/contao4/web/cm.phar.php composer install --no-dev --no-progress --no-ansi --no-interaction --optimize-autoloader

---

---

Hab das mal via SSH beim Kunden Account (angepaßt) probiert. Erhalte dann die Meldung das composer nicht ins Verzeichnis schreiben kann - Man sollte eine php.ini erstellen?

Code:

---

PHP temp directory (/is/htdocs/user_tmp/wpxxx_xxx) does not exist or is not writable to Composer. Set sys_temp_dir in your php.ini

---

Noch besser: Wenn ich auf PHP 8.1 umstelle existiert gar kein Verzeichnis /usr/bin/php8.1

(Status: Der Kunde hat einem Hoster Wechsel zugestimmt - werde den Domain Umzug jetzt einleiten)

Offensichtlich hat Contao bei Hosteurope ja keine Zukunft mehr, und für HE selber wird die Zahl derer, die ihnen deswegen den Rücken kehren keine kritische Größe sein. Als Betroffener mit einigen Installationen bei HE hier die offene Frage an die Community, welchen Hoster ihr für Shared Hosting empfehlen könnt, also für eine Komplettmigration inklusive Mailpostfächer. Danke im Voraus!

Ich war früher auch bei HE - nun bei All-inkl und bin damit recht zufrieden...

Etwas vestecktes Feature: wenn Du Dich in Dein PF online einloggst, gibt es die Möglichkeit ein anderes IMAP-Konto abzufragen und die Daten zu übertragen - dann muss das nicht über den eigenen Rechner laufen...

Da für meine Kunden ein Providerwechsel nur die letzte Option ist und weder ich noch die Kunden mit der HE-Aussage zum WebServer "sollte dort laufen" nicht leben konnten, habe ich es auf einem WebServer BASIC (HDD) ausprobiert. Das ist der kleinste Tarif, den man wählen kann. Ergebnis: Contao und der Contao-Manager laufen dort problemlos. Das nur zur Info, falls jemand bei HE bleiben möchte.

Ein paar Tipps dazu:

Eine Tarifumstellung überführt zwar alles autom. (Domains, Mailkonten, Einstellungen). Da sich aber die Mailserver ändern, muss man mit der Anpassung in seinen Mailclients leben. Und eine manuelle Sicherung von Webspace, Datenbank versteht sich vorher trotzdem von selbst!

Die PHP-Version muss im KIS natürlich manuell auf PHP 8.x umgestellt werden!

Aktiviert NICHT den "APC User Cache (APCu)". Das führt dazu, dass der Contao-Manager bei der Systemprüfung für den Webprozess zwar PHP8.1 findet, für CLI aber weiterhin lustig PHP7.4 verwendet.

Zur Sicherheit habe ich PHP8.1 noch als Standard für den CLI-Prozess eingestellt. Das geht so:
- SSH-Zugang im KIS anlegen
- Per SSH einloggen
- In der SSH-Konsole mit diesem Befehl die PHP-Version prüfen: php -v. Wenn sie der Enstellung lt. KIS entspricht ist alles gut. Ansonsten so fortfahren:
- Die bash_profile mit diesem Befehl in der SSH-Konmsole öffnen: vi ~/.bash_profile
- Mit i kommt ihr in den Bearbeitungsmodus und könnt mit dem Cursor in den Zeilen navigieren.
- Wenn kein Eintrag für TMP zu sehen ist, diese Zeile einfügen (das erspart euch die php.ini im Verzeichnis "contao-manager"): export TMP="pfad/zum_tmp/wie/im/kis/benannt"
- Dann diese Zeile einfügen: export PATH="/usr/bin/php8.0:$PATH" oder je nach gewünschter Version: export PATH="/usr/bin/php8.1:$PATH"
- Speichern und Beenden mit ESC :wq!
- Die bash_profile mit diesem Befehl in der SSH-Konsole neu verarbeiten: . ~/.bash_profile (ja, der Punkt ganz am Anfang gehört dazu!)
- In der SSH-Konsole mit diesem Befehl die PHP-Version erneut prüfen: php -v

Good luck!
Olli

Hier die Antwort von Host Europe Support

Zitat:

---

Leider ist unsere Konfiguration, bei den Shared Hosting Paketen keinen Zugriff auf das Temp Verzeichnis des Betriebssystems zu ermöglichen, schon allein aus Datenschutzgründen unumgänglich. Andernfalls könnten dort abgelegten Daten von anderen Kunden eingesehen werden.

Wie Sie möglicherweise jedoch bereits wissen, gibt es einen Workaround für das Verhalten des Contao Managers:

Bitte legen Sie eine php.ini Datei im Contao Manager-Verzeichnis mit folgendem Inhalt ...

Nach einem Neustarten des Managers sollte dieser wieder wie gewohnt funktionieren.

---

Bleibt uns nur der Providerwechsel? WebServer Basic HDD sind € 19.99 im Monat, keine Option für uns!

Du kannst folgende Antwort an HostEurope senden:

Es wird auch nicht verlangt auf das Temp Verzeichnis des Betriebssystems zuzugreifen. Das Problem ist, dass in der Hosting Umgebung von HostEurope aktuell kein gültiges temporäres Verzeichnis von der PHP Funktion sys_get_temp_dir() geliefert wird. Damit PHP Applikationen korrekt funktionieren, muss diese Funktion ein für den aktuellen Prozess des aktuellen Users, gültiges Verzeichnis zurück liefern. Sprich, die PHP Konfiguration der PHP Prozesse je Server-User muss ein entsprechendes Verzeichnis entweder über die jeweilige .ini oder über die Umgebungsvariable TMPDIR gesetzt haben. Sowohl über den PHP Web Prozess, als auch auf der Kommandozeile.

Nachrichtlich: Ich hatte die gestern früh mal von einer @contao.org-Adresse aus angeschrieben und auf das unterschiedliche Verhalten unter den verschiedenen PHP-Versionen hingewiesen und gefragt, ob sie sich das mal im Hinblick auf eine eventuelle Fehlkonfiguration anschauen mögen. Angesichts der sonstigen Reaktionszeiten halte ich es jetzt eher für ein gutes Zeichen, dass ich bisher keine Antwort erhalten habe.

Schaun mer mal. Ich berichte dann.

Bei mir kam die Antwort vom Support sehr schnell.

Zitat:

---

Mit dem Aufruf der Funktion sys_get_temp_dir() wird der richtige Pfad Ihres temporären Pfades ausgegeben. Dies könnte Contao auch auslesen, was es jedoch nicht macht.

Dadurch das keinen Temp-Pfad abgerufen hat, wird dies auf einen Fehler laufen. Durch das Hinterlegen der php.ini Datei mit dem entsprechenden Pfad, kann Contao installiert werden.

Eine Anleitung, wie man dies hinterlegen kann per php.ini finden Sie hier zusätzlich: https://github.com/contao/contao-man...iki/HostEurope

---

Könnt ihr bestätigen, dass der php.ini Workaround nur mit PHP 7.x funktioniert, aber die Installation mit PHP 8.x nicht läuft?

Zitat:

---

Zitat von ffw

Bei mir kam die Antwort vom Support sehr schnell.

---

Du kannst folgende Antwort zurück senden:

Contao bzw. die Abhängigkeiten davon (inkl. Symfony) nutzen sys_get_temp_dir(). Das Problem ist, dass bei sys_get_temp_dir() kein gültiges Verzeichnis geliefert wird, welches vom PHP Prozess beschrieben werden kann. Und zwar dann nicht, wenn der Prozess bspw. mittels passthru angeworfen wird. In dieser CLI Umgebung ist dann kein korrektes Temp Directory für diesen Prozess definiert.