Feed-Import nur noch unvollständig seit Version 5.5

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.

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.

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

Meines Erachtens ist die Bedinung in der Sprachvariable fehlerhaft:

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

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.

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.

Quote from Marcel Werk

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.

Quote from Marcel Werk

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.

Quote from Marcel Werk

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.

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.