Neue Live Update Major-Version

[Nina]

Bisher habe ich von den Hostern grundsätzlich zur Version die folgende Rückmeldung:

All-Inkl: 5.3.13
Hetzner: 5.3.1
Alfahosting: 5.3.14

Hosteurope:

Bei neu gebuchten WebPacks ist bereits PHP 5.3.13 aktiv. Bei bestehenden Paketen, welche noch auf PHP 5.2.17 laufen, ist ein Upgrade der PHP Version über das Kundensystem möglich.

Unsere Virtual Server Managed Pakete werden noch mit PHP 5.2.17 bereitgestellt, können jedoch auf Anfrage ebenfalls auf PHP 5.3.13 umgestellt werden.

Eine vollständige Umstellung auf PHP 5.3.13 ist bereits in Planung und wird voraussichtlich im August oder September stattfinden.

Weitere Hoster stehen noch aus. Wie xchs aber schon korrekt gesagt hat, sagt die Version alleine noch nicht viel aus.

[BugBuster]

Hmm, phar.readonly sollte nicht das Problem sein, oder? Wir wollen das ja nur lesen und nicht verändern oder generieren.
Und phar.require_hash heißt, Leo müsste eine Signatur mit reinlegen, wenn ich das hier richtig lese, wäre machbar. Ist ja ein Sicherheitsfeature.

Bleibt detect_unicode, was man theoretisch per ini_set('detect_unicode', 'Off'); sogar selber setzen könnte in der localconfig.php oder initconfig.php
(noch nicht getestet)

Derzeit würde das bei Goneo auch bedeuten nix geht trotz PHP 5.3.13, da die phar Werte alle auf On stehen.

[tinoo]

Wenn ich mir dann beispielsweise bei ALL-INKL die PHP-Konfiguration über phpinfo() ausgeben lasse und im Abschnitt "Phar" u.a. die folgenden Einstellungen finde .... dann ist auch nicht weiter verwunderlich, wieso es in dieser Hinsicht wahrscheinlich (noch) Probleme gibt oder geben kann.

Interessant. Ich hab zwei Hoster und beide geben mit phpinfo() die Informationen wie beim von dir eingefügten Bild aus. Beim einen funktioniert Liveupdate einwandfrei, beim anderen hingegen nicht...


Edit:

Der einzige Unterscheid: Bei dem, wo es funktioniert, fehlt der Eintrag "detect_unicode" im Abschnitt "Core". Bei dem, wo es nicht funktioniert, steht "detect_unicode On On"...

[BugBuster]

schau mal bitte einige Zeilen über denen im Phar Abschnitt, da werden Pack Arten aufgelistet, ob die auch gleich sind.

[Flex]

Wenn ich mir dann beispielsweise bei ALL-INKL die PHP-Konfiguration über phpinfo() ausgeben lasse und im Abschnitt "Phar" u.a. die folgenden Einstellungen finde

dann ist auch nicht weiter verwunderlich, wieso es in dieser Hinsicht wahrscheinlich (noch) Probleme gibt oder geben kann.

Bei anderen Webhostern oder in anderen PHP-Konfigurationen wird es vermutlich ähnlich aussehen. Daher müsste man zunächst diese (bekannten) Stolpersteine ausfindig machen und ggf. aus dem Weg schaffen.

Das sind die von PHP vorgegebenen Default Settings... Und mal ehrlich, so weit ist Phar im SharedHosting Bereich nicht in der Anwendung, von daher sehen (sahen?) die meisten Hoster wohl noch keinen Anlass da was zu ändern...

[BugBuster]

Hier mal Goneo zur Datensammlung:

[tblumrich]

Hi.

Ich weiß nicht obs hilft... bei mir:

Uberspace PHP 5.3.5 - keine Probleme
Canhost PHP 5.3.14 - keine Probleme

Weitere Server mit Projekten, die ich betreue, hab ich noch nicht getestet.

Gruß
Thomas

[tinoo]

Hoi BugBuster

schau mal bitte einige Zeilen über denen im Phar Abschnitt, da werden Pack Arten aufgelistet, ob die auch gleich sind.

Hier mal ein Auszug vom Hosting, wo es NICHT funktioniert:


