Download auch hier fehlgeschlagen

    Wow SilOrs67, du bist ja ein ganz Flotter. Da haben die Infos zackzack zu fliessen, und wenn wir nicht gleich liefern, bist du ruckzuck raus. Schneidiger Geist!


    Hallo mizapf: Deine Idee, im Quellcode der ./administrator/components/com_joomlaupdate/models/default.php herum zu pfuschen, habe ich gerne aufgenommen. Zunächst habe ich es mir ganz einfach gemacht, und Zeile 319 schlicht auskommentiert:

    Code
    317               if (!$result || ($result->code != 200 && $result->code != 310)) 318               { 319        /*               return false;          */320               }


    Und was soll ich sagen - der Download läuft! Das Update wird herunter geladen und einwandfrei installiert!


    Dann habe ich mir die Zeile 317 mal genauer angeschaut. Da wird auf zwei http-Codes verglichen, auf 200 (OK) und auf 310 (???). Ein http-Code 310 ist m. W. nirgends definiert. Ändere ich den Quellcode entsprechend zu

    Code
    317               if (!$result || ($result->code != 200 && $result->code != 303)) 
318               { 
319                       return false;
320               }


    funktionieren das Herunterladen und die Installation ebenfalls völlig störungsfrei!


    Dumm nur: Nach erfolgreichem Update meine Änderung natürlich wieder überschrieben!

    Hallo mizapf, es wäre interessant zu wissen, welche php-Version auf deiner openSUSE-Kiste läuft. Wenn das eine 5er Version < 5.6.26 ist, wäre das ein Hinweis darauf, dass tatsächlich (wie von mir oben schon vermutet) eines der letzten php-Updates zu einem geänderten Verhalten geführt hat.

    Zitat von herrmann

    Wow SilOrs67, du bist ja ein ganz Flotter. Da haben die Infos zackzack zu fliessen, und wenn wir nicht gleich liefern, bist du ruckzuck raus. Schneidiger Geist!


    Genau @herrmann du Schlauberger. Bitte mal die Forenregeln lesen. Und dann erst unqualifizierte Kommentare abliefern.. hier haste erst mal so viele Infos wie möglich zu liefern, damit Dir Schlausten der Welt..... jemand helfen kann.. und nicht hier mal schnell, einen post öffnen und am core rumbasteln.. nur weil Du nicht in der Lage bist ein Update aufzubügeln. Der Core ist nicht schuld!


    Hawadere!

    Das Problem ist meiner Meinung nicht die if-Anweisung, sondern die Tatsache, dass $http->get mit einem 303 (See other) zurückkehrt, während auf meiner openSUSE eine 200 (OK) kommt. In letzterem Fall scheint die get-Methode der Umlenkung selbst zu folgen, sprich, sie setzt automatisch einen neuen GET-Request auf das endgültige Ziel ab.


    Auf der openSUSE (wo es geht) läuft ein PHP 5.6.1, auf dem vServer mit Ubuntu 14.05 läuft 5.5.9-1ubuntu4.20.


    (Ich habe mich ein bisschen da reingekniet, nachdem mir im heise-Forum jemand vorwarf, wer so ein Problem nicht lösen könne, dürfe schon gar nicht einen eigenen Server betreiben ...)


    Michael

    Der Wert 303 in $result->code scheint tatsächlich nicht zum Ergebnis zu passen, da $result->body ja den erfolgreichen Download enthält. Ich denke aber, dass diese Rückgabe völlig rfc-konform und daher gleichwertig wie 200 zu behandeln ist. Die if-Anweisung prüft aber auf 310 - und dieser Wert ist als http-Statuscode nicht rfc-konform.


    Andererseits enthält $result->code genaugenommen keinen http-Statuscode, sondern den Returncode des Aufrufs eines Objekts vom Typ JHttpFactory::getHttp - und da mag die 310 sehr wohl einen legitimen Wert darstellen. Ich hab versucht, in der Joomla-Dokumentation weitere Informationen dazu zu finden, bin aber bislang nicht fündig geworden. Ist eigentlich auch nicht mein Job, sondern der der Joomla Entwickler...


    SilOrs67: Wenn du diesen Thread etwas aufmerksamer gelesen hättest, hättest du gemerkt, dass ich hier schon lange keine Hilfe mehr suche, dass mein Problem vielmehr längst behoben ist und dass ich durchaus in der Lage bin, 'ein Update aufzubügeln'.


    Mir geht es hier vielmehr darum mitzuhelfen, die Ursache für das Versagen des Joomla-Updates zu ermitteln. Einmal um anderen zu helfen, die das gleiche Problem für sich noch nicht gelöst haben, zum anderen, um eine allgemeine zukunftsfähige Lösung für dieses Problem zu finden.


    Wenn du in meinen wohlbegründeten Beiträgen hier einen 'unqualifizierten Kommentar' findest, der auch nur näherungsweise an die sehr bescheidene Qualität deines letzten Anwurfs heranreicht - dann darfst du mich noch mal an die Forenregeln erinnern. Bis dahin beherzigst du diese aber bitte selbst!

    https://github.com/joomla/joomla-cms/issues/11806


    https://github.com/joomla/joomla-cms/pull/11845


    @zero24 weiß vielleicht mehr?


    Bzgl. 310: Letztlich kannst ja auch "eigene" Codes aussenden. Vielleicht wird vom ausliefernden Server ein solcher erwartet? (und er liefert diesen nicht?)


    Zitat von herrmann

    Ich hab versucht, in der Joomla-Dokumentation weitere Informationen dazu zu finden, bin aber bislang nicht fündig geworden. Ist eigentlich auch nicht mein Job, sondern der der Joomla Entwickler...


    Na ja, aber User sollten halt entsprechend reagieren, wenn etwas in der Doku fehlen sollte, damit die "Joomla Entwickler" entsprechend reagieren. Dieses 310 läuft bei mir schon länger unter "dubios", hab aber einfach keine Probleme mit Updateservern...

    Danke, das war's. Bei meinem Ubuntu 14.05 LTS war kein php5-curl installiert. Genau das verhält sich so, dass Redirects automatisch gefolgt wird.


    Wäre nur schön, wenn Joomla das selbst herausfinden könnte und den Nutzer nicht mit einem "Download fehlgeschlagen" im Nebel stehen lässt.

    Re:Later: Dass hier vom ausliefernden Server ein "eigener" Code erwartet wird, kann nicht sein. Die Anfrage richtet sich an github, und github richtet die Anfrage per round robin an irgendeinen Server in der amazon-cloud weiter - und da die Joomla-Entwickler auf keinen dieser Server Einfluss haben, haben sie auch keinen Einfluß auf deren Statuscodes.


    Aber egal; wie mizapf schon schrieb: apt-get install php5-curl; service apache2 restart - und die Sache läuft rund!

    Zitat von mizapf

    Wäre nur schön, wenn Joomla das selbst herausfinden könnte und den Nutzer nicht mit einem "Download fehlgeschlagen" im Nebel stehen lässt.


    Aha, also doch Joomla schuld. Hab ich mir fast gedacht ;)


    Weiß nicht, ob ich das schön fände, wenn installierte Software(s) codeseitig so aufgeblasen wäre(n), dass sie auf fehlerhaft konfigurierten und unzureichend ausgestatteten Servern nach diesen oder jenen Fehlerquellen sucht/suchen. Es ist selbstverständlich, dass die wichtigsten PHP-Bibliotheken, darunter Curl, auf einem Server installiert sind.

    Ich hatte eigentlich nicht vor, daraus einen Vorwurf der Art "die sind schuld an allem" zu formulieren. Aber wenn relativ komplexe Software wie Joomla auf der einen Seite umfangreiche Tests schon anbietet, ob alles Wichtige korrekt installiert ist, Berechtigungen stimmen usw. und auf der anderen Seite bei so einem Problem gerade mal ein "Download fehlgeschlagen" ohne sinnvolle Logausgaben abwirft, ja, dann habe ich alles Recht, überrascht zu sein und nach Details zu fragen. :) Ich installiere auf einem Server erst einmal die notwendige Software und mache keinen Rundumschlag nach der Art "irgendwann werde ich es vielleicht mal brauchen". Tests für eine Serverinstallation kannst du meiner Meinung nach gar nicht aufgeblasen genug machen, wenn dadurch mögliche Probleme ausgeschlossen werden können.


    Gut, wenn nicht Joomla dran schuld ist, dann eben Ubuntu. Mir gefällt openSUSE ohnehin besser (da war die curl-Lib automatisch mit installiert). :)

    Die 310 wird schlicht ein Zahlendreher sein. 301 ist 'Moved Permanently', und dieser Code zeigt genauso einen Erfolg an, wie die Codes 200 'OK', 302 'Found' und 303 'See other'.


    Und genau dem entsprechend hat zero-24 seinen Patch-Vorschlag auch formuliert https://github.com/joomla/joomla-cms/pull/11845</a>


    Wir gackern hier also über längst gelegte Eier... Die nur dummerweise ihren Eingang ins Stable Release irgendwie bislang verpasst haben.

    Zitat von herrmann

    Wir gackern hier also über längst gelegte Eier... Die nur dummerweise ihren Eingang ins Stable Release irgendwie bislang verpasst haben.


    Dieses Ei wurde aussortiert: Der PR wurde geschlossen (=closed), ebenso wie das Issue! Deshalb benötigt er/es weiteren Input von Usern, damit er ggf. wieder geöffnet wird (=open), um dann schließlich nach Tests gemerged zu werden, also released. Oder eben nicht...


    Du bist also gefordert, damit es weitergehen kann. Sonst würde ich das schon nicht geschrieben haben.

    mizapf: Ubuntu ist hier nicht verantwortlich zu machen. Ubuntu ist nur verantwortlich für die Packages, die Ubuntu selbst anbietet, und da gehört Joomla nicht zu.


    Es ist ja auch nicht so, dass curl zwingende Installationsvoraussetzung wäre. Der Fehler ist tatsächlich in der Update-Funktion zu suchen und ich vermute, dass der von zero-24 vorgeschlagene Patch allerspätestens irgendwann auch seinen Eingang in den Joomla-Quellcode finden wird.

    Das Problem warum ich meinen PR geschlossen habe ist das wir niemanden gefunden haben der das Testen kann. Bzw. das ganze getestet hat. Da ich keinen betroffenen Server betreibe oder zur Verfügung habe war das eine Idee das Problem zu beheben. Leider betrifft dies nicht viele Installationen wo der Fehler schon mal aufgetreten ist und dann der fix getestet wurde. Wenn gewünscht kann ich den patch nochmal einreichen und Ihr testet dann auf euren systemen ob das Update funktioniert?

    PR wurde wieder geöffnent: https://github.com/joomla/joomla-cms/pull/11845


    Wie man testen kann siehe hier: https://docs.joomla.org/Testing_Joomla!_patches/de
    Patch Tester Erweiterung: https://github.com/joomla-extensions/patchtester/releases

    deGobbis: /etc/php5/apache2/php.ini:allow_url_fopen = On


    zero24: Ich würd's ja testen - aber entweder ist das Test-Repository gerade kaputt, oder ich mach irgendwas falsch. Wenn ich, der Dokumentation folgend, joomla-cms-staging.zip in einen Ordner 'bugtesting' entpacke und die entspr. Adresse aufrufe, bekomme ich nur eine leere Seite angezeigt.


    Gehe ich dagegen hin und entpacke stattdessen testweise die Joomla_3.6.4-Stable-Full_Package.zip in diesen Ordner, bekome ich - erwartungsgemäß - die 'Joomla Webinstallation' angezeigt.