Link zu Tag-Seite mit mehreren Tags/Schlagwörtern nicht korrekt verarbeitet

  • Hallo Joomlaner,

    ich baue mir gerade eine Liste mit Beiträgen gleicher Tags wie im angezeigten Artikel als eigenes Modul. Man kann dabei einstellen, wieviele Artikel maximal angezeigt werden sollen und dann soll es ggf. einen "alle anzeigen"-Link geben, der einfach auf die com_tags-Seite geht, die dann alle Artikel mit den gesuchten Tags anzeigt.


    Mein Problem ist die Generierung dieses Links bzw. dass dieser SEF-konvertiert wird, damit aber com_tags nicht mehr umgehen kann:

    - ich entnehme den Joomla-Menüs die folgende Bauweise: index.php?option=com_tags&view=tag&id[0]=2&id[1]=3

    - das generiere ich in meinem Modul aus den Tags und es funktioniert, wenn ich es einfach per echo ausgebe und im Browser als Adresse eingebe.

    - Nutze ich den Link in <a href="[link]"> geht der Joomla-Router drüber und macht /component/tags/tag/2,3 draus. Dem entnimmt com_tags aber nur die erstgenannte Tag-ID, die anderen werden ignoriert. Ebenso, wenn ich bei nicht-SEF-URL "&id=2,3" schreibe statt des kompletten Arrays. Habe gelesen, dass eigentlich beides funktionieren sollte (erster Kommentar hier)... also ein Bug?


    Kann jemand von euch das Problem nachvollziehen? Habe es in Joomla 3.9.6 getestet, scheint unabhängig vom template.


    Habt ihr Ideen, wie ich das Problem umgehen kann? Kann ich z.B. in meinem Modul verbieten, dass der generierte Link in diesem Einzelfall konvertiert wird? Will eigentlich nicht wegen dieser einen Sache die SEF-Links auf der kompletten Seite abschalten...


    Vielen Dank für eure Hilfe!

    Waldbär

  • OK, nach ausbleibender direkter Antwort habe ich mal selbst in der Komponente rumgesucht. Es findet sich in components/models/tag.php Zeile 180f wie folgt:

    Code
    1. // Load state from the request.
    2. $ids = ArrayHelper::toInteger($app->input->get('id', array(), 'array'));

    Offenbar funktioniert das direkte "toInteger" nicht mit den Komma-separierten id-Listen sondern killt alles nach dem ersten Komma (genau mein Problem).

    Folgender edit macht das Ganze bei mir funktionsfähig mit beiden Schreibweisen und unabhängig von der Zahl der übergebenen Parameter:

    Code
    1.         // Load state from the request.
    2. $ids = $app->input->get('id', array(), 'array');
    3. if (count($ids) == 1)
    4. {
    5. $ids = explode(',', $ids[0]);
    6. }
    7. $ids = ArrayHelper::toInteger($ids);

    Ich bin aber ganz sicher niemand von den sonderlich erfahrenen Entwicklern hier - hat jemand von euch eine bessere Lösung? Sollte ich das mal im Joomla! Issue Tracker melden (hab ich noch nie gemacht, aber mit firstlady s Tutorial sollte ich das hoffentlich hinbekommen)?


    Vielleicht gibt es auch eine Lösungsidee ohne im Core rumzupfuschen? Bisher habe ich auf meiner kleinen Bastler-Site immer schön alles über Extensions/Overrides lösen können und würde eigentlich gerne weiterhin updatefähig bleiben... ;-)


    PS@Mod: Vielleicht doch nach Komponenten- oder Modulentwicklung verschieben? Ich wusste leider nicht so recht, in welchem Unterforum das Topic am besten angesiedelt ist... pardon

  • PS@Mod: Vielleicht doch nach Komponenten- oder Modulentwicklung verschieben? Ich wusste leider nicht so recht, in welchem Unterforum das Topic am besten angesiedelt ist...

    Dafür kannst Du in Zukunft das schwarze Dreieck "Inhalt melden" verwenden. Habe nur durch Zufall Dein @Mod gelesen.

  • OK, nach ausbleibender direkter Antwort

    Weil sich mit diesem blöden Teil, also com_tags, keiner so recht auskennt oder auskennen will, weil total verquast. Im besten Fall lebt man damit ;-) ;-)


    Ich glaube aber in Joomla 4 hat das jemand neu aufgegriffen und baut die um.


    EDIT: Ja, hat, aber ist noch "Work In Progress". Siehe https://github.com/joomla/joomla-cms/pull/24551


    Zitat:

    Zitat

    Tagging right now also has issues with routing that can not be really fixed in a B/C way. Trying to fix this here, too.


    But most annoyingly the code is just plainout crap.

    Soll dich nicht vom Einreichen abhalten, aber die Chancen sind in Joomla 3 vermutlich gering, dass da noch gefixt wird.

  • Hm, OK. Den Beitrag habe ich auch gefunden, aber leider kaum was verstanden (was ist UCM? Hat es was hiermit zu tun? Habe keine Ahnung von Coding-Standards, fange jetzt mit Joomla gerade so an mich in ein paar Sachen allmählich reinzulesen wie MVC, selbst beim Umgang mit Klassen bin ich aber nach wie vor unsicher...). Vielleicht ist in den "routing bugs" ja auch meiner mit gemeint?

    Damit leben will ich nicht, v.a. nicht weil ich ja mittlerweile eine (wenn auch vielleicht nicht schöne, aber funktionierende) Lösung habe. 8o

    Damit muss ich aber jetzt nach jedem Joomla-Update die Datei wieder neu bearbeitet an ihren Platz schieben, oder ist die Update-Automatik (Web/direkt schreiben) bei sowas irgendwie differenzierter?

  • UCM (Unified Content Model) ist gaaanz grob ausgedrückt (ich bin kein Akademiker) im Fall von Joomla Funktionalitäten und Inhalte mehrerer Komponenten zusammenzufassen und damit angeblich leichter erweiterbar zu machen sowie angeblich leichter in eigenen Erweiterungen zu verwenden. Bei Tags/Schalgworten zeigt sich das z.B., dass ja mehrere Bereiche in Joomla mit Tags versehen werden können (Kategorien, Beiträge, Kontakte usw. usf.). Dabei werden die Schlagworte, egal welche, als sichbarstes Anzeichen des UCM in ein und den selben Datenbanktabellen abgelegt.


    Das Ganze war aber, zumindest im Falle Joomla, ein Luftschloss, weil es nie mehr war als ein zu voreilig aufgepropfter und immer umstrittener Ansatz, der weder fertig- noch weitergedacht wurde und generell von der Codierung her teils "ziemlich weg von Joomla-Programmierer-Denke" ist. Es gab dann noch paar "unschöne Internas", die irgendwie jegliches Interesse verpuffen ließen.


    Leider konnte man das aber nicht so einfach wieder rückgängig machen, wegen versprechen zur rückwärtskompatibilität ("B\C") von Joomla-Version zu Joomla-Version.

    Damit muss ich aber jetzt nach jedem Joomla-Update die Datei wieder neu bearbeitet an ihren Platz schieben, oder ist die Update-Automatik (Web/direkt schreiben) bei sowas irgendwie differenzierter?

    Wenn die Datei im Update-Paket enthalten ist, also geändert wurde durch das "Joomla-Team" wird sie überschrieben.Spätestens, wenn der Copyright-Hinweis in den Dateien auf neues Jahr gestellt wird. Wenn nicht enthalten, dann nicht.

  • Vielen Dank für die Infos! Interessant zu lesen. Sind die Custom Fields eigentlich angesehener, die sind doch auch vergleichbar konstruiert, oder?

    Bisher schien mir der Ansatz mit den content-unabhängigen Inhalten eigentlich auch immer recht geschickt (abgesehen davon, dass man ziemlich viele Datenbankabfragen und/oder joins braucht, um seine Daten zusammenzusuchen), aber vermutlich muss man mehr damit arbeiten, um die Vor- und Nachteile wirklich beurteilen zu können.

    Zumindest habe ich jetzt schon einen Tick mehr verstanden, aber wenn ich da ernsthaft anfange zu entwickeln, kommt mit Sicherheit nur wieder ein „Horrible mess“ raus. chinese


    Ich werde also konkret erst mal zusehen, dass ich bei Updates meinen Fix wieder reinbaue bzw. prüfe ob er zerstört wurde. Werde ihn mal in den issue tracker posten, vielleicht lerne ich so ja wenigstens mal das Prozedere da kennen...

  • Esrtelle in deinem Modul den Link so

    Code
    1. $link = 'index.php?option=com_tags&view=tag&id[0]=4&id[1]=2&id[2]=3';
    2. $link = JUri::root() . $link;

    Dann ist der Link "sicher", weil z.B.

    Code
    1. https://example.org/index.php?option=com_tags&view=tag&id[0]=4&id[1]=2&id[2]=3

    daraus wird. Das wird dann ignoriert und nicht durch den Router geschickt.


    EDIT: Generell Sch... ist dann alerdings, dass auch deaktivierte Schlagworte berücksichtigt werden und welche im Papierkorb. Sollte dich ja aber nicht tangieren.

  • Vielen Dank für die Idee! Damit ist das Problem nicht nur behoben (dazu müsste ja der Core in com_tags gefixt werden/s.o.), sondern auch praktisch umgangen, auch wenn ich dazu eine Extra-CSS-Regel auf die (HTML-Attribut-)id des Links brauche, die den Link wieder als internen erscheinen lässt - nicht toll, aber praktischer als bei jedem Update neu checken zu müssen, ob mein Core-Fix noch lebt.

    Danke auch für die Warnung bezgl. deaktivierten Schlagworten. Es scheint da ja wirklich so einige Merkwürdigkeiten zu geben...

    Alles in allem: Danke für deine Hilfe! beer

  • auch wenn ich dazu eine Extra-CSS-Regel auf die (HTML-Attribut-)id des Links brauche, die den Link wieder als internen erscheinen lässt

    Dann probier mal

    Code
    1. $link = JUri::root(true) . '/' . $link;

    Ist dann ohne Domain, aber mit "vor-rooter-schützendem" Slash.

    Code
    1. /index.php?option=com_tags&view=tag&id[0]=4&id[1]=2&id[2]=3

    Rest erledigt Browser, der das als internen Link interpretiert