Feed-Import nur noch unvollständig seit Version 5.5

  • Betroffene Version
    WoltLab Suite 5.5
    Betroffene App
    WoltLab Suite Forum

    Die Funktion zum automatisierten Einlesen von Feeds, um daraus Themen im Forum zu erstellen, funktioniert seit Version 5.5 nicht mehr richtig. Ich habe gerade sowohl eine nackte 5.4- als auch eine nackte 5.5-Installation eingerichtet und den Feed in identischer Weise konfiguriert, um eine Besonderheit in meienm Forum auszuschließen. Aber auch dort zeigt sich das Problem.

    Das ist die Feed-Adresse, welche importiert wird: https://sim.sozone.de/transferfeed.xml

    So sahen die Threads in Version 5.4 aus:

    So sehen die Threads in Version 5.5 aus:

    Wie man sehen kann, ist das ein signifikanter Informationsverlust.

    • Offizieller Beitrag

    Hallo,

    seit 5.5 werden die Rich Embeds verwendet. Wenn ich mir die im RSS-Feed ausgewiesene URL https://sim.sozone.de/mannschaft/transfer/details/10865/arminia-bielefeld-cagliari-calcio.html anschaue, so ist das ein ziemlicher Totalschaden. Weder ist das HTML, noch ist das ein vollständiges XML-Dokument, irgendetwas ist auf der Seite ordentlich im Argen.

  • Dass diese Ansicht derzeit (für nicht eingeloggte Nutzer) nicht korrekt arbeitet, ist richtig. Das sollte aber nicht den Import des Feeds komplett zerhauen, es fehlen ja auch sämtliche Text-Inhalte. Die haben nichts damit zu tun, was hinter der URL angezeigt wird, und sind deutlich wichtiger als dass Links schön dargestellt werden.

    Einmal editiert, zuletzt von Cadeyrn (19. Juli 2022 um 20:13)

  • Danke. Damit warst du mir kurzfristig eine sehr große Hilfe! <3

    Meines Erachtens ist die Bedinung in der Sprachvariable fehlerhaft:

    Code
    {if $link && MODULE_URL_UNFURLING}[url]{@$link}[/url]{else}[quote='{@$author}'{if $link},'{@$link}'{/if}]{@$description}[/quote]{/if}

    Wenn MODULE_URL_UNFURLING aktiviert ist, wird der komplette Inahlt verworfen. Das darf nicht sein. Das Rich Embed ist ja an sich in Ordnung - für die Quelle. Das Feld $description hat damit aber nichts zu tun. Es gibt in meinen Augen keinen logischen Grund dafür, das Anzeigen von $description von MODULE_URL_UNFURLING abhängig zu machen.

    Bitte beachten: RSS/Atom sind in erster Linie immer noch, ähnlich JSON, Datenaustauschformate. Natürlich werden Feeds häufig nur genutzt, um Inhalte anzuzeigen, die so sowieso öffentlich zugänglich sind. Aber nicht immer. Mein Beispiel ist insofern ein schönes Beispiel, als dass es ein Beispiel für einen Feed ist, der die Rolle einer Schnittstelle aus einer anderen Applikation in das WoltLab Suite Forum übernimmt und dessen Quelle nicht öffentlich zugänglich ist und wo MODULE_URL_UNFURLING keinen Sinn ergibt, grundsätzlich für das Forum aber aktiviert bleiben soll.

    tl;dr: Feeds beziehen ihre Daten nicht immer aus öffentlichen Quellen und werden häufig einfach als Daten-Schnittstelle verwendet! Das gehört also dringend behoben.

    6 Mal editiert, zuletzt von Cadeyrn (19. Juli 2022 um 20:31)

  • Das darf nicht sein.

    Ich denke, dass war hier leider genau so beabsichtigt. Wie man im Standardwert der Sprachvariable sehen kann ist für den Fall, dass MODULE_URL_UNFURLING nicht aktiviert ist, nämlich der zusätzliche Link zur Quelle entfallen (zurecht, da diese im Zitat verlinkt wird). Demnach war es mMn. nicht beabsichtigt, lediglich den Quellverweis als Rich Embed darzustellen.

  • Das mag schon sein, dass es ursprünglich so beabsichtigt war. Aber ich glaube ehrlich gesagt, dass es bei der Konzeption dieser Änderung überhaupt nicht bedacht wurde, dass Feeds teilweise auch als Schnittstelle verwendet werden und der Quell-Link nicht immer das ist, worum es geht. In Fällen wie diesen ist das das Unwichtigste, da geht es tatsächlich um den Text-Inhalt.

    Wenn man das wirklich so haben will, wie es jetzt umgesetzt ist, braucht es meines Erachtens dafür eine separate Option, die unabhängig von MODULE_URL_UNFURLING ist. Denn nur wegen der Feeds möchte ich das logischerweise nicht für das komplette Forum abschalten.

  • Denn nur wegen der Feeds möchte ich das logischerweise nicht für das komplette Forum abschalten.

    Naja aus diesem Grund hast du ja (zum Glück) die Möglichkeit, die Sprachvariable entsprechend anzupassen.

    Ich denke allerdings auch, dass das Teilen eines Links als Rich Embed mit idR. generischem Seitentitel und generischer Seitenbeschreibung den Zweck der Funktion zur Einbindung von RSS-Feeds verfehlt. Dafür wurden diese nicht konzipiert.

  • Würde das so funktionieren?

    [quote='{@$author}'{if $link},'{@$link}'{/if}]{@$description}[/quote]{if $link}{if MODULE_URL_UNFURLING}[url]{@$link}[/url]{else}Quelle: [url]{@$link}[/url]{/if}{/if}

    Linux: Born to Frag 8) :D

  • Marcel Werk 20. Juli 2022 um 13:56

    Hat das Label Funktioniert wie gewollt hinzugefügt.
  • Ich nehme das zur Kenntnis, auch wenn ich beim besten Willen nicht nachvollziehen kann, wieso es „für die allermeisten Anwendungfälle“ richtig sein soll, sämtliche Informationen außer den Link zur Quelle aus den neu zu erstellenden Beiträgen zu entfernen. Ein hübsches Vorschaubild für den Link (und selbst das funktioniert ja ganz oft nicht, weil das eine entsprechende Auszeichnung der verlinkten Seite voraussetzt) ändert nichts daran, dass nur noch der Link zur Quelle übrig geblieben ist und die tatsächliche Neuerung darin besteht, weniger Informationen als voher anzuzeigen. Das andere ist nur Optik, nichts sonst.

    • Offizieller Beitrag

    Ein Rich-Embed besteht in der Regel aus dem Vorschaubild, dem Seitentitel, der Seitenbeschreibung und natürlich den Link zur Seite. Damit stellt es mehr Informationen zur Verfügung als die alte Lösung und bereitet diese - wie ich finde - zudem hübscher auf.

    Ich sehe ein, dass die Änderung nicht praktikabel ist, wenn man einen RSS-Feed nutzt, der Seiten ohne Daten für das Rich-Embed verlinkt. Das halte ich aber wie gesagt nicht für den Standard-Anwendungsfall der Funktion.

  • Damit stellt es mehr Informationen zur Verfügung als die alte Lösung

    Nach meiner Bastel Aktion um es der alten Lösung näher zu bringen ;)

    wbb.acp.rssFeed.template

    [quote='{@$author}'{if $link},'{@$link}'{/if}]{@$description}[/quote]{if $link}{if MODULE_URL_UNFURLING}[url]{@$link}[/url]{else}Quelle: [url]{@$link}[/url]{/if}{/if}

    Wenn ich die Sprachvariable zurück auf den Standardwert stelle sieht es so aus

    Ich finde in dem Fall die erste Variante wesentlich nützlicher und informativer als die 2.

    Bei Youtube Feeds finde ich die erste Variante auch nützlicher als die 2

    Linux: Born to Frag 8) :D

  • Ein Rich-Embed besteht in der Regel aus dem Vorschaubild, dem Seitentitel, der Seitenbeschreibung und natürlich den Link zur Seite. Damit stellt es mehr Informationen zur Verfügung als die alte Lösung

    Nein, das stimmt einfach nicht. Es mag Fälle geben, in denen das so ist, aber pauschal ist das definitiv nicht zutreffend. Die Seitenbeschreibung ist in den meisten Fällen nicht identisch zum Beschreibungsfeld, zumal die neue Darstellung nur extrem wenig Platz anbietet und alleine deswegen fast immer Informationen verloren gehen. Da bekommt man ja kaum einen einzigen Satz unter. Dazu kommt, dass sowohl Seitentitel als auch Seitenbeschreibung in vielen Fällen generisch sind und gar nicht viel mit dem tatsächlichen Inhalt zu tun haben.

    Nein, die Seitenbeschreibung ist kein Ersatz für das Beschreibungsfeld eines Feeds, ganz und gar nicht.

    bereitet diese - wie ich finde - zudem hübscher auf.

    Ob das hier wirklich hübsch umgesetzt ist, darüber lässt sich streiten, vor allem mit dieser extrem niedrigen Breite, wodurch das ganze Element sehr gestaucht wirkt. Aber das ist vielleicht auch eine Geschmacksfrage. In jedem Fall setzt das eine entsprechende Auszeichnung durch die Website voraus und in ganz vielen Fällen liegt das entweder gar nicht oder nur in einer Form vor, dass daraus nichts Ansprechendes entsteht. Würde das bei allen Websites so hübsch aussehen wie bei eingebetteten GitHub-Links, könnte ich diese Aussage ja nachvollziehen. Das ist aber nicht der Regel-Fall.

    Ich sehe ein, dass die Änderung nicht praktikabel ist, wenn man einen RSS-Feed nutzt, der Seiten ohne Daten für das Rich-Embed verlinkt.

    Das Rich Embed ist für mich überhaupt nicht der Punkt. Der Vorschaulink darf doch gerne in ein Rich Embed umgewandelt werden. Dagegen sage ich überhaupt nichts. Es geht darum, dass das Rich Embed das Beschreibungsfeld nicht ersetzt. Das Rich Embed soll den Link schöner aufbereiten. Mit dem Beschreibungsfeld hat das Rich Embed schlicht und ergreifend nichts am Hut.

    De facto sorgt eure Umsetzung dafür, dass der Feed-Import nur noch Links anzeigt und nichts sonst.

    ---

    Natürlich kann man die Sprachvariable ändern und das habe ich auch gemacht. Ich bin glücklich darüber, dass das so einfach geht. Für mich ist und bleibt das aber ein konzeptioneller Fehler, das einfach vorauszusetzen, dass man nur am Link interessiert wäre, insbesondere wenn das vorher anders war und das auch nicht kommuniziert wurde. Ja, Rich Embeds in den Feeds wurden angekündigt. Aber mit keiner Silbe wurde erwähnt, dass Inhalte entfernt wurden. Und ich wäre definitiv niemals von alleine darauf gekommen, dass das über Sprachvariablen geändert werden kann.

    Was ich mir übrigens sehr gut vorstellen könnte, wäre ein „Template“-Feld in der Feed-Konfiguration. Im Beschreibungstext könnten dann alle variablen Feldnamen stehen, die man verwenden kann, und dann könnte man sich individuell pro Feed das so bauen, wie man es braucht. Dann wäre es für mich auch weniger relevant, dass der Standard nur noch Links vorsieht, weil dann jeder Administrator direkt bei der Einrichtung eines Feeds sieht, welche Möglichkeiten er hat - und es bietet deutlich mehr Flexibilität. Mein Anwendungsfall zum Beispiel würde mir ohne Zitat-Block besser gefallen, während für andere Anwendungsfälle der Zitatblock sinnvoll ist. Das ist vielleicht einen separaten Vorschlag wert.

  • Das Erstellen von Themen mit nur einem einzelnen Link als Inhalt ist für ein Forum wie ich finde auch nicht sinnvoll. RSS-Feeds kommen einem Forum u.A. dadurch zugute, dass sie regelmäßig neue Inhalte bereitstellen. Natürlich müssen diese fremden Inhalte ganz klar mit einem Quellverweis versehen werden, aber mit der Bereitstellung des Feeds stellt der Urheber diese bewusst (außer die Verbreitung wird explizit ausgeschlossen) für solche Zwecke zur Verfügung (Stichwort: Content-Syndication). Selbst wenn ein Anbieter nur eine Vorschau und nicht den vollständigen Inhalt bereitstellt, weil dieser auch ein paar Besucher verzeichnen möchte, ist das immer noch mehr als die aus der Seitenbeschreibung abgeleitete Beschreibung eines Rich Embed hergeben kann.

    Im Kontext eines Forums tragen über RSS-Feeds abgerufene Inhalte eben vor allem dazu bei, ein Forum für seine Nutzer aktiv und ansprechend zu halten, sowie diese Nutzer zur Diskussion der Inhalte zu animieren. Letzteres funktioniert deutlich besser, wenn die Nutzer das Forum nicht erst verlassen müssen, um diese Inhalte zu sehen und Teile des Inhalts bspw. auch schneller und einfacher zitieren können. Ich behaupte: Mehr Inhalt -> Mehr Traffic -> Mehr Aktivität.

    Zu guter Letzt gibt es auch noch ein weiteres Problem mit Rich Embeds, wenn ein Anbieter den Seitentitel und die Seitenbeschreibung nicht dynamisch anpasst. Das ist immer noch sehr oft und vor allem bei weniger redaktionell aufbereiteten Inhalten der Fall und macht den "Inhalt" des Themas dann komplett wertlos. Warum das kein "Standard-Anwendungsfall" sein soll erschließt sich mir nicht, da ich mir nicht aussuche ob ein Anbieter Daten für das Rich Embed bereitstellt.

    Counter-Strike: Global Offensive
    Counter-Strike: Global Offensive (CS:GO) expands upon the team-based action gameplay that it pioneered when it launched in 1999.
    blog.counter-strike.net

    Ich habe den CS:GO Blog (Wordpress) mal als Beispiel für ein Changelog eines Spiels genommen, da solche Inhalte nach meinem Empfinden recht häufig als RSS-Import verwendet werden. Es lassen sich aber natürlich auch Beispiele mit Seiten wie "XY's Life-Blog" machen, deren Titel und Beschreibung häufig statisch ist.

  • Was ich mir übrigens sehr gut vorstellen könnte, wäre ein „Template“-Feld in der Feed-Konfiguration. Im Beschreibungstext könnten dann alle variablen Feldnamen stehen, die man verwenden kann, und dann könnte man sich individuell pro Feed das so bauen, wie man es braucht. Dann wäre es für mich auch weniger relevant, dass der Standard nur noch Links vorsieht, weil dann jeder Administrator direkt bei der Einrichtung eines Feeds sieht, welche Möglichkeiten er hat - und es bietet deutlich mehr Flexibilität. Mein Anwendungsfall zum Beispiel würde mir ohne Zitat-Block besser gefallen, während für andere Anwendungsfälle der Zitatblock sinnvoll ist. Das ist vielleicht einen separaten Vorschlag wert.

    Also in etwa so wie es der Community Bot macht?

    Linux: Born to Frag 8) :D

  • Im Prinzip ja. Wobei das gar nicht so komplex sein muss und ein einfaches Eingabefeld mit ein paar wenigen unterstützten Feldbezeichnungen, die in einem kurzen Einleitungssatz erwähnt werden, für die allermeisten Anwendungsfälle ja schon ausreichend sein dürfte.

  • Würde das auch gern ändern das die Beiträge wieder korrekt angezeigt werden. Bei der 5.5 heißt der template dann nur noch rssFeed ist das korrekt?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!