Wegfall des Kompatibilitäts-Modus ab späterer J5 oder nachfolgender J6 Version - Warnung vor dem Update

    • Neu

    Meine Frage richtet sich an die Entwickler und Projektverantwortlichen der Joomla-Gemeinde:


    Irgendwann wird ja der Komp-Modus in einer späteren Joomla Version entfallen. Mit einem Update wäre dieser Modus dann nicht mehr vorhanden und ich stelle mir die Frage, ob vor Ausführung des dann folgenden Updates ein Hinweis eingeblendet wird, der als Warnung deutlich macht, dass der Komp-Modus mit diesem Update entfällt und alle nicht bis dahin angepassten Erweiterungen und Plugins die Joomla-Installation im schlimmsten Fall so beeinflussen, dass eine Anmeldung im Backend nicht mehr möglich ist.


    Hatten wir ja schon einige Beispiele, wo wir den Komp-Modus zum Test deaktiviert hatten und einzelne Erweiterungen oder Plugins dann den Zugang zum Backend gesperrt haben. Den Komp-Modus über die DB wieder aktivieren ist aber nach dem Update nicht mehr möglich, da es Ihn ja nicht mehr gibt ;)


    Letztlich bliebe dann nur noch das Backup wieder einzuspielen, was natürlich ärgerlich wäre.


    Vielleicht weis schon jemand, was in dieser Richtung geplant wird...


    Freu mich über euer Feedback.

    • Neu
    Zitat von bembelimen

    Einfach nichts nutzen, was das Plugin voraussetzt...

    Denke du machst nur einen Witz... oder ich habe meine Frage nicht verständlich formuliert :/


    Die Frage bezog sich nicht auf "sein oder nicht sein..." sondern darauf, ob dann ein klar formulierter Hinweis vor Durchführung des Updates eingeblendet wird. Thema Sensibilisierung der User.

    • Neu

    Voraussichtlich wird ja mit J6 das derzeitige Kompatibilitäts-Plugin wegfallen. Wahrscheinlich wird uns nichts anderes übrig bleiben, als (wie bei der Migration von J3 nach J4 und von PHP 7 auf PHP 8) jede einzelne Erweiterung abklopfen zu müssen:

    • Sind die Angaben im JED verlässlich?
    • Was sagt der Entwickler?
    • Im Zweifelsfall wird nur ein Test auf einer Testplattform endgültigen Aufschluss geben.
    • Neu
    Zitat von bembelimen

    Einfach nichts nutzen, was das Plugin voraussetzt...

    Woher soll ich das (als Nicht-Coder) denn wissen? Stimmen die Angaben im JED? Wie verlässlich sind Aussagen der Entwickler meiner Erweiterungen?


    Ich finde, die obige Aussage ist ein wenig hochnäsig. Nicht jeder kann sich für alles ein Override oder eine eigene Erweiterung schreiben.

    • Neu

    bembelimen hat wie ein Entwickler geantwortet, was ich durchaus nachvollziehen kann.


    Das ist aber für die Fragestellung zu wenig. Die schlechten Migrations-Erfahrungen vieler User mit J3 nach J4 sollten aber zum Anlass genommen werden, es besser und einfacher zu machen. Dies meine ich nicht technisch sondern organisatorisch und Informativ. Kann ja kein Problem sein entsprechende Hinweise einzublenden und Handlungsempfehlungen (Leitfaden) anzugeben.


    Nicht jeder Joomla Admin tummelt sich täglich in Joomla Foren herum und ist auf Informationen im richtigen Moment angewiesen.


    Wunderbar wäre natürlich eine Prüfung in Joomla, welche Erweiterungen ready sind bevor ich den Update-Button drücke aber mir ist auch die Problematik einer solchen Umsetzung durchaus bewußt.

    • Neu
    Zitat von WM-Loose

    Wunderbar wäre natürlich eine Prüfung in Joomla, welche Erweiterungen ready sind bevor ich den Update-Button drücke aber mir ist auch die Problematik einer solchen Umsetzung durchaus bewußt.

    Gibts doch schon lange (seit 3.10):


    Zitat von WM-Loose

    Kann ja kein Problem sein entsprechende Hinweise einzublenden und Handlungsempfehlungen (Leitfaden) anzugeben.

    Joomla! ist OpenSource, wenn du denkst irgendwo soll ein Text erscheinen, kannst du es hier vorschlagen: https://github.com/joomla/joomla-cms/issues

    Handlungsempfehlungen gibts auch immer für jedes Update: https://docs.joomla.org/Portal:Upgrading_Versions/de

    Zitat von Dautrich

    Woher soll ich das (als Nicht-Coder) denn wissen? Stimmen die Angaben im JED? Wie verlässlich sind Aussagen der Entwickler meiner Erweiterungen?


    Ich finde, die obige Aussage ist ein wenig hochnäsig. Nicht jeder kann sich für alles ein Override oder eine eigene Erweiterung schreiben.

    Naja, erkennt man ja, wenn man seine Seite kopiert und dann in der Kopie das Plugin deaktiviert. Dann sieht man was nicht kompatibel ist.

    • Neu

    Die Entwickler haben sich ziemlich viel Arbeit mit allen möglichen Prüfungen gemacht und auch bei den Dokumentationen wurden zahllose Stunden aufgewendet.
    Zum Beispiel hier: https://docs.joomla.org/Joomla…d_Upgrade_Step_by_Step/en
    Leider liest niemand mehr, weder die Meldungen auf screens und schon gar nicht die Dokumentation.

    Zitat

    Woher soll ich das (als Nicht-Coder) denn wissen? Stimmen die Angaben im JED? Wie verlässlich sind Aussagen der Entwickler meiner Erweiterungen?

    Das stimmt, aber dafür gibt es die vielen Releases von alpha, beta, rc .. damit jder das auf seiner kopie schon vorher testen kann.

    Das gilt zumindest für alle, die beruflich Webseiten entwicklen und betreuen.
    Für die "normalen" user müsssen wir hier im Forum bereit stehen.

    • Neu
    Zitat von WM-Loose

    Irgendwann wird ja der Komp-Modus in einer späteren Joomla Version entfallen. Mit einem Update wäre dieser Modus dann nicht mehr vorhanden und ich stelle mir die Frage, ob vor Ausführung des dann folgenden Updates ein Hinweis eingeblendet wird, der als Warnung deutlich macht, dass der Komp-Modus mit diesem Update entfällt und alle nicht bis dahin angepassten Erweiterungen und Plugins die Joomla-Installation im schlimmsten Fall so beeinflussen, dass eine Anmeldung im Backend nicht mehr möglich ist.

    Christiane und bembelimen haben ja schon den Update-Checker auf Erweiterungs-Ebene erwähnt. Wenn ich dich richtig verstehe, würdest du da jetzt gerne noch einen zusätzlichen Hinweis vor dem Update haben, ob das Compat-Plugin akiv ist - und falls ja, soll da dann ein Hinweis erscheinen? Oder soll das Update komplett blockiert werden?

    • Neu
    Zitat von bembelimen

    Naja, erkennt man ja, wenn man seine Seite kopiert und dann in der Kopie das Plugin deaktiviert. Dann sieht man was nicht kompatibel ist.

    Dass man das so machen kann, ist mir schon klar. Aber das ist die Methode "Trial & Error". Überspitzt formuliert heißt das: "Wir als Core Entwickler kümmern uns um den Core und um dessen reibungslose Updates. Wer so dumm ist, irgendwelche Erweiterungen einzusetzen, muss halt selbst sehen, wie er klarkommt!".


    Wir als Joomla-Community laufen hier sehenden Auges in die gleiche (Update-) Katastrophe wie beim "Update" von J3 auf J4. Das wird wieder viele (Noch-) Joomler in die Arme von WP treiben, wo das alles angeblich viel einfacher funktioniert.


    Letztlich steht der Anwender im Regen und muss sich selbst kümmern. Ich komme damit schon klar: Ich werde mir wieder eine schöne große Excel-Tabelle bauen mit einer Kreuzreferenz, welche Erweiterung ich auf welcher Website nutze. Und für jede Erweiterung einen Test machen, welche Einstellung vom b/c-Plugin noch geht und welche nicht. Und erst dann ans Update gehen, wenn alle Ampeln grün sind.


    Es wäre allerdings schön, wenn es da Unterstützung gäbe, z.B.:

    • Ein kleines Tool, das per SQL das b/c-Plugin in der Datenbank wieder aktiviert, nachdem es gekracht hat. Damit weniger versierte Benutzer sich nicht beim Reparaturversuch ihre Datenbank komplett zerschießen.
    • Eine Beispiel-Tabelle, wie ich sie oben beschrieben habe, um die Übersicht bei Umstellungen zu behalten.
      (Ich werde in den nächsten Wochen mal für mich solch eine Tabelle erstellen und bin gerne bereit, das Ergebnis für die Community bereitzustellen.)
    • Neu

    Vielleicht habe ich es zu kompliziert erklärt.

    Zitat von SniperSister

    Wenn ich dich richtig verstehe, würdest du da jetzt gerne noch einen zusätzlichen Hinweis vor dem Update haben, ob das Compat-Plugin akiv ist - und falls ja, soll da dann ein Hinweis erscheinen? Oder soll das Update komplett blockiert werden?

    Mit geht es darum, dass wenn das Plugin irgenwann in einer kommenden Version nicht mehr existiert (also quasi mit Update auf Joomla-xyz...) vor Update auf diese Joomla-Version ein Hinweis /Warnung eingeblendet wird, dass alle Erweiterungen und Plugins welche den Compat-Modus benötigen nicht mehr funktionieren und ein Zugang zum Backend nach dem Update unter Umständen nicht mehr möglich ist.


    Soweit sogut. Jetzt hat die updatewillige Person diesen Hinweis gelesen und keine Ahnung welche seiner Erweiterungen und Plugins diesen Compat-Modus benötigen :/ Wie auch, denn es steht ja nirgendwo ein Hinweis im Backend, wo ich z.B. bei Erweiterungen /Verwalten ein Hinweis auf need Compat-Mode ja oder nein.



    Dann sollte man eine Prüfung starten können (so wie bei der Migration von J3 auf J4), indem Erweiterungen und Plugins aufgelistet werden, die ohne dieses Compat-Plugin nicht mehr funktionieren. Ein Update auf Joomla-Version ohne das Compat-Plugin wird dann im besten Fall solange gesperrt, bis die aufgelisteten, nicht geeigneten Erweiterungen /Plugins deaktiviert wurden.


    Natürlich wird bei der Migration eine Prüfung durchgeführt (ich habe ja schon einige Seiten ;) von 3 auf 5 migriert) aber hier wird ja auch das Compat-Plugin mit installiert und direkt aktiviert. Ich schaue halt schon mal in die nähere Zukunft, wenn es dieses Plugin nicht mehr geben wird.


    Ich hoffe dass ich es jetzt richtig erklärt habe.

    • Neu
    Zitat von WM-Loose

    Soweit sogut. Jetzt hat die updatewillige Person diesen Hinweis gelesen und keine Ahnung welche seiner Erweiterungen und Plugins diesen Compat-Modus benötigen :/ Wie auch, denn es steht ja nirgendwo ein Hinweis im Backend, wo ich z.B. bei Erweiterungen /Verwalten ein Hinweis auf need Compat-Mode ja oder nein.

    Die spannende Frage dabei ist ja: woher kommt die Information, welches Plugin den Compat Modus braucht? Dieses Problem haben wir auch schon beim "normalen" Update-Check.


    Der aktuelle Modus ist: der Entwickler der jeweiligen Erweiterung schreibt in seine Extension (genauer: in seinen Update-Server) rein, welche Joomla-Versionen er unterstützt. Daraus ergibt sich im Update-Checker (und ggf. auch in so einer neuen "Needs Compat Plugin"-Spalte) 3 verschiedene Ausgaben:


    1. JA

    2. NEIN
    3. Keine Ahnung, der Entwickler ist nicht mehr da oder haut keine Info dazu raus


    Jetzt ist die Frage: wie geht man mit dem dritten Fall um? Genau das ist ja auch der Fall, der allen Beteiligten bei der normalen Migration Probleme macht.

    Leider gibt es auch keine zuverlässige Variante, die Nutzung des Compat-Plugins "zur Laufzeit" zu ermitteln. Jede Variante, die mir da einfällt (Aufrufe ins Compat Plugin aufzeichnen und über den Callstack nachschauen, woher sie vielleicht gekommen sind; Code des Drittplugins nach auffälligen "mustern" durchsuchen) ist letztlich unzuverlässig - der Core müsste da also eine Aussage treffen auf die ein Anwender sich dann verlässt und dann trotzdem auf die Nase zu fallen.


    Daher auch meine Alternatividee: wir könnten ja das Update von 5.x auf 6.x im Update Checker verweigern, so lange das Plugin noch aktiv ist. Der Nutzer wird dann gezwungen es zu deaktivieren und wenn dann was knallt sieht er es sofort - und kann diese Änderung noch relativ simpel über die DB (oder ein von Dautrich vorgeschlagenes Script) wieder rückgängig machen.

    • Neu
    Zitat von SniperSister

    Daher auch meine Alternatividee: wir könnten ja das Update von 5.x auf 6.x im Update Checker verweigern, so lange das Plugin noch aktiv ist. Der Nutzer wird dann gezwungen es zu deaktivieren und wenn dann was knallt sieht er es sofort - und kann diese Änderung noch relativ simpel über die DB (oder ein von Dautrich vorgeschlagenes Script) wieder rückgängig machen.

    Das halte ich für eine sehr gute Idee. :thumbup:

    • Neu
    Zitat von SniperSister

    Daher auch meine Alternatividee: wir könnten ja das Update von 5.x auf 6.x im Update Checker verweigern, so lange das Plugin noch aktiv ist. Der Nutzer wird dann gezwungen es zu deaktivieren und wenn dann was knallt sieht er es sofort - und kann diese Änderung noch relativ simpel über die DB (oder ein von Dautrich vorgeschlagenes Script) wieder rückgängig machen.

    In der Praxis werden die meisten User das Plugin wohl deaktivieren und anschließend das Update starten, ohne die Webseite vorher nochmal auf mögliche Probleme zu untersuchen. Ich mag mich auch täuschen. Müsste man also explizit nochmal dazuschreiben, dass die Webseite nach der Deaktivierung auf Inkompatibilitäten untersucht werden müsste.

    • Neu
    Zitat von JoomlaWunder

    In der Praxis werden die meisten User das Plugin wohl deaktivieren und anschließend das Update starten, ohne die Webseite vorher nochmal auf mögliche Probleme zu untersuchen. Ich mag mich auch täuschen. Müsste man also explizit nochmal dazuschreiben, dass die Webseite nach der Deaktivierung auf Inkompatibilitäten untersucht werden müsste.

    Korrekt. Ob's dann gemacht wird ist zwar eine ganz andere Baustelle, aber zumindest der Hinweis schadet ja nicht ;)

    • Neu

    Hi,


    ich bin da sowas von bei dir! Habe, bevor ich hier selbst aktiv geworden bin, 40+ Artikel zu dem Thema gelesen und mir schon sehr an den Kopf langen müssen.


    Nur mal so: Ich bin überzeugt davon, dass Joomla! eine erstklassige Option für die Schnittstelle zwischen Webdev und Webdesign ist und im Vergleich zu WP deutlich vielfältiger ist. Zumindest ist das mein Ersteindruck nach 3 Tagen Deep Dive.


    So manche Dinge werden einem dann aber doch sehr schwierig gemacht. Und mit den Joomla!-Meistern hier bin ich auch nur semi-zufrieden. Manche hier haben den "Reddit-Geruch".


    Mein Mantra mittlerweile: Wenn die Extension nicht zwingend gebraucht wird: Raußschmeißen!

    Meine Lösung ist jetzt: Eine Test-Domain für unsere Vereins-Website, eine neue Datenbank-Instanz und dort rum-experimentieren.

    Joomla! hat eine entsprechende Lernkurve, aber sie hat eine. xD Meine bisherige Erfahrung ist: Schwierige Lernkurve = Es lohnt sich am Ende.

    Ich hoffe mal, dass sich das bewahrheitet und ich nicht die Nerven verliere. :D


    Alles in Allem: Joomla! bräuchte wohl einen etwas strengeren "Vetting-Prozess" für die Schreiberlinge von Extensions.

    NPM musste das auch irgendwann machen, weil Browser-Extensions explodiert sind und sie gemerkt haben, dass das zu nem Haufen an Sicherheits-Risiken führt. Software Bills of Material haben schon was für sich. Aufwendig aber wichtig.


    LG Nicolas

    • Neu
    Zitat von NioDor
    ..... Joomla! bräuchte wohl einen etwas strengeren "Vetting-Prozess" für die Schreiberlinge von Extensions ...... Software Bills of Material haben schon was für sich. Aufwendig aber wichtig.
    1. "Schreiberlinge" ist sicher nicht der richtige Ausdruck. Und mit Strenge wird man wohl auch nicht weiterkommen. Ich glaube eher, dass es mehr Dialog zwischen Core- und Extension-Entwicklern geben sollte, damit das gegenseitige Verständnis hergestellt bzw. verbessert wird. Die Entwickler von Extensions müssen verstehen, warum manche Dinge im Core anders gelöst werden (müssen), als bisher gewohnt. Und die Core-Entwickler sollten die Anforderungen, Sorgen und Nöte der Entwickler von Erweiterungen kennen und verstehen. Wenn das gelingen würde, wäre Joomla einen wichtigen Schritt nach vorne gegangen.
    2. SBMs sollten meiner Meinung nach auf jeden Fall auf der Task List der Release Manager und Core-Entwickler stehen (auch wenn sich dort viele Tasks vor wenigen Freiwilligen auftürmen).
    • Neu
    Zitat von Dautrich
    1. "Schreiberlinge" ist sicher nicht der richtige Ausdruck. Und mit Strenge wird man wohl auch nicht weiterkommen. Ich glaube eher, dass es mehr Dialog zwischen Core- und Extension-Entwicklern geben sollte, damit das gegenseitige Verständnis hergestellt bzw. verbessert wird. Die Entwickler von Extensions müssen verstehen, warum manche Dinge im Core anders gelöst werden (müssen), als bisher gewohnt. Und die Core-Entwickler sollten die Anforderungen, Sorgen und Nöte der Entwickler von Erweiterungen kennen und verstehen. Wenn das gelingen würde, wäre Joomla einen wichtigen Schritt nach vorne gegangen.

    Das klingt nach einem No-Brainer ist in der Praxis aber herausfordernd.


    Kernproblem ist, dass das Interesse der Drittentwickler, dass ich mal mit "alles bleibt wie es ist" zusammenfassen will, in fundamentalem Widerspruch zu einem explizit so formulierten Kernziel von Joomla steht, nämlich:

    "Adapting the latest technologies to the core product to be innovative and renewing as a platform."


    Joomla hat einen Innovationswillen also gewissermaßen in der DNA, für Drittentwickler hingegen bedeuten Änderungen im Core auf den ersten Blick nur Arbeit. Auf den zweiten Blick profitieren sie zwar auch davon, aber da der Markt für Extension-Entwickler in den letzten jahren durchaus herausfordernd war und jegliche Core-Änderung dann als zusätzliche Zumutung dazu kam, sind die Fronten da teils verhärtet.


    Das zweite Problem in dem Kontext ist ein ganz praktisches: es ist super schwer die Drittentwickler für eine Kommunikation überhaupt zu erreichen. Das Projekt bittet z.B. gebetsmühlenartig darum, dass Drittentwickler sich am CMS Testing beteiligen und dabei insbesondere zu frühen Alpha und Beta Versionen Feedback geben, damit man Probleme, die in Sachen Kompatibilität auftreten können, frühzeitig angehen kann. In der Praxis tun das aber leider verschwindend wenige. Auf Core-Entwickler-Seite gibt es da manchmal den Eindruck, dass sich Extension-Entwickler als Konsumenten betrachten: vom Ergebnis profitieren, aber mit der Entwicklung nichts zutun haben wollen.

    Ich weiß natürlich dass das zumindest für einen Teil nicht zu trifft, aber es erklärt vielleicht die Dünnhäutigkeit die es da manchmal auf beiden Seiten geht.


    Zitat von Dautrich
    1. SBMs sollten meiner Meinung nach auf jeden Fall auf der Task List der Release Manager und Core-Entwickler stehen (auch wenn sich dort viele Tasks vor wenigen Freiwilligen auftürmen).

    Das Thema ist auf dem Radar und das Projekt bemüht sich, die Anzahl der verwendeten Drittlibraries so gering wie irgend möglich zu halten.