PHP Version 5.3.10
FreeBSD 8.3-RELEASE-p1 FreeBSD 8.3-RELEASE-p1
Phar: PHP Archive support enabled
Phar EXT version 2.0.1
Phar API version 1.1.1
SVN revision $Revision: 321634 $
Phar-based phar archives enabled
Tar-based phar archives enabled
ZIP-based phar archives enabled
gzip compression enabled
bzip2 compression enabled
OpenSSL support enabled

phar.cache_list no value no value
phar.readonly On On
phar.require_hash On On

Und hier von einem Hosting, wo es geht:

PHP Version 5.3.13(uew)
Windows NT WL9 5.2 build 3790 (Windows Server 2003 R2 Standard Edition Service Pack 2) i586
Phar: PHP Archive support enabled
Phar EXT version 2.0.1
Phar API version 1.1.1
SVN revision $Id: d8eaad1a2452af8d7f8ea9e3944e43add43e1890 $
Phar-based phar archives enabled
Tar-based phar archives enabled
ZIP-based phar archives enabled
gzip compression enabled
bzip2 compression enabled
OpenSSL support enabled

phar.cache_list no value no value
phar.readonly On On
phar.require_hash On On

Ein Unterschied ist also auch bei der SVN Revision auszumachen. Ob das einen Einfluss hat?

[BugBuster]

Bei denen wo es geht, wäre der Phar Abschnitt der Phpinfo interessant.
Wer es nicht kennt:

<?php phpinfo(); ?>

als Datei anlegen und aufrufen und scrollen bis zum Abschnitt.

[BugBuster]

Hallo tinoo,

wenn das beides auch noch die gleichen PHP Versionen sind (was aber durch die unterschiedlichen phar svn Versionen nicht der Fall sein wird),
wäre ja die einzige Ursache hier:

Der einzige Unterscheid: Bei dem, wo es funktioniert, fehlt der Eintrag "detect_unicode" im Abschnitt "Core". Bei dem, wo es nicht funktioniert, steht "detect_unicode On On"...

Falls du testen magst:
lege im Verzeichnis /system/config eine Datei initconfig.php an, mit dem Inhalt:

<?php
ini_set('detect_unicode', 'Off');

Die Beschreibung läßt leider offen, ob man das nur On setzen kann im Programm oder auch Off.

[tinoo]

Hoi BugBuster

Hab ich gemacht, scheint aber keinen Einfluss zu haben. Wenn ich unter Systemwartung auf "Zum Live Update" klicke, bekomm ich eine weisse Seite mit vierzehn Fragezeichen drauf...

Es handelt sich im übrigen um unterschiedliche PHP-Versionen: PHP5.3.13 und 5.3.10, siehe frühere Postings.

[Kind-der-Nacht]

1und1 unterstützt derzeit nur PHP5.2 oder 5.4 aber ohne Support (PHP Einstellung: PHP-dev)

PHP Version 5.4.4

System Linux infong 2.4 #1 SMP Fri May 18 17:32:59 UTC 2012 i686 GNU/Linux
Server API CGI/FastCGI

Phar: PHP Archive support enabled
Phar EXT version 2.0.1
Phar API version 1.1.1
SVN revision $Id: 2a47d3d0354109d8077e34d59f1228ccfd021d59 $
Phar-based phar archives enabled
Tar-based phar archives enabled
ZIP-based phar archives enabled
gzip compression enabled
bzip2 compression enabled
Native OpenSSL support enabled

Directive Local Value Master Value
phar.cache_list no value no value
phar.readonly On On
phar.require_hash On On

"--disable-phar"-Flag war laut phpinfo() nicht gesetzt

Update mit der Version 2 führt an der gleichen Stelle, wie oben erwähnt zu einem Umteilungsfehler (FF) bzw. Netzwerkfehler (IE)

[leo]

Es bleibt auch noch die Frage, ob der Suhosin-Patch mit kompiliert wurde und ob das "--disable-phar"-Flag gesetzt war. Ersteres lässt sich aus der php.ini entnehmen, letzteres leider nur bedingt.

[leo]

Ach so, und das Server-Betriebsystem wäre auch noch interessant

[jan.theofel]

Hi,

Lag tatsächlich daran, dass ich das Backend mit www. aufgerufen habe, die Domain aber ohne www. registiert ist. Jetzt hat das Update mit der Variante PHP5.2 funktioniert. Beim Versuch mit PHP5.3 kommen noch immer Fragezeichen...

