Es gibt einen Pull Request der es Erweiterungen ermöglicht, den Update-Prozess zu stoppen wenn bestimmte Bedingungen (z.B. ein aktuelles Backup der Seite liegt vor) nicht erfüllt sind:
Wir hatten zuerst überlegt, eine Logik zu bauen die es Erweiterungen erlaubt hätte, langlaufende Prozesse (wie z.B. ein Komplettbackup) laufen zu lassen, davon dann aber letztlich doch Abstand genommen, weil es bedeutet hätte, dass der Update-Prozess einer Seite nicht mehr 10 Sekunden dauert, sondern vielleicht 30 Minuten und wir dadurch ein großes Skalierungsproblem bekommen.
Ich finde es gut, dieses Thema sachlich und nicht ideologisch anzugehen....
Ich denke für Backups sorgt jemand der es ernst meint eh von selber. Da sehe ich (für mich) weniger ein Problem.
Interessanter finde ich eher die Frage wie die Einbindung von Erweiterungen erfolgt. Müssen Entwickler ihre Erweiterungen als geeignet erklären und was passiert wenn sie das nicht tun? Wird das Update aufgrund von unklaren Kompatibilitäten zurückgehalten mit der Aufforderung selber zu prüfen oder wird es eine Möglichkeit geben, das auch Leute aus der Comunity oder dem Coreteam Erweiterungen 'freigeben' können?
Interessanter finde ich eher die Frage wie die Einbindung von Erweiterungen erfolgt. Müssen Entwickler ihre Erweiterungen als geeignet erklären und was passiert wenn sie das nicht tun? Wird das Update aufgrund von unklaren Kompatibilitäten zurückgehalten mit der Aufforderung selber zu prüfen oder wird es eine Möglichkeit geben, das auch Leute aus der Comunity oder dem Coreteam Erweiterungen 'freigeben' können?
Die automatischen Updates in Joomla 5.4 beziehen sich ausschließlich auf Core Updates!
Erweiterungsupdates sind nochmal ein ganz eigenes Thema, weil hier, ähnlich wie zu Beginn beim Core, erstmal ein Grundproblem in Sachen Security zu lösen ist: wie stellt man sicher, dass ein angebotenes Updates wirklich vom Entwickler kommt? Stell dir vor, bei einer populären Erweiterung wird der Update-Server gehackt und ein bösartiges Update veröffentlicht - in Kombination mit automatischen Updates ist dann ein Albtraumszenario! Für den Core haben wir das mit TUF gelöst, für Erweiterungen ist die Integration bereits vorbereitet, aber wir suchen noch eine gute Möglichkeit, wie wir Drittentwicklern beim Verwalten der Signaturschlüssel unterstützen können.
Es ist aber auf der Agenda.
Wird vor dem automatischen Backup eine Mail an den Superuser versendet, indem man durch Freigabe im Content der Mail (Link) das Update freigeben kann?
Der verlinkte Pull Request würde genau das erlauben: man könnte ein Plugin programmieren, dass den ersten automatischen Updateversuch erstmal ablehnt und die Mail an den Admin verschickt. Klickt der auf den fraglichen Link, dann würde der zweite Updateversuch durchlaufen.
Der verlinkte Pull Request würde genau das erlauben: man könnte ein Plugin programmieren, dass den ersten automatischen Updateversuch erstmal ablehnt und die Mail an den Admin verschickt. Klickt der auf den fraglichen Link, dann würde der zweite Updateversuch durchlaufen.
Denke auch dass dieses Plugin eine sehr gute Lösung wäre. Wie immer wäre dann aber das eigentliche Problem, wer fühlt sich für die Programmierung des Plugin verantwortlich. Ich traue mich kaum zu fragen, da ich sowas selbst nicht kann. Vielleicht gibt es hier Entwickler:innen, die solch ein Plugin erstellen könnten und dann auch gerne kostenpflichtig anbieten möchten.
Der verlinkte Pull Request würde genau das erlauben: man könnte ein Plugin programmieren, dass den ersten automatischen Updateversuch erstmal ablehnt und die Mail an den Admin verschickt. Klickt der auf den fraglichen Link, dann würde der zweite Updateversuch durchlaufen.
Hey David,
das Abfangen, Versenden der E-Mail und Verarbeiten des aufgerufenen Links ist klar.
Wie genau kann man aber diesen "zweiten Updateversuch" manuall im Plugin anstoßen? (sorry, habe mir die Implementation noch nicht im Detail angeschaut)
> Wie genau kann man aber diesen "zweiten Updateversuch" manuall im Plugin anstoßen? (sorry, habe mir die Implementation noch nicht im Detail angeschaut)
Der Update-Server macht regelmäßig erneute Versuche 
da musst der Extension Dev sich nicht drum kümmern
Der Update-Server macht regelmäßig erneute Versuche
Ah, das ist ja nice. Hmm, vielleicht schreibe ich so ein Plugin, hört sich auf jeden Fall nützlich an.
Der Update-Server macht regelmäßig erneute Versuche
Nehme da jetzt konkret von Dir Viktor: ECCPlusPro. Gerade geschaut.
Zeigt, dass es nun eine 5.2.4.0-PRO Update (seit gestern) gibt. Und Ja, hat vorhin geklappt.
Eine (unwissende) Frage von mir: "Versuche der Extension Dev" bedeutet genau what?
Da müsste doch der "Update Server" einer (egal welche) Erweiterung aktuell sein, oder?
Wegen Kümmern und so
Liebe Grüße
Christine
Hallo Christine,
ich verstehe schon, wie das funktioniert. Mir ging es nur darum, ob man nach dem Klick in der E-Mail das Update direkt anstoßen muss oder ob das System es selber noch mal versucht.
Zu deiner Frage: David meinte damit, dass ein Entwickler, der so ein Plugin schreibt, sich nicht um den eigentlichen Update-Prozess kümmern muss.
Ah, das ist ja nice. Hmm, vielleicht schreibe ich so ein Plugin, hört sich auf jeden Fall nützlich an.
Das wäre wirklich klasse Viktor.
Ich möchte gestehen, dass ich kein Fan von automatischen Updates bin.
Daher meine Frage: Updatet sich nach der Aktualisierung auf 5.4 irgend etwas im Hintergrund automatich, oder muss ich dazu erst irgendwo etwas aktivieren?
Danke der Faro
Daher meine Frage: Updatet sich nach der Aktualisierung auf 5.4 irgend etwas im Hintergrund automatich, oder muss ich dazu erst irgendwo etwas aktivieren?
Bei Neuinstallationen ist das Feature standardmäßig an (und kann deaktiviert werden), bei Updates ist standardmäßig deaktiviert und muss manuell eingeschaltet werden
Bei Neuinstallationen ist das Feature standardmäßig an (und kann deaktiviert werden), bei Updates ist standardmäßig deaktiviert und muss manuell eingeschaltet werden
Danke SniperSister für die Info. Beste Grüße der Faro
So als Idee:
Ablauf wäre dann folgender:
Das kann man ja noch weiter ausdehen, da ja vor finalen Releases 1-x Release Candidates veröffentlicht werden, die man auf Dev-Seiten automatisiert testen kann (=> Einstellbar in den Optionen der Update-Komponente). Eventuell auch mithilfe der Konsole:
Oder man nutzt günstig einen Service wie BackupMonkey 
Ob man wirklich weiterhin seine Seiten manuell aktualisieren will, wenn man doch recht viele technische Möglichkeiten hat, das zu automatisieren?
Zunächst Danke an bembelimen . Dös ist mir zu schwer
Seit gestern bin ich am Testen des PRs #2.
Derzeitiger Stand: 1/2 erfolgreich ...
Mit toller Hilfe - (wir hatten auch Nachtdienst von SniperSister
Gab so einige Hoppalas z.B. mit Host usw. halt ....
Ob der 2. Teil nun gelingt, weiß ich noch nicht. Muss da irgendwie neue Installation schaffen oder so ........
Liebe Grüße
Christine
So, neuester Stand:
Gestern Nacht versucht, den 2. Teil des PRs zu vollbringen.
Geschafft habe ich nur einen Teil (in ein neues Joomla) mit dem angegebenen Package.
Server Probleme (das Übertragen via FTP). Auch der Mail Server ging in die Knie und bin jetzt schwach
Wie/wann ich da was weiterbringe, weiß ich (noch) nicht.
Liebe Grüße
Christine
Update der verworrenen Situation:
Endlich neues Jooma mit dem J 5.4.0-alpha3-dev .... Paket plus Prevent Plugin usw. installiert. Davor waren die oben erwähnten FTP Probleme. Das ist jetzt nur Kurzversion
Beim Aktivieren von: Automated Updates bekam und bekomme ich schon wieder die Fehlermeldung.
Der Grund: Hoster blockiert den Update Server.
SniperSister David, der Arme, ist da die Kummer-E-Mail Nummer ... Dankes Grüße an ihn!
Wiederholt dem Hoster geschrieben:
Die IP ..... gehört zum Update-Server des Joomla Projekts (joomla.org) und muss daher permanent freigegeben werden. Der Server führt regelmäßige Status Checks durch und aktualisiert Joomla-Seiten, es handelt sich folglich um automatisierte Prozesse.So ähnlich hab ich vorhin auf Github geschrieben.
Liebe müde Grüße
Christine
Ich erhalten bei der Aktivierung der Auto-Updates diese Meldung:
Error while registering to automated update service: cURL error 28: Failed to connect to fc-test.de port 443 after 5001 ms: Timeout was reached (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for ...