Druckbare Version
Vielen Dank, Leo. Habe von Domainfactory den Arbeitsspeicher auf 500 MB hochsetzen lassen. Aber auch das führt bei dem Update von 2.11.4 auf 2.11.5 zu dem o.g. Ergebnis. Ich habe inzwischen bei anderen Installationen auf dem gleichen Server problemlos von 2.11.5 auf 2.11.6 updaten können, aber bei der 2.11.4-Version habe ich weitehin das beschriebene Problem.
Ist eigentlich zwingend die FASTCGI-Version von PHP 5.3.8 erforderlich oder tut es auch die Standard-Version?
Es geht auch mit mod_php, falls Du das mit "Standardversion" meinst. Welche Version des Live Update-Client hast Du denn auf den verschiedenen Accounts laufen?
Ja, ich meinte die "mod_php"-Version. Während die FASTCGI-Version zu dem o.g. Screenshot führt endet die mod_php-Version übrigens irgendwann mit einem Fehler 500. Beide PHP-Version führen aber das Update 2.11.5 auf 2.11.6 problemlos aus.
Ich verwende überall die gleiche, aktuelle Version "Live Update (v4.2)".
Ist die 2.11.4er-Version aktuell (lt. Contao-Check)? Was passiert, wenn Du eine der funktionsfähigen Installationen von 2.11.6 auf 2.11.4 downgradest und anschließend wieder upgradest?
Laut Contao Check ist die Version aktuell und hat auch sonst alles "im grünen Bereich". Der Downgradeversuch von 2.11.6 auf 2.11.4 endet leider genauso wie der Upgradeversuch von 2.11.4 auf 2.11.5. Downgrade auf 2.11.5 und wieder zurück auf 2.11.6 funktioniert dagegen problemlos und schnell.
Ich hatte inzwischen noch einmal Kontakt zu Domainfactory wegen dieses Problems. Die Antwort ist leider etwas ernüchternd:
"Leider haben auch tiefgreifende Prüfungen kein neues Ergebnis gebracht.
Auch in den Logfiles erhalten wir keinen Fehler, sodass wir genauere
Informationen übermitteln könnten.
Vermutlich verschluckt Contao die Fehlermeldungen, sodass diese nicht
gespeichert werden können.
Auch ein Aktivieren des Error-Loggings über die php.ini hat keine
Veränderung bewirkt, und ein nochmaliges Erhöhen der Limits führte auch
nicht zum Ziel.
Bei dem Update wird auf die Domain von Contao zugegriffen, eventuell
kommt der Fehler von dort? Ohne Fehlermeldung ist es nur schwer
möglich, die Ursache des Fehlers einzugrenzen."
Allmählich versteh ich gar nichts mehr. :confused:
Nachdem HE Phar aktiviert hatte (https://www.contao-community.de/show...l=1#post224355), und das LU auf dem Server zumindest anlief (ganz durchgeführt hatte ich es da noch nicht, weil ich zunächst lokal testen wollte und zum Serverupdate lieber eine Zeit mit niedriger Besucherfrequenz wähle), wollte ich heute das LU durchführen und bekomme wieder die berühmte weiße Seite und beim Check wieder den Hinweis, das phar nicht aktiviert ist.
Hat jemand eine Erklärung dafür, wie sich diese Einstellung von selber deaktivieren kann? Hat jemand ähnliche Erfahrungen bei einer HE-Installation gemacht?
Habe den HE-Support natürlich angemailt und bin gespannt auf die Antwort...
Im Ankündigungs-Thread für 3.0 RC1 habe ich aufgeschnappt, dass Live-Update auch für die Betas und RCs funktionieren soll - was bei mir nicht klappt (bin auf 3.0 RC1). Ich bekomme statt dessen die Möglichkeit, auf 2.11.6 zu gehen - was mir weniger sinnvoll scheint :)
Was habe ich übersehen?
Von beta/RC auf stable: ja
Von stable of beta/RC: nein
Anbei noch mal eine Phar-Testdatei, die wirklich nur das absolute Minimum an Code enthält und eine PHP-Info-Seite ausgibt. Wenn der Provider die gerne genutzte "die Applikation scheint einen Fehler zu haben"-Karte zieht, kann man mit der Testdatei nachsehen, ob es tatsächlich am Live Update Client liegt oder ob doch Phar nicht korrekt funktioniert.
ACHTUNG! Die Datei muss im Binärmodus übertragen werden, andernfalls kommt es zu einem "Broken Signature"-Fehler.
Vielen Dank, Leo.
Da ich beim Ausführen deiner Datei den folgenden Fehler erhalte, werde ich wohl nochmal bei Domainfactory anklopfen:
"Fatal error: Uncaught exception 'PharException' with message 'phar "/xxx/test.phar.php" SHA1 signature could not be verified: broken signature' in /xxx/test.phar.php:8 Stack trace: #0 /xxx/test.phar.php(8): Phar::webPhar('test.phar.php', 'index.php', '', Array, 'phar_rewrite') #1 {main} thrown in /xxx/test.phar.php on line 8"
Hallo,
jetzt wollte ich auch mal wieder updaten von 2.11.5 auf 2.11.6.
Nachdem auch bei mir die weisse Seite kam, hab ich den neuen Contao-Check hochgeladen mit Ergebnis für PHP:
nach dem löschen der "update.phar.php" komme ich wieder zur Auswahl ob Update für PHP 5.3 oder 5.2.Zitat:
PHP 5.3.2 oder größer
Sie haben die PHP-Version 5.3.3-7+squeeze3.
PHP Phar-Erweiterung
Die PHP Phar-Erweiterung ist aktiv.
ionCube Loader
Der ionCube-Loader ist nicht aktiv oder liegt mindestens in der Version 4.0.9 vor.
Suhosin-Erweiterung
Die Suhosin-Erweiterung verhindert die Ausführung von .phar-Dateien.
Sie müssen "phar" in Ihrer php.ini zur Liste der erlaubten Streams hinzufügen: suhosin.executor.include.whitelist = phar.
Detect Unicode
Das Flag --enable-zend-multibyte ist nicht gesetzt oder detect_unicode ist deaktiviert.
FastCGI+eAccelerator
Sie verwenden kein FastCGI mit dem eAccelerator.
Sie können das Live Update auf diesem Server nicht verwenden.
bei Auswahl 5.3 -> weisse Seite.
bei Auswahl 5.2 -> funktioniert.
muss jetzt da der Hoster die php.ini bearbeiten oder anderweitig tätig werden?
Habe in diesem Threat leider etwas den Überblick verloren (abgesehen davon, daß ich eh kein Programmierer bin).
Danke und Grüße
Carlos
ACHTUNG! Die Datei muss im Binärmodus hochgeladen werden! Andernfalls kommt es zu dem "Broken Signature"-Fehler.
@Carlos
Das muss der Provider tun sofern du das nicht selbst kannst/darfst.Zitat:
Sie müssen "phar" in Ihrer php.ini zur Liste der erlaubten Streams hinzufügen: suhosin.executor.include.whitelist = phar.
danke, mal schauen, ob er mitmachtZitat:
Zitat von BugBuster
Nachdem ich Leos Testdatei im Binärmodus hochgeladen habe, bekomme ich problemlos eine Info-PHP-Datei ausgegeben. Daran scheint es bei mir also nicht zu liegen, dass das Updatescript beim Versuch von 2.11.4 auf 2.11.5 zu updaten grundsätzlich aus dem Ruder läuft.
Ich kann das Problem reproduzieren, wenn man z.B. von der 2.11.2 auf die 2.11.6 updated will. Ich finde aber die Ursache nicht. Als zwischenzeitlichen Workaround kann man auf die 2.10.4 downgraden und direkt im Anschluss auf die 2.11.6 upgraden. Das funktioniert bei mir ohne Probleme.Zitat:
Zitat von Daniel_
So, nun habe ich das Problem endlich gefunden. Es liegt an den Änderungen aus Ticket #4892, die ich in der Version 4.3 des Live Update-Client zurückgenommen habe. Bitte jetzt noch einmal versuchen.
Perfekt! Bei mir läuft es jetzt schnell und ohne Probleme.
hallo zusammen,
nachdem auch bei uns (HE) die php-updates auf 5.3 durchgeführt wurden haben wir uns ebenfalls gefreut, dass die live updates jetzt ja dank phar funktionieren müssten (alle unsere kunden liegen auf shared hosting servern von HE). aber pustekuchen. aus zeitlichen gründen haben wir unsere live updates dann erstmal nicht durchgeführt.
mittlerweile konnten wir klären, dass eine eintragung in der htaccess notwendig ist, um die updates ausführen zu können:
testen konnte ich es indes noch nicht ...PHP-Code:php_flag detect_unicode off
In der .htaccess funktioniert das allerdings nur, wenn PHP als Apache-Modul ausgeführt wird.
Soviel ich weiss sollte detect_unicode ohnehin immer auf Off sein. Diese Direktive ist veraltet und wird in einer zukünftigen PHP-Version entfernt :)
Edit:
Hier noch was zum Lesen:
Edit2:
https://github.com/contao/check/issues/28
so, nachtrag:
nachdem es mit der 'einfachen' eintragung in der htaccess nicht funktioniert hat habe ich nochmals mit HE telefoniert: es muss über das KIS eine supportanfrage gestellt werden, mit der bitte "phar" in der php.ini zur liste der erlaubten Streams hinzu zu fügen: suhosin.executor.include.whitelist = phar.
das sollte angeblich klappen.
@toflar:
danke, aber das ist in meinem fall sache des hosters (host europe), und ich gehe einfach mal davon aus, dass die wissen, was sie tun. immerhin ist das nicht einfach irgendwer, sondern schon einer der großen ...
NACHTRAG:
hat funktioniert. mittlerweile sind fast alle unsere kunden-webpacks bei HE mit phar ausgestattet. das liveupdate lief schon bei einigen installationen problemlos durch.
Zur Info die Antwort von HE:Zitat:
Zitat von jubel
Zitat:
> Wie ich gerade feststellen muss, ist die Einstellung inzwischen wieder
> deaktiviert. Wie ist das möglich?
Die Funktion wurde wieder zur Verfügung gestellt.
Die Deaktivierung erfolgte aufgrund interner Maßnahmen im Abuse-Bereich.
Hallo Mitlesende, ich bin ein unbeschriebenes Blatt was php und Contao betrifft - das vorab!
nachdem ich nun drei Stunden für das nachlesen des Threads, incl. Erwachsenenstreiterei, benötigt habe und mein Problem ebenfalls die Meldung: Fatal error: Class 'Phar' not found in /homepages/xx/xxxxxxxxxx/htdocs/xxxxxxx/contao/update.phar.php on line 33 war habe ich mich selbst bei 1und1 ins Hilfecenter begeben und nachgelesen wie ich herausfinden kann, welche php Version aufgesetzt ist. Das geht ganz leicht: http://hilfe-center.1und1.de/article/782429, danach habe ich die update.phar.php in meiner Installation gelöscht, bei 1und1: php_dev (also lt. 1und1 PHP 5.4.x.) gewählt und im Contaoupdate aber angegeben, dass ich nur php.5.2.x habe - erstaunlich war, dass das kompl. Update (auf 2.11.6) ohne das leiseste Mucken durchlief.
Das war doch echt Glück - so im Zusammenhang von Versionseinstellungen und schrägem Denken, oder? Na ja, vielleicht hilft mein Eintrag ja jemandem.
Nun kommt aber meine Frage: wie kann ich in Contao den abgesicherten Modus verlassen, um von der roten Schrift nicht länger eingeschüchtert zu werden? Danke an alle Poster und Mitdenker für die vergangenen Threads und eine Antwort auf meine Frage.
schöne Tage euch allen
Abschalten des abgesicherten Modus:
Backend unter System - Einstellungen, dort in den Bereich "Globale Einstellungen" (bei Contao 3, bei Contao 2 in "Sicherheitseinstellungen")
(eventuell anklicken zum aufklappen)
darin gibt es den Punkt "Abgesicherter Modus", Haken raus und unten auf "Speichern und Schließen"
Und, Willkommen bei Contao :D
System > Einstellungen > Sicherheitseinstellungen > Abgesicherter ModusZitat:
Nun kommt aber meine Frage: wie kann ich in Contao den abgesicherten Modus verlassen, um von der roten Schrift nicht länger eingeschüchtert zu werden? Danke an alle Poster und Mitdenker für die vergangenen Threads und eine Antwort auf meine Frage.
@Bugbuster
Das gilt für die Version 3.Zitat:
dort in den Bereich "Globale Einstellungen"
Hey, merk ich ja jetzt erst, das der Punkt in Contao 3 verschoben wurde....
So, nach einigem Kopfweh habe ich das neue LiveUpdate auch auf W3W.de zum laufen bekommen.
Folgende htaccess Einträge sind nötig:
Nach erstmaligem Aufruf und Download der update.phar.php im Sitecontrol Rechte zuweisen ( Nobody + Username )Code:php_flag detect_unicode Off
php_flag phar.readonly Off
php_flag phar.require_hash Off
Und zum Schluss in der htaccess den eAccelerator abschalten, sonst gibt es eine Fehlermeldung:
Nach dem Update einfach die Option wieder heraus nehmen.Code:php_flag eaccelerator.enable 0
Falls es mit den Einträgen oben nicht gleich klappt, den Support anmailen, kann sein dass die im Hintergrund auch noch was einstellen müssen.
Um auch das Datenbank-Backup machen zu können, diesen Link an den Support, mit der Bitte das freizuschalten.
Hi
Dieses Problem besteht bei mir auch mit der neusten Liveupdate-Version 5.2
Eine Idee, was da nicht läuft?Zitat:
Zitat von tinoo
Ist das eventuell eine Safe-Mode-Beschränkung?
Das passiert mit der PHP-Version < 5.3 (und keine zusätzliche PHAR-Erweiterung installiert ist)Zitat:
Zitat von bacchus
Ab da hättest Du auch das neue Live-Update nehmen können. Sollte bei 1und1 kein Problem mehr sein.Zitat:
Zitat von bacchus
Hoi Leo
Hm... Die Seite ist auf einem IIS-Server gehostet. Contao kommt (bislang) ohne Safe-Mode-Hack aus und läuft seit Jahren einwandfrei und konnte auch immer über Liveupdate auf den neusten Stand gebracht werden... Ich frag mal meinen Hoster...Zitat:
Zitat von leo
Ok, hier ein kurzes Feedback bezüglich meines obengenannten Problems, falls jemand mit
ähnlichen Problemen zu kämpfen hat... :D
Zitat:
Eine Sicherheitseinstellung in unserer PHP Konfiguration lässt nur bestimmte execute Befehle zu,
welche wir explizit freigegeben haben. Aus diesem Grund haben Sie den Fehler bekommen. Wir
haben dies nun auf Ihrem Server so angepasst, dass der für das Update benötigte Befehl
ausgeführt werden kann und werden diese EInstellung auf all unseren Servern in den
kommenden tagen übernehmen.
Hallo Community,
ich habe, Dank der automatischen Updatefunktion, auf v3.0 erneuert. Der Vorgang lief recht schnörkellos durch und am Ende habe ich dann oben einen "deaktivieren" Button gedrückt und mich aus dem BE abgemeldet. Neuerliche Anmeldungen schlugen alle fehl - die Eingabebox für Name und Passwort erscheint > Eintragungen erfolgt > Anmelden - und brachten eine weiße Oberfläche im Firefox-Browser. Die Anzeige des Quelltextes bringt mir oben links eine ausgegraute Zahl "1".
In Chrome erhalte ich die Fehlermeldung: HTTP-Fehler 500 (Internal Server Error): Beim Versuch des Servers, die Anforderung zu verarbeiten, ist eine unerwartete Bedingung aufgetreten..
Wie kann ich vorgehen, welche Änderungen muss ich vornehmen - ich bitte um Rat und Hilfe - Danke! und freundliche Tage
Warum? Was deaktivierst du da mit? Den abgesicherten Modus? Das war dann der Fehler.Zitat:
habe ich dann oben einen "deaktivieren" Button gedrückt
Du hast jetzt ne Menge Erweiterungen installiert die nicht C3 kompatibel sind, die eigentlich deaktiviert waren.
ok! Danke erstmal für die Aussicht. Kann ich das wieder rückgängig machen?Zitat:
Zitat von BugBuster
Hallo,
ich habe in Contao noch nie ein update gemacht. Ich habe mir gerade das Major Video angesehen. Ist dieses Update verfahren kostenlos? Weil ich auf der INet Robots gesehen habe das es dort eine Live Update ID zu kaufen gibt. http://www.inetrobots.com/shop/produ...Update-ID.html
Die updates im Backend sind doch kostenlos oder nicht. Vielleicht kann mir jemand erklären was die Unterschiede sind und was einem zu raten ist.
danke
Die Updates sind weiterhin kostenlos.
Mit der Live-Update-ID geht es jedoch deutlich einfacher. Allerdings bitte beachten, dass mit der neuen Liveupdate-Version einige Einstellungen (providerabhängig) notwendig sind. Dazu gibt es hier genügend lange Threads.
Versuche mal damit: in die localconfig.php reinschreiben:Zitat:
Zitat von bacchus
Code:$GLOBALS['TL_CONFIG']['coreOnlyMode'] = true;