Schreib das am besten in der .htaccess um, so dass nur eine Schriebweise gültig ist. Mag Google auch lieber. ;-)

Jan

[pmmueller]

Ich habe das neue Contao-Live-Update gestern und heute bei zwei Hostern probiert:

all-inkl.com
Dort habe ich dieselben Probleme wie hier im Thread beschrieben: Per .htaccess wurde die 5.3.13 aktiviert. Internal Server Error 500. No Update.

Webhostone
Installiert ist PHP 5.3.10. Am Ende des Updates erscheint folgende Fehlermeldung:

Fatal error: Phar::webPhar() [function.require]:
Failed opening required 'phar:///home/www/name/contao/update.phar.php/index.php' (include_path='.:/usr/share/php') in /home/www/name/contao/update.phar.php on line 3

Das alte Live Update funktioniert auf beiden Webspaces problemlos.

[Schmidty]

Hallo,

hat schon jemand Erfahrung mit dem PHP-Update 5.2.17 ==> 5.3.13 beim Managed Server von HostEurope gemacht? Ich bin am überlegen, ob ich das PHP-Update beauftragen soll.

Danke für die Info.

Schmidty

[tinoo]

Ach so, und das Server-Betriebsystem wäre auch noch interessant

Hab die Angaben hier mal noch ergänzt:
https://www.contao-community.de/show...l=1#post213917

[Kind-der-Nacht]

Habe auch noch ein paar Infos hinzugefügt

https://www.contao-community.de/show...l=1#post213924

[BugBuster]

Gibt es eine Möglichkeit das phar "Problem" zu testen ohne das man eine Liveupdate ID hat?
Die phar Datei hätte ich schon mal.

Dann könnte ich bei meinem Provider testen ob es theoretisch gehen würde und ein Kauf sich damit zukünftig lohnt.

[leo]

Hab eben noch einen möglichen "Schuldigen" gefunden: Der ionCube-Loader und Phar verstehen sich auch nicht unbedingt immer.

[wotank]

Moin,

habe dasselbe Problem mit minimal anderer Fehlermeldung.

Habe also eine live-update-id gekauft und nutze diese.
Ich frage mich was macht ein User der sich überhaupt nicht auskennt?

allinkl ist ein seriöser, weitverbreiter Hoster, der sehr gerne von Webentwicklern genutzt und empfohlen wird.
Vor diesem Hintergrund sage ich nicht dass allinkl ein Problem hat, sondern das Contao ein Problem mit einem suboptimalen Update hat.

Die Diskussion hier befremdet mich doch ziemlich. Es wird imho ausschließlich drumrumgeredet und der unwissende User komplett im Regen stehengelassen.
Warum wird das Update nicht zurückgezogen um die offensichtlich vorhandenen Fehler zu beseitigen??? Stattdessen wird hier wild gemutmaßt und rumprobiert.
Da kann ich nur verständnislos den Kopf schütteln und fragen:"Hey Leute, gehts noch??"

[dotflo]

Bin da jetzt auch nicht ganz so drin, leider, und eher Nutzer.

Da es ja hier die unterschiedlichsten Fehlermeldung zu geben scheint, hier mal meine:

Parse error: syntax error, unexpected '@' in /www/htdocs/booking/contao/contao/update.phar.php on line 9

unter /contao/update.phar.php/index.php.

Hoster: All-Inkl
PHP: 5.3.13-nmm1

Und die Phar-Infos:

[leo]

Warum wird das Update nicht zurückgezogen um die offensichtlich vorhandenen Fehler zu beseitigen???

Das Live Update hat doch keinen Fehler, nur weil irgendwo die Server-Voraussetzungen nicht erfüllt sind!

[leo]

Ach so, noch eine vielleicht nicht ganz offensichtliche Sache: Die .phar-Datei muss beim Upload über FTP als Binärdatei und nicht als Textdatei übertragen werden!

[BugBuster]

Wenn ich das richtig sehe, reicht es aus die Datei '/contao/update.phar.php' umzubenennen (falls man später doch wieder damit will)
Dann wird automatisch das alte Verfahren genutzt. Wie Leo aber schon sagte, das gilt nur für Contao 2.

Wer gar nicht erst dahin will sollte bei der Abfrage ob man PHP5.3 mit phar oder 5.2 ohne phar habe, die 5.2 auswählen.

[wotank]

Das Live Update hat doch keinen Fehler, nur weil irgendwo die Server-Voraussetzungen nicht erfüllt sind!

