Um die Jahrtausendwende startete der RSS-Feed und im Zuge von Web 2.0 hat er in den folgenden Jahren immer mehr Verbreitung gefunden. Aber da er schlecht zu monetarisieren war, wurden wichtige Produkte, wie der Google Reader wieder eingestellt. Auch der von Google gekaufte Feed-Optimierer Feedburner wird nur stiefmütterlich behandelt.
Für viele ältere Internetnutzer ist der RSS-Feed aber wie E-Mail, Usenet, IIRC vielleicht nicht mehr besonders populär, aber immer noch ein wichtiges Werkzeug und nicht wegzudenken.
Leider hat WordPress seine Wurzeln vergessen und hat den Feed nicht nur nicht weiter verbessert, sondern ist dabei ihn aktiv kaputtzumachen.
Ein Bericht über die Probleme und mögliche Lösungen.
Das Problem ist mir erstmalig aufgefallen, als ich in meinem Feedreader den Blog eines Kollegen anschaute und mich wunderte, dass die Icons am Ende riesengroß waren. Zuerst dachte ich an ein Problem mit der Darstellung von SVG-Bildern. Aber auch in einem Blog einer großen WordPress-Agentur zeigten sich Fehler im Feed und so machte ich mich auf die Suche nach den Ursachen.
Grundproblem #1: Kein CSS im Feed
Das Problem im Blog des Kollegen lag daran, dass die Icons in vier Spalten gesetzt waren. Nun werden die Spalten in WordPress-Blöcken ja per CSS umgesetzt. CSS wird im Feed aber nicht mit ausgegeben. Daher werden die Spalten mit 100 % Breite ausgegeben, was bei den SVG-Icons dazu führte, dass sie bildschirmfüllend angezeigt wurden.

Das betrifft natürlich nicht nur Spalten, sondern auch alle anderen Blöcke, die nur mit CSS korrekt funktionieren. Zum Beispiel Buttons, Abstandshalter, … und sicher noch ein paar mehr.
Manchmal ist nicht die komplette Funktion betroffen, sondern nur eine bestimmte Darstellung. Drop Caps werden nicht angezeigt und auch sämtliche Anpassungen von Schriftgrößen oder Ausrichtungen werden nicht umgesetzt, da sie auf CSS basieren.
Grundproblem #2: Kein Javascript im Feed
Wenn ein Button eine Interaktion via JavaScript im Frontend auslöst, dann ist auch diese Interaktion, aufgrund des fehlenden JavaScript im Feed natürlich nicht funktional. Per AJAX nachgeladene Blogartikel zum Beispiel, wie in dem Fall der großen WordPress-Agentur.


