Beiträge von SniperSister

    Joomla unterstützt von Haus aus keine Bedingungen für die Anzeige von einzelnen Menüeinträgen. Die einfachste, wenn auch nicht unbedingt schönste Variante wäre:


    1. ein neues Menü anlegen

    2. in diesem Menü genau den einen fraglichen Menüeintrag hinterlegen

    3. für das Menü ein Modul anlegen

    4. mithilfe des Advanced Module Managers (regularlabs) das Modul nur anzeigen lassen, wenn in der fraglichen Kategorie ein veröffentlichter Beitrag ist. Der Module Manager hat dafür keine vordefinierte Bedingung, du kannst dort aber PHP Code hinterlegen und anhand des Ergebnis des Codes das Modul ein- oder ausblenden. Den dafür notwendigen Code kann man sich dann z.B. auch sinnvolerl bei ChatGPT generieren lassen, weil die Zielsetzung klarer ist.

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

    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.