Beiträge von Waldbaer

Ich fürchte, da musst du händisch selbst debuggen, denn zumindest mir ist gerade nicht klar, was genau das Problem ist bzw. wo es passiert. Irgendwelche Fehlermeldungen bei der Ausgabe oder passiert einfach nix?

Wenn ich dich richtig verstanden habe, möchtest du an jedes Menüitem "&nr=15" anhängen. Das sollte

$item->flink .= '&nr=' . $UID;

innerhalb des foreach eigentlich machen. Wenn das nicht klappt, ist die Frage wo es nicht klapp, also gib deine Variable mal per var_dump($item->flink); oder print_r($item->flink); vor und nach der Zeile aus. Dann weißt du zumindest, ob die Zeile macht, was du willst. Wenn ja, ist halt die Frage, was weiter damit passiert - folge dem flink durch die Layout-Dateien.

Danke auch für diesen vereinfachenden Tipp, funktioniert!

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!

Yay, gleich mal voll versagt: Hier ist das Issue, aber habe es nicht mal auf die Reihe bekommen ihm com_tags als Kategorie zu geben (unter edit kriege ich das nicht mehr hin):

https://issues.joomla.org/tracker/joomla-cms/24980

Vielleicht kann ich heute Abend was daran weitermachen (z.B. Code anhängen o.ä.); jetzt muss ich erst mal arbeiten.

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.

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

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.

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?

Hallo Sven,

ich steige zwar gerade nicht durch alle Details deines Problems (und des Modul-Overrides), aber vielleicht helfen meine zwei Tips auch schon weiter:

1. deine Zeile 14 sollte vermutlich in das foreach (d.h. frühestens Zeile 28), sonst ist ja das "$item" (vermutlich der jeweilige Menüpunkt) gar nicht klar.
2. Außerdem glaube ich, dass der erste "." in derselben Zeile genaugenommen ein ".=" sein müsste (bedeutet "an String-Wert anhängen"), sonst macht die Zeile gar nix, was sie überdauert (fügt Strings zusammen ohne sie zu speichern).

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:

        // Load state from the request.
        $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:

        // Load state from the request.
        $ids = $app->input->get('id', array(), 'array');
        if (count($ids) == 1)
        {
            $ids = explode(',', $ids[0]);
        }
        $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...

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

Vielen Dank für deine Antwort! Hast du auch getestet, ob er noch meckert, wenn du zwar in den anderen Feldern etwas angibst, aber nicht beim Captcha? Du scheinst ja auf jeden Fall schon mal mein Problem verstanden zu haben und eine Idee zu haben, wie man sowas testet (würde ich trotz deiner Hinweise jetzt wieder Stunden rumwerkeln dran, fürchte ich).

Mit Leerzeichen wäre das Captcha übrigens in meinem Fall schon nicht mehr ausgehebelt worden, aber trotzdem danke für den Tip mit onValidateContact, da komme ich ggf. gerne mal drauf zurück!

Zitat von JoomlaWunder

.....und zudem auch die Option "Kopie an Absender" deaktivieren, falls noch nicht geschehen! Diese wird meist für solche Geschichten missbraucht.

Jep, das habe ich auch gemerkt und dann jetzt auch gemacht, auch wenn ich es schade finde, dass es nötig ist - wenn ich jemanden kontaktiere, nutze ich die immer gern.

Ansonsten ging es mir aber nicht darum, Empfehlungen für Captcha-Plugins zu bekommen, sondern darum, dass ich den Eindruck hatte, dass der Joomla Core an dieser Stelle unnötig verwundbar ist: Weil er bei eingeschaltetem Captcha offensichtlich nicht mehr prüft ob tatsächlich eine Eingabe für dieses vorliegt wenn er die Mail sendet, sondern nur wenn man im Formular auf "absenden" klickt. Anders kann ich mir schlecht erklären, warum ich eine Fehlermeldung bekomme, wenn ich das Captcha nicht ausfülle (und die nicht vorhandene Eingabe dann gar nicht an dieses weitergeleitet wird zur Prüfung), aber der Bot offensichtlich mit leerem Wert für das Captcha durchkommt, sodass dieses den Leerwert erst händeln muss.

Gibt es einen guten Grund für dieses Verhalten oder haltet ihr es für schlicht egal? Könnt ihr es ggf. aus eigener Erfahrung bestätigen oder ist es womöglich ein Problem innerhalb meiner Installation?

Ich habe leider auch keine Ahnung, wie ich einen solchen Angriff selbst simulieren könnte, deswegen sind meine Aussagen leider gerade von der Angriffslust eines scheinbar verrückten Chinesen abhängig und nicht eindeutig belegbar. Wenn ihr also Tips habt, wie ich das beschriebene Verhalten selbst reproduzieren könnte, sind die auch willkommen.

Hallo Joomla-Community,

ich hatte vereinzelte Spam-Nachrichten über meine Kontaktseite bekommen und mir daraufhin (kein Bock auf Google) ein kleines Captcha-Plugin gebastelt. Daraufhin sind ist die Zahl der SPAM-Nachrichten explodiert statt kleiner zu werden. Nachdem ich eine Logging-Funktion in mein Plugin eingebaut hatte, habe ich sehr schnell gemerkt, dass die durchgehenden Anfragen überhaupt keine/komplett leere Antworten enthielten.