wenn ein Update nicht funktioniert hat es für mich zunächst mal einen Fehler.
Wenn ein Update nicht funktioniert, weil es bei einem der großen Provider nicht funktioniert (allinkl ist sicher kein kleiner Provider) hat es immer noch einen Fehler.

Das Ganze auf die Servereinstellungen eines Providers zu schieben ist natürlich leicht und der schwarze Peter scheinbar weitergereicht. Aber das kanns ja wohl nicht sein.
Vielleicht sind dann die Vorraussetzungen zu einem fehlerfreien Update zu hoch geschraubt. Da ich kein Programmierer bin, fehlt mir da auch a weng der fachliche Hintergrund um das beurteilen zu können.

Die Diskussion erinnert mich insgesamt eher an ein rumstochern im Nebel. Sowas scheint mir imho nicht sehr zielführend zu sein. Wie das in der Außendarstellung bei Kollegen ankommt kann man sich ja denken, oder?

[BugBuster]

Theoretisch hat Leo recht, auch ich habe eine Erweiterung wo ich davon ausgehe, dass die Hoster nicht was rausnehmen was per default in PHP 5 drin ist. (SPL)
Aber praktisch wäre dieses neue Feature eher was für 2.12 gewesen, nicht für 2.11.5 wo die Möglichkeit für die phar Liveupdate-Möglichkeit eingebaut wurde.
Da die 2.12 ja meines Wissen nich mehr kommt, wurde das dann in die 2.11.5 reingehauen.
Mit der 2.12 hätte man dafür eine RC Phase haben können zum Test, und bei der Gelegheit auf die Erweiterung der Systemvoraussetzungen hinweisen können.

Damit man nun nicht per Hand wieder zur alten Variante zurück "schalten" muss, wäre es vielleicht nicht schlecht das im Backend wählbar zu machen.

[Fryd]

Das Ganze auf die Servereinstellungen eines Providers zu schieben ist natürlich leicht und der schwarze Peter scheinbar weitergereicht. Aber das kanns ja wohl nicht sein.

Hallo wotank, ich glaube, hier liegt ein Missverständnis vor. In dieser Diskussion wir darauf verwiesen, welche Servervoraussetzungen grundsätzlich gegeben sein müssen. Leider wurde deutlich, dass diese Voraussetzungen allein nicht ausreichen. Die folgenden Beiträge dienen deshalb dazu, herauszufinden, woran genau es liegt, dass das Update manchmal nicht funktioniert. Wenn das klar ist, wird es entweder eine Anpassung im Update gaben, die das Problem umgeht oder einen klaren Hinweis, welche Einstellungen Serverseitig vorzunehmen sind. In der Zwischenzeit gibt es aber leider eine Phase der Unsicherheit. Schade ist, dass diese Probleme anscheinend nicht in der Beta-Phase aufgetreten sind.

Vielleicht wäre es auch nützlich, wenn diejenigen, bei denen es funktioniert, die Einstellungen ihres Hosters posten und dabei auch konkret den Namen des Hosters nennen.

Herzliche Grüße
Fryd

[andreasisaak]

Vielleicht sind dann die Vorraussetzungen zu einem fehlerfreien Update zu hoch geschraubt. Da ich kein Programmierer bin, fehlt mir da auch a weng der fachliche Hintergrund um das beurteilen zu können.

Die Anforderungen sind hoch aber wie du selbst sagst - du kannst es nicht wirklich beurteilen. Daher denke ich das es bei Kollegen mit entsprechendem Hintergrund weniger schlimm ankommt.

Ist ja nicht so das TYPO3 z.B. ganz geringe Anforderungen hat und nur aus reiner Langeweile sich ganze TYPO3 Hoster gebildet haben. Das wird schon wieder, mit in die Diskussion zu breschen und hier Dampf abzulassen wird dir nichts bringen.

[wotank]

Die Anforderungen sind hoch aber wie du selbst sagst - du kannst es nicht wirklich beurteilen.

das hatte ich ja schon gepostet. Wiederholungen sind nicht notwendig.

Daher denke ich das es bei Kollegen mit entsprechendem Hintergrund weniger schlimm ankommt.

Leider nicht richtig!
Der Fred wird auch von Kollegen mit entspr. HG verfolgt. Deren Meinung zu zitieren erspare ich mir. Ich habe in der Hinsicht schon alles gesagt.

