Vor zwei/drei Wochen bin ich zufällig über brickomattic.com gestolpert (warum hat mir bisher niemand davon erzählt) und hab nicht widerstehen können!
Und nachdem ich (nach gefühlten Wochen) die bestellten Teile zusammen und das WordPress-Logo fertig gebaut hatte kam mir eine noch viel großartigere Idee!!!
Was soll ich sagen… 😅 (aber im Ernst, gar nicht so schlecht für den ersten Versuch, oder?)
Ich weiß zwar nicht warum, aber falls jemand das notiz.Blog-Logo nachbauen möchte…
Ich habe gerade alle XML Formate die ich in WordPress finden konnte, mit XSLT aufgehübscht und jetzt beschließen Google & Co. ernsthaft den Support einzustellen!?!?
Aber bevor ich weiter „rante“, hier ein kurzer Einschub was XSLT überhaupt ist: Mit XSLT lassen sich XML-Dateien in andere Formate umwandeln, zum Beispiel HTML. Man verlinkt dazu ein Stylesheet in der XML-Datei und der Browser übernimmt die Umwandlung. So wird aus einem RSS-Feed eine lesbare Webseite. Ohne JavaScript und ohne dass man dafür auf dem Server etwas installieren muss.
Für den Feed-Reader ändert sich dabei nichts. Der bekommt weiterhin die XML-Datei. Wenn ihr den Feed im Browser öffnet, seht ihr dagegen Beiträge, Links und eine Erklärung wie ihr ihn abonnieren könnt.
Bei OPML finde ich das besonders praktisch: Ihr klickt auf den Link und bekommt eine Liste von Blogs durch die ihr stöbern könnt. Die gleiche URL könnt ihr in euren Feed-Reader importieren. Man muss nicht einmal wissen was OPML ist um etwas damit anfangen zu können.
@ix hat auch gerade nochmal über seine Basteleien geschrieben. Er hübscht seine OPML-Dateien auch mit XSLT auf und inzwischen auch seine RSS-Feeds.
Die generelle Idee hinter XSLT erinnert mich sehr an den Microformats-Grundsatz:
Bei Microformats ergänzt man das HTML einer Webseite so, dass auch Software etwas damit anfangen kann. Das gleiche HTML für Menschen und Maschinen. Bestehendes sinnvoll erweitern, mit dem arbeiten was schon da ist.
XSLT macht im Prinzip das Gleiche, nur aus der anderen Richtung:
Designed for machines first and humans second
Die XML-Dateien bleiben für Maschinen lesbar. Mit einem Stylesheet können aber auch Menschen etwas damit anfangen.
RSS und OPML sind ein wesentlicher Bestandteil des Open Webs. Wir verlinken sie an so vielen Stellen, weil wir wollen dass Besucher es einfach haben den Blog zu abonnieren oder weil wir ihnen neue Links vorschlagen wollen. Was sie in Zukunft sehen werden ist reines XML. Keine Möglichkeit irgendetwas zu erklären oder auf das Wesentliche aufmerksam zu machen! Nur XML!
Leider ist das auch keine rein theoretische Diskussion mehr. Stand 5. Oktober 2026:
Chrome: XSLT ist bereits deprecated. Die Abschaltung ist für Chrome 158 am 17. November 2026 geplant. Befristete Ausnahmen für registrierte Websites und verwaltete Browser sollen am 17. August 2027 enden. Betroffen sind sowohl die Verknüpfung mit einem XSLT-Stylesheet als auch die JavaScript-API XSLTProcessor. Zeitplan von Chrome
Firefox: Mozilla hat die Abschaltung für August 2027 angekündigt. Intent to Unship
Safari/WebKit: WebKit unterstützt die Entfernung grundsätzlich, formuliert seine Zustimmung aber vorsichtig. Einen verbindlichen Abschalttermin habe ich in den geprüften Quellen nicht gefunden. WebKits Stellungnahme
RSS, Atom und OPML funktionieren natürlich weiter. Entfernt wird die XSLT-Verarbeitung im Browser. Der Reader kann meinen Feed also weiterhin lesen, aber wer auf den Link klickt bekommt die XML-Ansicht.
Die Begründung der Browserentwickler sind Sicherheitslücken, Wartungsaufwand und geringe Nutzung. Das sind alles nachvollziehbare Argumente. Trotzdem finde ich den Verweis auf JavaScript und moderne Frameworks als Ersatz unbefriedigend. Ich hab eine XML-Datei und ein Stylesheet. Für das was ich damit machen will hat das bisher gereicht!
Was können wir stattdessen machen?
XSLT mit JavaScript nachrüsten. Es gibt einen Polyfill mit WebAssembly, den man direkt in die XML-Datei einbindet. Der Browser führt damit das Stylesheet aus, der Reader bekommt weiterhin XML. Das könnte die bisherige Darstellung unter der gleichen URL erhalten. Allerdings dokumentiert das Projekt Unterschiede zur eingebauten XSLT-Verarbeitung, etwa beim Nachladen weiterer Dateien. Ob es mit meinen Stylesheets und den Readern funktioniert müsste ich ausprobieren.
XML mit CSS gestalten.Das bleibt möglich. Die gleiche XML-Datei lässt sich damit im Browser lesbar darstellen, für Reader ändert sich nichts. CSS kann aber nicht alles was XSLT kann: Aus einer URL in einer OPML-Datei wird dadurch noch kein anklickbarer HTML-Link. Für eine einfache Ansicht kann es trotzdem reichen.
HTML und XML unter der gleichen URL ausliefern. Mit Content Negotiation könnte der Server anhand des Accept-Headers entscheiden welche Version er zurückgibt. Nur für die HTML-Version würde ich XSLT auf dem Server ausführen, Reader müssten weiterhin das ursprüngliche XML bekommen. Eine zusätzliche öffentliche URL braucht es dafür nicht. Der Haken: Browser und Reader lassen sich über den Header nicht zuverlässig auseinanderhalten. Das müsste ich mit verschiedenen Readern testen. Caches brauchen außerdem Vary: Accept damit sie die Versionen nicht verwechseln.
Ganz ehrlich? Das ist alles 💩 und keine wirkliche Alternative!
Meine ganze Motivation, an WordPress und dem Open Web zu arbeiten, ist eine sehr selbstsüchtige: Ich liebe es, an meiner Seite herumzubasteln und ins Internet zu schreiben. Leider vergesse ich das von Zeit zu Zeit, und dann wird es sehr ruhig hier… Gerade ist das anders!
Ich habe meine About-Seite überarbeitet, meine Now-Seite aktualisiert, ein Changelog angelegt und wieder generell Lust zu schreiben! Ich hab ein Dutzend neue Plugins gebaut und mein Autonomie Theme auf „Full Site Editing“ umgestellt (naja, vielleicht noch nicht ganz umgestellt).
Ich weiß nicht so genau, warum gerade jetzt, aber vielleicht hab ich mich von @simon mitreißen lassen ☺️
Simon tingelt gerade durch die Lande und teilt seine Motivation, eine eigene Webseite zu haben und daran herum zu werkeln! Wer noch keine Chance hatte, den Vortrag live zu sehen, sollte sich unbedingt das Video anschauen!
Das Fazit für mich bei dem Ganzen ist so ein bisschen, meine Website kann klein sein und irgendwie menscheln. Und sie ist dann erfolgreich, wenn ich das sage. Es gibt exakt keine einzige Metrik, die mich überhaupt interessieren könnte, außer der Spaß, den ich daran habe, dieses Ding zu bauen. Und die Verbindung, die ich dabei mit anderen Leuten an den Start bringe.
Eigentlich ist es ein bisschen wie das Ei des Kolumbus: Sobald man es einmal gehört hat, macht es total Sinn. Trotzdem vergesse ich es leider immer mal wieder!
Deshalb ist es wichtig, sich das immer wieder klarzumachen… mal schauen, wie lange es diesmal anhält.
Und jetzt bin ich aktives und zahlendes Mitglied bei Rivva und beteilige mich am Starter-Packs Projekt!
Ich bin da wohl aus Versehen in was Großartiges reingerutscht 😉
Das Plugin selbst stellt eigentlich nur einen Block bereit. Man kann eine Blogroll in jeden Beitrag oder auf jede Seite packen, auch mehrmals, wenn man z.B. Blogs und Podcasts trennen will. Oder man verteilt die Blogrolls auf mehrere Seiten. Jede Blogroll hat dabei ihre eigene OPML.
Beim Hinzufügen reicht die URL. Name, Beschreibung, Icon und Feed holt sich das Plugin selbst, man kann aber alles noch anpassen. Es gibt keine Settings, alle Änderungen nimmt man direkt im Block vor.
Das Plugin gibt es auf WordPress.org und GitHub. Ich freue mich über Feedback, Ideen und Pull Requests!
(Das Plugin hieß ursprünglich übrigens „Blockroll“. Ein schlechtes Wortspiel: ein Gutenberg-Block, der eine Blogroll ausgibt. Nachdem in der Rivva-Community die Frage aufkam, was das Ganze mit Blocken zu tun hat, heißt es auf WordPress.org jetzt „Blogroll & Podroll Block“. Den Slug blockroll hab ich aber behalten, das Wortspiel konnte ich mir nicht verkneifen 😉)
((@simon bastelt außerdem schon an einem Logo für das Plugin (bzw. er lässt basteln)… mehr dazu bald))