„Load More“ ist nicht nur nicht übersetzt, sondern hat hier natürlich keine Funktion, da der Button via JavaScript Artikel nachlädt, was im Feed natürlich nicht funktioniert.
Beide Probleme liegen letztendlich daran, dass der Feed-Kontext nicht bedacht wurde, was in der Anzeige oder in der Funktionalität die Fehler erzeugt. Und das passiert hier einem klugen Kollegen, der sich mit der Materie gut auskennt und einer großen WordPress-zentrierten Agentur. Das liegt unter anderem daran, dass das Core-System uns nicht davor schützt, solche Fehler zu begehen.
Mögliche Lösungen?
Blöcke ausblenden?
Nun stellt sich natürlich die Frage, was es für Lösungen gibt (oder geben könnte). Wir könnten manche Blöcke im Kontext von Beiträgen (und somit von Feeds) schlicht nicht erlauben. Wäre es vielleicht zu verschmerzen, wenn wir den Spalten-Block einfach nicht mehr in Beiträgen benutzen könnten? Oder den Abstandshalter? Oder Buttons?
Blöcke aus dem Feed entfernen?
Und wenn das komplette Entfernen vielleicht doch zu viel ist, bei der riesigen Menge an Use Cases im WordPress-Ökosystem: Wie wäre eine zusätzliche Funktion, die es erlauben würde, einzelne Blöcke aus dem Feed zu entfernen, weil sie dort sowieso nicht funktionieren würden?
Dazu habe ich ein „Proof of concept“-Plugin gebaut. Es ist aktuell auf GitHub zu finden und ich freue mich über Feedback!
https://github.com/Zodiac1978/hide-from-feed
Alle semantischen Objekte, die ohnehin durch HTML-Tags gesetzt werden, funktionieren ganz gut. Blockquotes können zum Beispiel im Feedreader vielleicht anders gestylt sein, aber die Verwendung als Zitat, ggf. mit Quelle, ist durch HTML gegeben und stylebar.
Nur was ist dann mit Elementen, die keine klare Semantik haben? Buttons, die eigentlich Links sind? Technisch gesehen ist das in WordPress ein DIV mit einer CSS-Klasse, die es zum Button macht. Im Feed wird es nur noch zum einfachen Textlink.
CSS hinzufügen, aber wo?
Vielleicht ist die Lösung auch nicht in WordPress zu suchen, sondern im Feedreader. Typischerweise entfernen oder ignorieren die meisten Feedreader das CSS allerdings (egal ob als verlinkte Datei oder im Style-Attribut). Am ehesten noch funktionieren Inline-Styles im Inhaltsbereich.
Aber vielleicht könnten die Feedreader auch selbst das CSS anbieten, was dann die CSS-Klassen von WordPress interpretiert. Die sind nämlich nach wie vor im Feed enthalten. Mein Versuch bei NetNewsWire (Mac) diesen Vorschlag anzubringen, ist leider nicht besonders erfolgreich gewesen.
Noch mehr Probleme mit RSS
Leider ist das nicht das einzige Problem mit RSS in WordPress und Feedreadern. Ich zähle mal ein paar Probleme und mögliche Lösungen auf.
Feeds finden
Als RSS-Feeds ihre besten Zeiten hatten, standen die Feed-Icons auf jedem Blog in der Sidebar. Mit der Zeit verschwanden nicht nur die Sidebars, sondern auch die Feed-Icons von den Websites. Unter anderem, weil der Feed nun für die Autodiscovery im Head der Website definiert wurde und die Browser oder Feedreader den Feed automatisch erkannten.
Dabei wurde jedoch übersehen, dass neue Generationen an Internetnutzenden das Icon nicht mehr sahen und sich daher auch nicht mehr fragten, was das eigentlich ist, so ein RSS-Feed. Weniger Nutzung führte dazu, dass RSS-Funktionen aus Browsern verschwanden, was wiederum weniger Bekanntheit und Nutzung nach sich zog … was sehr schade ist.
Mangelnde Innovation
Mit dem Rückgang der Feedreader-Nutzung ging einher, dass die „sozialen“ Netzwerke immer stärker genutzt wurden. Hier gab es Vorschaubilder, Teasertexte und die Möglichkeit zum direkten Weiterteilen.
Leider wurden die Feeds nicht wirklich weiter entwickelt. Gerade WordPress hätte hier ja eine treibende Kraft sein können. Ein Feed/Feedreader wird nicht durch Algorithmen verändert, zeigt nur die Autor:innen, denen ich wirklich folgen will – ist somit ein kleines lokales, unidirektionales Fediverse. 😉
Aber viele mögliche Funktionalitäten scheitern an der Integration in WordPress und Feedreadern.
Medien in Feeds
Warum werden zum Beispiel „featured images“ nicht als Vorschaubild genutzt? Oder eine neue Option dafür eingeführt (meinetwegen auch in einem Plugin)? Nun, dazu müsste WordPress das Bild überhaupt erst einmal einbetten. Und Feedreader müssten diese Media RSS Erweiterung auch umsetzen:
The media:content element is part of the Media RSS (MRSS) specification, which is an extension to RSS that allows embedding richer multimedia metadata (video, audio, images, etc.).
https://www.rssboard.org/media-rss
Leider ist der Support auch hier eher mäßig.
Scraping
Eine große Sorge war und ist, dass über den RSS-Feed ein kompletter Blog leicht kopiert werden kann, da eine maschinenlesbare Version ja direkt angeboten wird. Im Yoast SEO Plugin gibt es dazu die Erweiterung des Feeds mit dem Satz:
„The post XXX appeared first on YYY.“
Warum ist das nicht so oder so ähnlich im WordPress Core?
Feedback-Kanal, anyone?
Ein großer Vorteil von Social Media ist das direkte Feedback der Leser:innen. Feeds könnten so ein Feedback ermöglichen, aber es fehlt eine Verzahnung mit anderen Systemen, wie den WordPress-Kommentaren. Ich kommentiere ja nicht jeden Artikel, aber wenn ich kommentiere, möchte ich die weiteren Antworten vermutlich lesen. Für diese Artikel jetzt einzeln noch den Kommentar-Feed in meinen Feedreader einbauen? Das mache ich vermutlich nicht – warum gibt es da keine bessere Integration? Und wenn es nicht das Kommentarsystem ist, dann vielleicht wenigstens eine E-Mail, so wie es Florian Ziegler vorgeschlagen hat. Aber das setzt voraus, dass die Feedreader das auch anzeigen … und von dem direkten Kommentieren im Feedreader wage ich gar nicht zu träumen.
Verbreitung
Und um nochmal auf das Problem mit dem Finden der Feeds zurückzukommen: Lasst uns doch bitte alle wieder das Feed-Icon auf unsere Blogs bringen! Aber diesmal bohren wir den Feed mit XSL auf und stylen die Seite, die den Besuchern angezeigt wird. So können wir das Prinzip von RSS-Feeds erklären und gleich ein paar Feedreader verlinken.
Auch das sollte Teil des Cores sein, damit dieses Feature wieder mehr Verbreitung findet, denn es ist unmittelbar kompatibel mit der Mission „democratize publishing“. Inhalte werden für alle bereitgestellt, nicht durch Algorithmen gefiltert, getrackt und ausgewertet.
Alternativen?
Ja, es gibt Alternativen, aber sie stecken noch in den Kinderschuhen oder wollen zu viel, sind zu kompliziert oder haben noch ganz andere Probleme.
RSS-Feeds kann ich noch in einem (recht langen) Satz erklären. Aber wenn ich die Funktionsweisen und Unterschiede zwischen ActivitiyPub, Webmentions, Mastodon, Fediverse, PubSubHubbub und dergleichen erklären müsste, dann müsste ich mir eher eine Woche Urlaub nehmen.
Ein Beispiel für ganz neue Probleme mit dem ActivityPub-Plugin: Mit dem Einsatz wird der Blog ja zu einer eigenen Instanz im Fediverse. Ein neuer Artikel löst nun automatisch einen Post des Blog-Profils aus. Doch typischerweise bin ich ja in meinem persönlichen Profil angemeldet und nicht in meinem Blog-Profil. Wenn jetzt aber der Blog-Tröt viral geht, dann kann es passieren, dass ich das gar nicht mitbekomme, so wie es Roy Tanck passiert ist.
Fazit
Ich finde es unendlich traurig, dass WordPress nicht den Weg gewählt hat, offene Formate wie RSS, Pingback & Co. weiterzuentwickeln und voranzutreiben. Stattdessen wurde mit dem Blockeditor vor allem ein Problem der Hosting-Plattform WordPress.com angegangen, um gegen Squarespace, Jimdo & Wix anzugehen. Für den Blogger oder Website-Builder wurde damit nur ein weiterer „Standard“ hinzugefügt. Das Ziel der gemeinsamen Basis für alle ist eine unerreichbare Utopie. Der Markt zeigt, dass die Hersteller mit ihren eigenen Block-Sammlungen zwar die Lücken des Core schließen, damit aber auch den einfachen Wechsel zwischen Systemen unmöglich machen. Somit ist der Block-Editor auch nur ein weiterer Page Builder mit Lock-In-Effekt geworden, vor dem wir früher immer gewarnt haben.
Ich habe ja ein paar Lösungsideen im Artikel genannt und bin gespannt auf eine Diskussion in den Kommentaren. Was haltet ihr für einen guten Weg? Und was nicht? Und warum? Oder nutzt ihr alle keinen Feedreader mehr und es ist euch egal?
Das wäre ein wirklich tolles Thema für den KrautPress Website Club!
Du hast nicht zufällig am Dienstag um 17 Uhr Zeit?
https://events.krautpress.de/veranstaltung/9-krautpress-website-club/
Eigentlich nicht. Aber ich versuche mal, ob ich das einrichten kann.
Ich nutze Feedly. Bei der Einführung gab es eine Lifetime-Lizenz und bei der Umstellung auf KI gab es ein Lifetime-Upgrade zu Pro+. Leider auf Englisch. Aber es stellt den Feed in ihrem Design und mit einer ausgewählten Schrift dar. Zudem kann man Mute-Filter einrichten.