Das wird schon wieder, mit in die Diskussion zu breschen und hier Dampf abzulassen wird dir nichts bringen.

Wenn du deutliche Worte finden mit Dampf ablassen gleichsetzt stimmt das in der Tat. Da ich offensichtlich der einzige bin der dazu deutliche Worte findet sticht das natürlich um so mehr heraus.

[leo]

Also heute noch mal die definitive Bestätigung: Der ionCube-Loader verhindert die korrekte Ausführung von Phar-Dateien!

Das Problem ist bekannt: http://forum.ioncube.com/viewtopic.php?p=8867 und https://github.com/fabpot/Silex/pull/104/files

Bis seitens ionCube ein Patch zur Verfügung steht, muss die Extension entsprechend deaktiviert werden. Dies ist auch der Grund, warum das neue Live Update bei allinkl nicht klappt.

[Nina]

Eine Bitte @Leo: Schreib doch bitte auf die Update-Auswahlseite eine hervorgehobene Warnbox die genau darauf hinweist sowie die Info, wie man die getroffene Auswahl wieder umkehren kann (phar-Datei aus /contao/ löschen). Ich denke, das würde schon einigen Leuten helfen.

Wenn ich mir den Thread hier so ansehe, sind vom Problem verifiziert derzeit folgende Hoster betroffen (bitte auch in dieser Warnbox angeben):

- All-Inkl (selbst getestet)
- 1&1 (selbst getestet)
- Alfahosting (laut User steffen und RedWise)
- Hostpoint.ch (laut User Tinoo)
- Webhostone (laut User pmmueller)

Natürlich könnten noch weitere Hoster betroffen sein. Ich hab nur die genannt, die hier schon erwähnt wurden. Man muss dem Nutzer einfach klar machen, dass der Fehler nicht bei uns liegt, hoffentlich bald durch ein Update von IonCube (oder wie das Ding heißt) behoben ist und bis dahin halt doch die alte Variante genutzt werden sollte.

Selbst wenn es nicht unsere Schuld ist, dass das Problem auftaucht, könnten wir durch die entsprechende Warnbox Frust bei den Nutzern vermeiden.

[RedWise]

Hallo Nina....

wir haben bei All-Inkl ein Testaccount beantragt und eingerichtet. PHP 5.3 ist aktive.

Gemeinsam mit dem Support haben wir ein Paar Verändeungen durchgeführt z.B. https://www.contao-community.de/show...Aktualisierung

oder den ionCube-Loader zu deaktiviert, leider ohne Ergebnis, der Fehler ist nach vie vor.

Parse error: syntax error, unexpected '?' in /www/htdocs/test75833/contao-2.10.4/contao/update.phar.php on line 103

Aber nun etwas erfreuliches...

Nach Umstellung der PHP Version von 5.2 ( mit Fehlermeldung) auf 5.3, funktionierte das Backup....

mit der kleinen Fehlermeldung

Datenbank-Backup
Die PHP-Funktionen exec() oder shell_exec() sind nicht verfügbar.

Wir sind von Alfahosting positiv überascht.

Wir habe nun die infophp an den Support von All-Inkl gesand und mal sehen was passiert.

Ein kleiner Nachtrag..

Wir haben bei Alfahosting einen Testaccount angelegt, und siehe da.... das Liveupdate funktioniert auch da mit diesen Servereinstellungen.

Bildschirmfoto-2012-08-01-um-20.33.jpg

[tlightuser]

Hallo Nina.

Ich ergänze einmal deine Liste.

Wenn ich mir den Thread hier so ansehe, sind vom Problem verifiziert derzeit folgende Hoster betroffen (bitte auch in dieser Warnbox angeben):

- All-Inkl (selbst getestet)
- 1&1 (selbst getestet)
- Alfahosting (laut User steffen und RedWise)
- Hostpoint.ch (laut User Tinoo)
- Webhostone (laut User pmmueller)

- Ergänzung: STRATO Managed Server Level 5 (v1205.1.44)

@Leo: nur zur Info.
die Deaktivierung des "ionCube Loader" beim STRATO Managed Server Level 5 (v1205.1.44) hingegen hilft nicht weiter.

Edit: Problem gelöst.
Beim STRATO Managed Server Level 5 (v1205.1.44) muss FastCGI+eAccelerator im Kundenmenü deaktiviert werden. Der Server darf also nur mit FastCGI konfiguriert (betrieben) werden.

