Beiträge von SniperSister

    Ich hatte gestern früh mal kurz den Impuls den Thread zu zu machen, jetzt bereue ich es nicht getan zu haben.

    Lasst mich mal versuchen, hier einen Strich drunter zu ziehen:

    Ursprungsproblem: das Update einer 3.x Seite auf 4.x ist gescheitert. Der Thread-Ersteller hat versucht einen lauffähigen Zustand wiederherzustellen und dafür erst einen Restore des Dateisystems und dann einen Restore der Datenbank beim Hoster beauftragt. Beim Dateisystem-Restore wurden dabei die Dateien der 3.x und 4.x Version zusammengeführt, was zu einem Zombie-Zustand geführt hat.

    Danach wird's, zumindest für mich, im Thread was die Sachebene angeht etwas unübersichtlich: ich verstehe @NioDor so, dass es danach sowohl mehrere Versuche gab, die gescheiterte Instanz wieder lauffähig zu kriegen als auch einen sauberen Restore zu machen. Der saubere Restore (wie im zweiten Post des Threads vorgeschlagen) scheint dann, wenn ich mir das Ergebnis betrachte, wohl auch funktioniert zu haben.

    Diskussionen auf Meta-Ebene: losgelöst von der Diskussion zum Grundproblem (Seite nach Update kaputt) gab's diverse Meta-Diskussionen:

    • Warum lädt Joomla nach einem Rollback noch alte Dateien? Antwort: es gab hier keinen sauberen "Rollback", also eine Wiederherstellung von Dateisystem und Datenbank im Pre-Update Zustand, sondern einen partiellen Restore, der zu einem "Zwischenzustand" mit Dateien aus beiden Versionen geführt hat. Das kann prinzipbedingt keine stabile Seite geben.
    • Warum gibt es in Joomla keine Rollback Funktion bei einem gescheiterten Update? Antwort: das ist nicht so trivial und scheitert an der technischen Komplexität und fehlenden Volunteers, die das implementieren
    • Warum deaktiviert Joomla nicht "einfach" Extensions, die Fehler verursachen? Antwort: das ist nicht einfach :)

    Persönliche Ebene:

    Liebe Supporter: ja, die Lösungsfindung war mühselig weil es viele, für die Problemstellung irrelevante Nebendiskussionen und eine ausgeprägte Suche nach einem Schuldigen gab. ABER: ein "tja, da bist du halt selber Schuld" ist ebenfalls kein Beitrag zur Lösungsfindung. Spart euch Posts dieser Art bitte in der Zukunft, denn sie sind für jemanden, der hier vielleicht das erste mal HIlfe sucht, eine negative Erfahrung die die Wahrnehmung von Joomla nachhaltig beeinträchtigen kann.

    Lieber NioDor: ich verstehe den Frust, den ein gescheitertes Update mit sich bringt. Wenn dann noch das etwas merkwürdige Restore-Verständnis des Hosters dazu kommt und einem die Kiste endgültig zerschießt, macht es das noch schlimmer. In der Gesamtbeschau hast du es den Supportern hier aber wirklich nicht leicht gemacht, weil du Tipps nicht oder nicht konsequent umgesetzt hast und parallel noch selber diverse Reparaturversuche (Stichwort "englisches Forum") gestartet hast, die die Situation dann verschlimmern. Bitte versuch hier in Zukunft, themenorientierter zu agieren und die Anweisungen der Support umzusetzen.

    Würde sowieso gerne mehr dazu lernen. Auch z.B. warum man mehr mit .php als .js arbeitet.

    PHP ist im Kontext des Zielmarkts die mit Abstand verbreiteste serverseitige Interpretersprache.

    Warum man quasi alles in eine Datenbank wirft und diese dann zum SPoF (Single Point of Failure) werden kann für den Zweck einer Website-Darstellung.

    Du kannst Nutzdaten auch ins Dateisystem schreiben, dann ist halt das Dateisystem der SPoF.

    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.

    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.

    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 ;)

    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.

    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?

    Das Google Authenticator MFA Plugin heißt in Joomla 4+ "Multi-Faktor-Authentifizierung – Verifizierungscode" weil es verschiedene Anbieter (nicht nur Google) unterstützt, die das TOTP Protokoll unterstützen. Soweit ich weiß hat Entrust in unendlicher Weisheit aber beschlossen, diesen offenen Standard nicht zu verwenden, sondern irgendeinen hauseigenen Kram gebaut.

    Die Einstufung des BSI basiert vermutlich darauf, dass zwei der Lücken für XSS Angriffe genutzt werden können und ein XSS Payload, wenn er mit Admin-Rechten ausgeführt wird, im Grunde genommen eine Remote-Code-Execution ist.

    Nur einer der beiden Angriffe kann aber überhaupt ohne erweiterte Rechte ausgeführt werden und das erfordert bestimmte Bedingungen und liefert nur einen sehr schmalen Vektor, daher auch unsere Einschätzung als "High", die sich aus dem Score von 7,5 ableitet.

    Der Pixel und die Conversion API haben eine entscheidende Gemeinsamkeit: sie machen nur dann Sinn, wenn sie zielgerichtet eingebunden sind. Was meine ich damit?

    Der Umstand, dass ein reiner Pageview passiert (also ein Nutzer der von Facebook kam, deine Seite aufruft) hilft dir nur mäßig weiter. Du willst ja wissen, ob er etwas getan hat, was für dich einen relevanten Mehrwert hat, also eine Kontaktanfrage gestellt hat, was gekauft hat, deine Telefonnummer angeklickt hat etc.

    Diese Art von Events können im Kontext von Joomla ja aber sowohl im Core als auch in jeder beliebigen Dritterweiterung auftreten - und hier wirds spaßig: wie soll ein Entwickler eines solchen Conversion-API-Plugins denn vorab wissen, mit welcher Dritterweiterung du deine Kontaktformulare baust? Oder anhand welcher Interaktion sich ein "Verkauf" ergibt?

    Ich sehe da keine generische Lösung für.

    Die Visforms Entwickler nutzen nicht die von Joomla vorgesehenen Methoden um JS und CSS an die Seitenausgabe anzuhängen (Stichwort "Web Asset Manager") sondern gehen ihren eigenen Weg. Dadurch kann Joomla keine passenden Nounces generieren und eine strikte CSP verhindert die korrekte Ausführung. Die richtige Lösung ist, dass Visforms ihre Ausgabe anpasst, die Alternative ist das Erlauben von unsafe-inline.