Beiträge von SniperSister

  • Suchindex sprengt die Datenbank - Frage nach Alternative

    Wir betrachten das mal systemtisch:


    Es gibt zwei grundverschiedene Arten, wie man eine Volltextsuche wie die von Joomla gestalten kann:


    1: Suche zur Laufzeit: du gibst einen Begriff ein und im Moment des Absendens werden die Inhalte nach dem fraglichen Textschnipsel durchsucht. Ist relativ simpel in der Implementierung, braucht keinen doppelten Speicherplatz weil man ja nur die Originalinhalte braucht. Ist aber dafür auch seeeehr langsam und bestimmte Funktionen wie Vertipper-Prüfung ("Meinten Sie...") oder Autocompletion sind damit nicht sinnvoll implementierbar.


    2. Suche mit einem Index: dabei werden die Inhalte in Einzelbegriffe zerlegt, Füllwörter und Wortvarianten werden raus genommen und es entsteht eine Art Liste, welches Wort sich in welchem Beitrag findet. Das ist wesentlicher schneller, bietet viel mehr Möglichkeiten, bedeutet aber halt auch zwangsläufig, dass man den Speicherplatz für die Wortliste (Beim Joomla-Suchindex: #__finder_terms) und die Zuordnung zur den Beiträgen (#__finder_terms_links) braucht.


    Du kannst über Anpassung der Einstellungen von com_finder die Indexierung beeinflussen und zum Beispiel einstellen, dass wirklich nur einzelne Wörter und keine Wortgruppen im Index abgelegt werden (Einstellung "Suche nach Phrasen" im Reiter Index). Das reduziert den Speicherbedarf, ist aber für die Ergebnisqualität nachteilig.


    Mit dieser Einführung im Hinterkopf lässt sich dann auch deine Frage beantworten: egal welche lokal installierte Lösung du verwendest, sie wird bei einem so großen Datenbestand entweder recht langsam sein (Laufzeitsuche) oder recht viel Speicher beanspruchen (Indexsuche).

  • Upgrade to 4.x nicht erfolgreich. Joomla!-Backend größtenteils kaputt.

    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.

  • Upgrade to 4.x nicht erfolgreich. Joomla!-Backend größtenteils kaputt.

    Zitat von NioDor

    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.


    Zitat von NioDor

    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.

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

    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.

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

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

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

    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.

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

    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?

  • 2 Faktor Authentifizierung mit Entrust Identity App und Token - ab J4 Anmeldung über Google Authenticator vermisst

    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.

  • EInschätzung Risiko unterschiedlich (J! vor 5.0.3/4.4.3)

    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.