[leo]

Bei allinkl ist das Problem die GZ-Komprimierung, die ich im Live Update-Client Version 3.2 weggelassen habe. Damit konnte ich das Live Update dort ausführen.

Bei fast allen genannten – sicher bei allinkl und WebhostOne – ist das verbleibende Problem der ionCube-Loader, der dort scheinbar standardmäßig aktiviert ist. Weder der Suhosin-Patch (nicht zu Verwechseln mit der Suhosin-Extension) noch die Einstellungen bezüglich "phar.readonly" oder "require_hash" sind bei dem Format der .phar-Datei relevant.

[Kind-der-Nacht]

Auch bei Level3 bekomme ich mit FF einen Umleitungsfehler und IE sagt "Die Seite kann nicht angezigt werden", wenn ich versuche das neue Update zu benutzen.

PHP Version 5.3.13

System Linux **** 3.0.35-pn #4 SMP Wed Jul 11 16:33:21 CEST 2012 i686
Server API CGI/FastCGI

Phar: PHP Archive support enabled
Phar EXT version 2.0.1
Phar API version 1.1.1
SVN revision $Id: d8eaad1a2452af8d7f8ea9e3944e43add43e1890 $
Phar-based phar archives enabled
Tar-based phar archives enabled
ZIP-based phar archives enabled
gzip compression enabled
bzip2 compression disabled (install pecl/bz2)
Native OpenSSL support enabled

Directive Local Value Master Value
phar.cache_list no value no value
phar.readonly On On
phar.require_hash On On

Die update.phar.php ist unterschiedlich groß:

1&1 (PHP5.4.4) - 604.114 Byte
Level3 (PHP5.3.13) - 2.619.279 Byte

Edit: das neue Update bleibt jetzt auch bei 1&1 aktiviert. Der Größenunterschied besteht aber weiter..

[CeeKay]

Bei fast allen genannten – sicher bei allinkl und WebhostOne – ist das verbleibende Problem der ionCube-Loader, der dort scheinbar standardmäßig aktiviert ist. Weder der Suhosin-Patch (nicht zu Verwechseln mit der Suhosin-Extension) noch die Einstellungen bezüglich "phar.readonly" oder "require_hash" sind bei dem Format der .phar-Datei relevant.

Da bei WebhostOne bei allen aktuellen (mit Contao kompatiblen) Tarifen php.ini-Zugriff besteht, sollte sich das Problem dort lösen lassen. Die meisten User werden den ionCube-Loader eh nicht benötigen.

Edit: Aussage des WebhostOne-Supports zur Deaktivierung des ionCube-Loaders:

Bitte kopieren Sie die Einträge des Administrators in die eigenen Einträge, deaktivieren Sie bitte die Zeile zu IonCube und setzten dann bitte den Haken bei "Einträge vom Administrator in die php.ini nicht zulassen".

Das könnt ihr im WHO-Adminpanel machen (siehe Screenshot).

[pmmueller]

Aussage des WebhostOne-Supports zur Deaktivierung des ionCube-Loaders:
Bitte kopieren Sie die Einträge des Administrators in die eigenen Einträge, deaktivieren Sie bitte die Zeile zu IonCube und setzten dann bitte den Haken bei "Einträge vom Administrator in die php.ini nicht zulassen".

Hat wunderbar geklappt.

Zur genauen Vorgehensweise habe ich einen kommentierten Screenshot erstellt: 2012-08-01_17-00-54.jpg

EDIT:
Ich habe auf dem Screenshot gerade entdeckt, dass ich die maximale Skriptlaufzeit früher mal auf 60 "erhöht" hatte. Nur nach dem Tarifwechsel auf "Multi-App" ist sie inzwischen standardmäßig bei 240. Also gleich raus mit der Zeile

[pmmueller]

Bei fast allen genannten – sicher bei allinkl und WebhostOne – ist das verbleibende Problem der ionCube-Loader, der dort scheinbar standardmäßig aktiviert ist.

Bei Webhostone lässt sich das über Einträge in der eigenen php.ini lösen (und es funktioniert, siehe #79).

Gibt es bei all-inkl.com auch eine Möglichkeit diesen ionCube-Loader zu deaktivieren? Im KAS kann ich nicht so richtig was finden...