Natürlich lässt sich das (wenn man es erst mal rausbekommen hat) gut abfangen, aber ich wundere mich, dass diese Anfragen überhaupt bis zu meinem Captcha-Plugin kommen. Wenn ich normal über das Formular anfrage zum Testen, wird das ja auch nicht akzeptiert. Scheinbar bei direkten (automatisierten) Server-Anfragen dagegen schon? Ich bin ja alles andere als ein Profi, darum wage ich erst mal noch nicht öffentlich darüber zu urteilen...

Was denken die erfahreneren Webentwickler unter euch darüber? Kann das Problem jemand nachvollziehen? Danke für eure Antworten!

Ich habe eure Vorschläge jetzt mal ausprobiert. @firstlady's geht natürlich, würde eben nur Updates der internen Übersetzung nicht einbeziehen (kann auch ein Vorteil sein, wie du ja zurecht schreibst).

Das mit dem Spezialfeld funktioniert jetzt auch, finde ich sehr hübsch und ist ein Hack, der sich sicher im Hinterkopf zu behalten lohnt. Zwei Anmerkungen dazu:

• getInput() wird benötigt. Erstens sind direkt innerhalb von Klassen nur Funktionen und Konstanten erlaubt, zweitens wird von Joomla intern bei Feldern offenbar die Methode mit genau diesem Namen aufgerufen (Namensänderung und schon gibt's Errors statt Ausgabe).
• Aufpassen: Das Spezialfeld muss in der Manifestdatei direkt am Anfang bzw. vor Verwendung des ersten verwendeten Strings stehen, sonst wird die Datei geladen, aber sie nützt scheinbar nichts (zumindest nicht für vorher stehende Sprachstrings)

Vielen Dank für eure Hilfe!

Overrides funktionieren, ja, aber ich würde das Modul gerne so wartungsarm wie möglich halten und nicht noch darauf angewiesen sein, dass man auch noch manuell Overrides einpflegt (selbst wenn es nicht viele sind).

Die andere Rangehensweise mit dem Spezial-Feld ist ja ziemlich ausgefuchst - werde ich mal ausprobieren und mich dann noch mal melden. Vielen Dank schon mal für den Tip!

Hallo Re:Later,

vielen Dank für deine schnelle Antwort. Sowas hatte ich tatsächlich auch schon gefunden, aber wo füge ich das denn ein? Für das Backend habe ich beim Modul ja gar keine eigene .php, sondern nutze nur die <fields> in der .xml... wenn ich es in die Haupt-.php des Moduls einfüge hat es im Schnelltest (ohne Neuinstallation des Moduls) auch nichts gebracht. Ich nehme mal an, die .php wird überhaupt nicht geladen, wenn man im Backend die Einstellungen des Moduls öffnet, oder? Nur da fehlen mir aber die Strings...

Hallo,

ich habe noch ein kleines Problemchen, bei dem mir hoffentlich jemand helfen kann. Ich würde gerne in der Backend-Konfiguration meines Moduls in Feldern Sprachstrings aus internen Sprachdateien nutzen. Bei einem hat das direkt super funktioniert, bei zwei anderen leider nicht, weil die zugehörige Datei wohl an der Stelle nicht geladen wird - wie kann ich das ändern?

Konkret geht es z.B. um COM_CONTENT_FIELD_PUBLISH_DOWN_LABEL, dieser String befindet sich in administrator/language/xx-XX/xx-XX.com_content.ini. Im Sprach-Debug-Mode wird diese Datei unter den geladenen nicht aufgeführt - ich nehme an, das ist der Grund, warum die entsprechenden Strings nicht umgewandelt werden können. Wie kann ich also dafür sorgen, dass die doch geladen wird?

Ich habe versucht, sie folgendermaßen in der XML unter languages einzubinden, das hat aber trotz reinstallation des Moduls nix geholfen, sondern nur zu einer Fehlermeldung bei der Installation geführt:

<languages folder="administrator/language/">
  <language tag="en-GB">en-GB/en-GB.com_content.ini</language>
  <language tag="de_DE">de-DE/de-DE.com_content.ini</language>
</languages>

Hab ich hier was verbockt oder macht man das einfach anders?

Einmal mehr vielen Dank für eure Hilfe!

OK, über dem Problem mit den optional auszufüllenden Feldern/Custom Fields habe ich jetzt so einige Stunden gebrütet, gesucht, probiert und mich geärgert, aber es schließlich und tatsächlich hinbekommen.

Die Lösung ist, kein ->where zum Feld-Filtern zu benutzen, sondern die Bedingung gleich als AND in den join zu bauen. Dann funktionieren auch inner- bzw. left-join wie man es erwarten sollte (bzw. ich es erwartet habe). Die von dir (Christiane) im Tutorial gezeigte und oben angedeutete Variante mit ->where funktioniert grundsätzlich auch, aber eben nur mit Pflichtfeldern, die wiederum auch mit meiner Version gut funktionieren. Der Einheitlichkeit zuliebe würde ich darum meine nehmen.

Hier ein funktionierender Minimalcode zum Abruf von Artikeltiteln samt zwei Feldern (eins Pflicht, eins optional auszufüllen):

// Wir wollen den Wert der zwei Felder (Custom Fields) und den Titel des Artikels
$query   ->select( [
    $query->qn('fv1.value', 'feld1'), //Beispiel Pflichtfeld
    $query->qn('fv2.value', 'feld2'), //Beispiel optional auszufüllendes Feld
    $query->qn('a.title', 'titel')
  ])

// Gesamttabelle erstellen aus Artikeln...
->from($query->qn('#__content', 'a'))

// ...und feld1 -  Pflichtfeld nur Schnittmenge/innerjoin
->innerjoin(
    $query->qn('#__fields_values', 'fv1')
     // Felder, die zum Artikel gehören
    . ' ON (' . $query->qn('a.id') . ' = ' . $query->qn('fv1.item_id')
    // nur feld1 anhängen
    . ' AND ' . $query->qn('fv1.field_id') . ' = ' . $feld1id .')'
    )

// feld2 an die Gesamttabelle anhänge - da optinal auch ohne Treffer zulassen/leftjoin
->leftjoin(
  $query->qn('#__fields_values', 'fv2')
  // Felder, die zum Artikel gehören)
  . ' ON (' . $query->qn('a.id') . ' = ' . $query->qn('fv2.item_id')
  // nur feld2 anhängen
  . ' AND ' . $query->qn('fv2.field_id') . ' = ' . $feld2id . ')'
)

// ggf. weiter filtern mit ->where(), sortieren mit ->order() oder Ergebnis begrenzen mit ->setlimit()

// am Schluss der Query-Bastelei das Semikolon nicht vergessen ;-)
;

//Ergebnis holen
return $db->setQuery($query)->loadObjectList();

Hallo Christiane,

vielen Dank für deine Antwort. Deinen Code kann ich nachvollziehen, und bin nach ein paar Stündchen probieren und recherchieren schon deutlich weiter gekommen.

Habe nach einigem Suchen $query->__toString() gefunden um mal zu schauen, was die Klasse da eigentlich so bastelt. Dabei ist mir aufgefallen, dass sie bei deinem Code einfach bei FROM direkt beide #__fields_values hinschreibt, also komplett ohne Join. Habe dann das zweite ->from gelöscht und das zweite ->join statt noch mal mit #__content umgebaut zu "'#__fields_values', 'fv2'". Der Query von ->__toString scheint mir nun logischer und liefert auch die richtigen Ergebnisse.

Einziges verbleibendes Problem ist, dass es nur Ergebnisse liefert, wo beide Felder einen Wert enthalten. 'key2' soll aber optional sein. Wie bekomme ich es hin, dass auch Zeilen angezeigt werden, wo kein 'key2' existiert? Left- und rightjoin helfen beide nicht (warum? Sind die nicht genau dafür da?), outerjoin gibt einen SQL-Syntax-Error (Joomla-Bug oder muss ich da in der übergebenen Bedingung tatsächlich etwas anpassen?).

Danke im Voraus an dich oder möglicherweise auch jemand anderen, der sich einklinkt! Wenn jemand noch weitere Codebeispiele möchte, sagt mir gerne was ihr braucht...

Grüße

Waldbaer

Hallo Joomla-Community,

ich habe hier gerade ein Problem: Mittels dieses hervorragenden Blogbeitrags zum Thema (vielen Dank an firstlady!) weiß ich nun, wie ich eine Liste Artikel erstelle mit einem verknüpften Custom Field. Jetzt würde ich gerne mehrere anzeigen (z.B. jeweils zwei verschiedene Custom Field Werte, die zum selben Artikel gehören) und stoße auf das Problem, dass ich dem Tabellenfeld fieldvalues.value unterschiedliche (Alias-)Namen geben muss je nach FeldID, damit sie sich im Ergebnis nicht überschreiben, sondern dann hübsch einzeln über das Ergebnis-Objekt-Array verwenden lassen. Geht das überhaupt noch in einer DB-Abfrage? Oder wie geht man da ran?

Wäre super, wenn mir einer von den erfahreneren hier auf die Sprünge helfen könnte!

Vielen Dank im Voraus!

Der "Blog", d.h. die Blog-Ansicht, dient in dem Seitenbereich nur der Vorschau/Übersicht, die Texte sind allesamt mit "weiterlesen" beschnitten. Dafür ist dann deren Einzelansicht. Es ist eine Liste von Projekten, die man daher auch einzeln direkt per Untermenü ansteuern kann.

Wie möchtest du das mit Hauptbeiträgen umsetzen? Eine Unterscheidung zwischen Haupt und Nebenbeiträgen gibt es in der Kategorie nicht (alle Projekte praktisch gleichwertig). Für so eine Übersichtsseite schien mir die Blogansicht bisher am geeignetsten, oder würdest du eine andere empfehlen?