Auf dem CloudFest Hackathon im März, hab‘ ich mich ein wenig mit Alain Schlesser über WordPress und Plugin-Entwicklung unterhalten. Alain meinte, dass er, wenn es das Plugin hergibt und es zeitlich möglich ist, immer zuerst eine generische Library bauen und diese dann über ein WordPress-Plugin implementieren würde.

Vor ein paar Tagen hab ich mich an unser Gespräch erinnert, weil ich mich (aus Gründen) wieder intensiver mit dem ActivityPub-Plugin beschäftigt habe. Wir hatten schon vor einem Jahr den Plan, eine ActivityPub-Bibliothek zu verwenden, um uns nicht mit dem Protokoll beschäftigen zu müssen, und uns so voll und ganz auf die WordPress Integration konzentrieren könn(t)en. Wir haben die Idee aber erstmal nicht weiter verfolgt, da die Bibliothek eine Reihe von schwergewichtigen Third-Party-Libs wie Guzzle (HTTP-Client), Monolog (Logger) oder Symfony Cache (Caching) mit sich bringt. Für all diese Funktionen hat WordPress eigene Lösungen und wegen der Interoperabilität mit anderen Plugins, sollte man diese auch nutzen.

Bei der erneuten Evaluierung der ActivityPub-Bibliothek ist mir aufgefallen, dass sich Monolog, durch einen beliebigen PSR-3 kompatiblen Logger ersetzen lässt.

Kurze Erklärung zu PSR:

Eine PHP Standard Recommendation (PSR) ist eine PHP-Spezifikation, welche durch die PHP Framework Interop Group veröffentlicht wird. Ähnlich einem Java Specification Request in Java dient sie der Standardisierung von Programmierkonzepten. Ziel ist es die Interoperabilität von Komponenten zu ermöglichen und eine gemeinsame technische Basis zu schaffen oder bewährte Konzepte für einen guten Programmierstil sowie eine gute Testbarkeit von Komponenten umzusetzen. Verschiedene Frameworks wie z. B. die der TYPO3-Community, Symfony oder Zend implementieren hierbei PSR-Spezifikationen in einem selbst gewählten Umfang.

https://de.wikipedia.org/wiki/PHP_Standard_Recommendation

PSR-3 definiert ein standardisiertes Logger-Interface, welches (in unserem Beispiel) durch Monolog implementiert wird. Beim initialisieren des ActivityPub-Servers, lässt sich Monolog, durch einen alternativen Logger ersetzen, solange dieser auch PSR-3 konform ist.

use ActivityPhp\Server; // Create a server instance with no log output $server = new Server([ 'logger' => [ 'driver' => '\Psr\Log\NullLogger' ], ]);
Code-Sprache: PHP (php)

Also hab ich mir überlegt, wie so ein Logger für WordPress aussehen könnte und einen PSR-3 kompatiblen Wrapper gebaut:

namespace WPPSR\Log; use Psr\Log\AbstractLogger; class ErrorLogLogger extends AbstractLogger { public function log( $level, $message, $context = array() ) { if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) { if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) { error_log( sprintf( '%s: %s. Details: %s', $level, trim( $message, '.' ), json_encode( $context ) ) ); } } } }
Code-Sprache: PHP (php)

PSR definiert passenderweise auch Interfaces für HTTP-Clients, Request-/Response-Objekte und Caching. Für die Request-Library die in WordPress benutzt wird, gibt es sogar schon ein passendes Issue: https://github.com/WordPress/Requests/issues/320

Leider sind Caching und der HTTP-Client in der ActivityPub-Implementierung noch nicht austauschbar, obwohl beide benutzten Libraries PSR kompatibel sind. Das heißt ich muss zuerst evaluieren, wie viel Arbeit es ist, die ActivityPub-Lib anzupassen, um dann diverse Wrapper für das WordPress Caching und die Request-/Response-Classes zu schreiben…

Bzw. muss ich das wahrscheinlich nicht einmal selbst implementieren, da ich bei weitem nicht der Erste war, der diese Idee hatte:

WordPress tut sich immernoch schwer mit modernem PHP-Dependency-/Plugin-Management. Ersteres ist praktisch nicht vorhanden (wird aber zumindest nicht verhindert) und letzteres basiert immer noch auf einem Prozess in dem SVN eine tragende Rolle spielt. Aber mit PSR(-Wrappern) kann man das Problem schon ganz gut kompensieren 🙂

Ein Code-Beispiel wie Kommentare als Custom Post Type registriert werden können.

Eine Leseempfehlung vorweg: „Yes, Comments Are Still Relevant, But We Need a Better System“ von Justin Tadlock auf WPTavern!

Soziale Netzwerke haben die Art wie wir kommunizieren drastisch verändert. Wir reagieren selten mit Text, statt dessen liken, re-tweeten, sharen und faven wir was das Zeug hält. Und wenn wir mit Text reagieren, hat dieser spätestens seit Twitter, einen anderen Stellenwert. Ein Kommentar ist nicht länger ein Stück Text unter einem Artikel, ein Kommentar steht für sich alleine und wird durch die Plattform in den richtigen Kontext gesetzt, abhängig vom Einstiegspunkt des lesenden.

Mein Tweet, über meine Timeline, mit Depones Antwort
Daniels Antwort über seine Timeline, mit meinem Tweet als „Reply-Context“.

Die IndieWeb Community nennt das einen Reply-Context.

Diese Art der Darstellung und Handhabung von Reaktionen ist auch in dezentralen Netzwerken sehr populär. Mastodon ähnelt sehr, dem von Twitter gekauften Tweetdeck und imitiert auch dessen Darstellung. Die IndieWeb Bewegung geht sogar noch einen Schritt weiter und schafft mit Webmentions eine Möglichkeit über Blog-Posts dezentral zu kommentieren.

Die Kommentar-Funktion von WordPress ist dagegen bald 20 Jahre alt und dementsprechend antiquiert.

Zeit das zu ändern!?!

Custom Post Type

Ich arbeite seit knapp 15 Jahren daran, WordPress im IndieWeb und Fediverse zu verankern. Das große Problem ist dabei immer wieder die Persistenz und die Darstellung von Reaktionen. Ich habe mir viele Gedanken gemacht, wie man das Problem beheben und WordPress‘ Kommentar System modernisieren könnte, und ende immer an dem Punkt, wo ich versuche die Custom Post Type – Funktionalität für Kommentare nachzubauen.

Aber warum? Wenn ich eh alles nachbauen müsste, wäre es doch viel sinnvoller direkt Post-Types zu benutzen.

register_post_type( 'comment' );
Code-Sprache: JavaScript (javascript)

Aktuell bildet WordPress Posts, Pages, Attachments, Revisions, Navigation Menus, Custom CSS und Changesets über Custom Post Types ab… Warum also nicht auch Kommentare und andere Reaktionen?

Durch die Gleichsetzung der Datenstruktur von Posts und Comments, lassen sich diese einheitlich und dadurch einfacher verarbeiten und über z.B. APIs ausgeben. Gerade ActivityPub macht, wie Twitter, keinen Unterschied zwischen Kommentar, Antwort, Like, Boost oder initialem Text.

Die (Custom-)Post Tabelle bietet über post_parent schon jetzt die Möglichkeit komplexe Zusammenhänge wie z.B. auch Threaded-Comments abzubilden. Über den post_status ließen sich außerdem Kommentar-Status sowie eine Spam-Behandlung realisieren und commentmeta kann komplett in postmeta aufgehen.

Neben den klassichen Kommentaren lassen sich aber auch andere Reaktionen umsetzen.

Like, Share, …

Mit Post-Formats hat WordPress ein interessantes Konstrukt um Posts (über eine Taxonomy) weiter zu klassifizieren. Was für Posts das aside, gallery, link oder video Format ist, könnte für Comments das Like, Share oder Bookmark Format sein.

Themes könnten ihren Support wie folgt definieren:

add_theme_support( 'comment-formats', array( 'like', 'share', 'bookmark' ) );
Code-Sprache: PHP (php)

Und Plugins, wie Webmention oder ActicityPub, könnten neue Formate wie folgt registrieren:

register_comment_format( string $comment_format, array|string $args = array() )
Code-Sprache: PHP (php)

Fazit

Technisch spricht also nichts dagegen, Custom Post Types auch für Kommentare zu benutzen, man muss eigentlich nur noch alle Kommentar-Funktionen und -Klassen anpassen und fertig!

…und direkt über wpdb wird sicherlich eh niemand auf die Kommentar-Tabelle zugreifen! 😉

Spaß beiseite… Ich mag die Idee wirklich, hab aber bisher noch keinen ähnlichen Vorschlag im Trac gefunden… Ob das ein Zeichen ist?

Im modernen Sprachgebrauch wird der Begriff [Posse] in übertragenem Sinn […] genutzt, um als grotesk empfundene Vorgänge in Gesellschaft und Politik zu beschreiben.

https://de.wikipedia.org/wiki/Posse

Wer sich (aus gegebenem Anlass) sorgen um Twitter macht, sollte sich mal mit der etwas anderen POSSE befassen.

POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.

https://indieweb.org/POSSE

Installiert euch WordPress! Veröffentlicht Texte, Bilder, Videos und Ideen nicht auf Twitter sondern auf eurer eigenen Seite! Teilt eure Inhalte über Twitter!

Und sollte Twitter „verschwinden“, teilt es über Mastodon! usw, usw…

Schaut euch dazu gerne auch mal Brid.gy an!

Vor ein paar Tagen bin ich über einen Post von Tantek Çelik gestolpert, in dem er metaformats vorstellt.

Introducing #metaformats (https://microformats.org/wiki/metaformats), an extension to #microformats2 for parsing invisible data published in HTML meta tags, for backward compatibility with existing vocabularies consumed by multiple testable interoperable implementations.

https://tantek.com/2022/091/t1/metaformats

Der Vorschlag ist vom 01. April und war wohl ursprünglich als April-Scherz gedacht.

metaformats started as an April Fools joke concept to describe how to both publish using microformats class names and openly parse meta tags as a fallback for what should be in-the-body visible data, including backcompat with OGP, Twitter Cards, and meta author, description, and anything else real sites (like search engines) appear to consume.

https://indieweb.org/metaformats

Eine Art Fallback-Spezifikation für Microformats-Parser finde ich in der Tat etwas sperrig, aber ich mag die Idee eines Fallbacks an sich.

Microformats sind ein Building-Block des IndieWebs und werden unter anderem auch von Webmentions genutzt. Es sind Markup-Formate zur semantischen Auszeichnung von HTML. In der Version 2, werden Microformats aber fast ausschließlich von der IndieWeb Community benutzt und sind darüber hinaus wenig bekannt.

Aber gerade für WordPress ist es extrem schwer, bestehende Themes nachträglich mit Microformats zu „veredeln“. Wir haben es mit diversen Plugins versucht, mit nur mäßigem Erfolg. Andere Formate wie das Open Graph Protocol oder Schema.org (JSON-LD) sind da wesentlich einfacher zu integrieren, da sie nicht bestehendes HTML erweitern und durch den Support der großen Suchmaschinen und sozialen Netzwerke, auch viel attraktiver sind.

Ich bin kein großer Fan von embedded JSON-LD, aber wenn es nicht anders funktioniert und seine Reichweite hat, warum sollte man es dann ignorieren?

Das IndieWeb hat eigentlich eine großartige Philosophie um mit solchen „Problemen“ umzugehen.

bridge all the things is a nascent IndieWeb philosophy that prioritizes interoperability over ideology, NIH, historical disagreements, etc. ecosystems are valuable and powerful, and one easy way to extend an ecosystem is to bridge it with other existing ecosystems.

https://indieweb.org/bridge_all_the_things

Für das Webmention Plugin haben David und ich schon vor Monaten einen ganz ähnlichen Ansatz gewählt. Neben Microformats unterstützen wir auch OGP, Twitter-Cards, Schema.org, Meta-Header und die WordPress API, um eventuell fehlende Microformats v2 zu kompensieren.

Selbst wenn „metaformats“ nur als April Scherz gedacht waren, hat die Idee Potential um speziell Webmentions voran zu treiben, da sie eine direkte Abhängikeit zu einer speziellen Websemantik verhindert.

Bridge all the things!

Das IndieWeb Team auf dem Cloudfest Hackathon

Vom 19. bis 21. März fand der CloudFest Hackathon in Rust statt und ich hatte die Chance ein Projekt einzureichen und zu leiten:

WordPress and the IndieWeb

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data.

There are a variety of WordPress-plugins implementing these standards and principles, to help people to stay independent. Most of these plugins are very basic, have no or only little documentation with a poor user experience. Help the movement to mature and gain a broader audience.

Ich hatte mir im Vorfeld nicht viel Gedanken zum Hackathon gemacht, hab aber insgeheim gehofft, der Version 5.0 vom Webmention Plugin (einer nahezu kompletten Überarbeitung an der David Shanske und ich schon eine halbe Ewigkeit arbeiten) ein wesentliches Stück näher zu kommen… Das Wochenende lief dann aber doch etwas anders… auch großartig, aber anders 🙂

1. Tag

Wir waren eine wild zusammengewürfelte Truppe von 8 Leuten mit den verschiedensten Lebensläufen und ich hab mir den ersten Tag viel Mühe gegeben, das IndieWeb und Webmentions zu erklären. Die Diskussionen waren spannend und hitzig und gingen sogar so weit, dass ich zwischendurch den generellen Sinn und Zweck des Webmention Plugins verteidigen musste.

Hackathon Gruppe

Letztendlich haben aber nicht meine Argumente die Gruppe überzeugt, sondern eine Präsentation des Plugins mit all seinen aktuellen Features. Wer diesen Erkenntnisprozess nachvollziehen möchte, kann gerne Hagen Grafs „Webmention Journey“ auf Twitter verfolgen 🙂 (Nachtrag: Hagen hat seine Journey mittlerweile auch „verbloggt“)!

Meine Fazit des ersten Tages?

Man muss nicht die Geschichte des IndieWebs verstehen und auch nicht den Webmention Standard gelesen haben um von der Funktionalität begeistert zu werden, vor allem in der Kombination mit Brid.gy (Brid.gy schlägt eine Brücke zwischen dem Webmention Standard und den proprietären APIs der bekannten Social Networks. So landen dann auch Likes auf Facebook und Kommentare auf Twitter, im eigenen Blog).

Ich werde Versuchen mich zukünftig weniger auf Geschichte und Technologie zu konzentrieren und auf Vorträgen und Hackathons mehr Fokus auf die Funktionalität zu legen.

Ich hab die Plugins in erster Linie erstmal für mich Gebaut. Frei nach dem Motto „eat your own dogfood„. Das hat für die IndieWeb Community ganz gut funktioniert, aber um eine breitere Masse anzusprechen, muss das Plugin verständlicher werden.

Für den Hackathon haben wir uns deshalb dazu entschieden, die Usability und die User Experience des Plugin zu beleuchten und (im besten Fall) zu verbessern.

Webmention-Settings

Die Einstellungen setzen relativ viel Kenntnisse über die Funktionsweise von Webmentions voraus. Ein Teil der Gruppe hat sich daran gemacht, die Seite zu überarbeiten und zu vereinfachen.

Das Resultat ist eine Art Wizard, der beim ersten Aufruf gestartet wird und den User Schritt für Schritt durch die Einstellungen führt und sie ausführlich erklärt. Der Wizard soll nur beim ersten Laden starten und die klassischen Einstellungen nicht ersetzen.

(Der Pull Request dazu: #328)

Die zweite Idee war Brid.gy tiefer in das Webmentions Plugin zu integrieren. Die aktuelle Diskussion dazu findet auf GitHub statt.

Response-Types

Im Gegensatz zu Trackbacks und Pingbacks, müssen Webementions nicht immer „nur“ ein simpler ping sein. Es ist auch möglich dezentrale Likes, Bookmarks, RSVPs oder Reposts zu verschicken.

Aktuell muss man dazu im Block-Editor auf die HTML Ansicht wechseln und dem Link eine CSS-Klasse hinzufügen:

<a class="u-like-of" href="http://example.com/">Example</a>
Code-Sprache: HTML, XML (xml)

Das ist nicht praktikabel und in keiner Weise anwenderfreundlich. Aus diesem Grund hat eine zweite Gruppe, an einem User Interface für den Response-Type gearbeitet.

Response-Types für Links im Block Editor

Am Ende des Hackathons gab es auch einen ersten Draft, mit der man Links als Likes auszeichnen konnte. Den PR gibt es leider noch nicht, aber ich werde ihn nachreichen wenn es soweit ist.

Webmaininnat suomeksi

…ja Carolinan ansiosta Webmaininnat-laajennus on nyt saatavilla myös suomeksi! Kiitos paljon 🙂

Fazit

Es war extrem spannend mit Leuten, außerhalb der IndieWeb und (teilweise) auch außerhalb der WordPress-Community, über das IndieWeb im Allgemeinen und das Webmention Plugin im Speziellen zu sprechen.

Vielen Dank an Moritz Bappert, Stefan Euchenhofer, Marko Feldmann, Hagen Graf, Carolina Lindqvist, Jason Rouet und Jan Vogt für eure tolle Arbeit! Danke für die neue Perspektive und für euer Feedback!

Danke auch an Robert Windisch und Alain Schlesser, mit denen ich viel über das Potential von Webmentions im WordPress Core geredet habe.

Die 5.0er Version des Webmention Plugins wird großartig!

Screenshot der notizBlog Seite von 2005

notiz.blog wird 16 und zur Feier des Tages habe ich meiner Blog-Beschreibung das kleine Wort „mainly“ spendiert!

a weblog mainly about the open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web

Kontext?

Christian Fischer hat einen sehr schönen Text, über „Tanker“ geschrieben:

An dem Tag als ich beschloss alles zuzumachen, war das jawl knappe 17 Jahre alt. In diesen 17 Jahren hatte ich befunden, diese Blogs wären vielleicht interessant, war von den ersten 50 Bloggern freundlich und allerschärftens willkommen geheißen worden, hatte so vor mich hingeschrieben, hatte plötzlich viele Leserinnen, sah die Blogosphäre wachsen, war nicht auf der Blogmich, hatte weniger Leserinnen. Schrieb allerlei wofür wir später Twitter oder Facebook bekamen, schrieb dadaistisches Zeug, über Popstars, über die Blogosphäre, Kurzgeschichten und meinen ersten Rant, und bloggte lange so vor mich hin. Davon abgesehen, dass ich natürlich keine Ahnung mehr habe, was ich da wirklich so alles getrieben habe, hatte ich vor allem das Gefühl, dass ich dabei immer ernsthafter wurde, immer wichtiger schreiben wollte – und deswegen immer seltener und seltener schrieb.

Und seit ichs hier Tagebuchbloggen nenne, darf ich so gehaltlos sein, wie ich will. Ist ja nur Alltag.

Und das ist sehr befreiend.

Judith Holofernes hat zum Ende von Wir sind Helden mal sinngemäß gesagt: Das Ding war wie ein Tanker, zu groß, zu schwer, zu unbeweglich.

Ich kann das exakt so auch sagen.

11.6.2020 – das alte und das neue Blog

Etwas Ähnliches ist leider auch hier/mir passiert!

Eigentlich war das notiz.Blog nie monothematisch geplant. Es begann mit Posts über Web2.0, X-Box, das Web, Bud Spencer, Mr. T, das Web und das A-Team und es endete mit dem „open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social web„.

Ähnlich wie bei Christian, stelle ich mir heute viel zu oft die Frage ob eine Text-Idee thematisch zum Blog passt. Aber eigentlich gibt es so viel Themen über die ich gerne schreiben würde… über WordPress, Open Source, Haus-Automatisierung, Selbstorganisation und Action-Figuren.

Depone hat die Tage fast sein privates Blog geschlossen.

Auch interessant, dass ich seit Juli keinen Blogpost mehr in meinem privaten Blog veröffentlich habe.

Die Tage darüber nachgedacht es zu löschen.

twitter

Ich mach mir statt dessen Gedanken ob ich ein Neues brauche!?!

Mal schauen wie es hier weiter geht, jetzt wird aber erstmal gefeiert 🎉!

…vielleicht reicht ja der psychologische Effekt des kleinen Wortes „mainly“ und dicht gemacht wird auf keinen Fall 😉

Screenshot von amp.dev

Google hat aktuell eine Klage am Hals. Der Konzern soll AMP genutzt haben, um sein eigenes Werbenetzwerk gegenüber der Konkurrenz zu bevorzugen.

Google soll sein Format AMP (Accelerated Mobile Pages) zur Webseiten-Beschleunigung nur eingeführt haben, um die Verleger dazu zu bewegen, letztlich mehr Geld im Google-internen Werbenetzwerk auszugeben. Das ist einer der Vorwürfe von zwölf US-Bundesstaaten, die kürzlich Klage gegen den US-Konzern eingereicht haben.

Kartellklage: Google soll AMP für Wettbewerbsvorteile eingeführt haben (heise online)

Leider ist das nur einer von vielen Kritikpunkten an AMP, toppt in meinen Augen aber alle Bisherigen um längen!

Ich möchte aber gar nicht zu sehr auf die Fälle eingehen, weil sie schon zu Genüge thematisiert wurden. Was mich dagegen triggert, ist die ständige Erwähnung von „Open Web“ im Kontext von AMP, speziell auch im WordPress Umfeld!

Screenshot von amp.dev

Sarah Gooding hat auf WP Tavern einen sehr lesenswerten Artikel zu dem AMP Skandal veröffentlicht, in dem sie auch auf die Rolle von WordPress bzw. Automattic eingeht: AMP Has Irreparably Damaged Publishers’ Trust in Google-led Initiatives.

In dem Abschnitt „Automattic Denies Prior Knowledge of Google Throttling Non-Amp Ads“ schreibt sie:

In 2016, Automattic, one of the most influential companies in the WordPress ecosystem, partnered with Google to promote AMP as an early adopter. WordPress.com added AMP support and Automattic built the first versions of the AMP plugin for self-hosted WordPress sites. The company has played a significant role in driving AMP adoption forward, giving it an entrance into the WordPress ecosystem.

Auf eine Nachfrage bei Automattic, bekommt sie folgende Antwort:

As part of our mission to make the web a better place, we are always testing new technologies including AMP

Auf die konkrete Frage, ob sie von der Wettbewerbsverzerrung wussten, antwortet Automattic mit:

We chose to partner with Google because we believed that we had a shared vision of advancing the open web. Additionally, we wanted to offer the benefit of the latest technology to WordPress users and publishers including AMP.

Da steht tatsächlich „we believed that we had a shared vision of advancing the open web„!

Selbst nach all der Kritik an einem proprietäres Format, einem subset von HTML5, welches die Nutzung von JavaScript limitiert, Webseiten-Betreibern aufgezwungen wurde, damit sie ihren Page-Rank behalten/verbessern, um ihnen dann die Besucher durch ein heftiges Caching der AMP Seiten abzugraben, um sich dann wohl auch noch einen Wettbewerbsvorteil im Bereich der Werbung zu sichern, sprechen Automattic und Google von „Open Web„?!?!

Warum mich das triggert?

Ich investiere jetzt knapp 15 Jahre meiner Freizeit in wirkliche „Open Web“ Plugins für WordPress, welche seit Jahren unbeachtet oder als „maybe later“ gekennzeichnet im Trac vor sich hin siechen, aber insgeheim hatte ich trotzdem die Hoffnung, dass vielleicht Google oder Automattic irgendwann Interesse zeigen könnten, wenn ihnen das Thema „Open Web“ (und WordPress) anscheinend doch so wichtig ist…

Wenn jetzt aber AMP der Maßstab für „Open Web“ ist, dann sehe ich schwarz für Webmentions oder ActivityPub.

In deutsch zu bloggen war eine bewusste Entscheidung!

Der Austausch über das „open, portable, interoperable, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted und federated social web“ findet hauptsächlich in englischer Sprache statt, und mir ist wichtig, das Thema speziell in Deutschland voranzutreiben.

Ich bin bisher aber nie wirklich davon ausgegangen, dass meine „Artikel“ auch für anders sprechende interessant sein könnten, bis Ray mir folgendes in die Kommentare schrieb:

For those of you like me who can’t read German but want to follow your blog via RSS, I found a way to have an RSS feed translated on the fly to whatever language you prefer:

https://www.labnol.org/internet/google-translate-rss-feeds/5110/

I can confirm it works following the steps listed within — Feedbin pulls in your RSS feed in english for me now! : )

Thanks for all you do,
Ray

Und was soll ich sagen… Seine Idee is großartig und super simpel… Einfach einen kleinen Service über Google Scripts bauen, der die Texte aus dem Feed automatisch übersetzt und dann wieder als Feed bereit stellt! Die Anleitung findet ihr auf labnol.org und mein etwas angepasstes Skript auf GitHub.

Ihr könnt meinen (notiz)Blog jetzt also auch auf Englisch abonnieren: https://notiz.blog/en/feed/ 😍

(Ich hab dazu auch eine Seite gebaut, die ihr unter „(en)“ im Menü findet.)

Danke Ray!

A list of all my WordPress Plugins

Mein erstes WordPress Plugin hab ich vor mehr als 14 Jahren veröffentlicht und über die Jahre sind eine ganze Menge, mehr oder weniger erfolgreiche, Plugins dazu gekommen… Zeit für eine Inventur 🙂

Viele der Plugins schreibe ich in erster Linie für mich selbst (eat your own dogfood), weshalb ich in den wenigesten Fällen über die Plugins spreche oder sie bewerbe. Das, in Verbindung mit meinen eher spärlichen Beschreibungen, sorgt oft für eher zweistellige, maximal dreistellige Download-Zahlen. Wo die Zahlen höher sind, habe ich das Plugin meistens von Anderen übernommen (um die Weiterentwicklung zu gewährleisten) oder ich bin einfach „nur“ Contributor.

Aber Schluss mit der falschen Bescheidenheit!

Selbst wenn ich die Plugins für mich baue, ist die Motivation natürlich größer, wenn sie auch von anderen benutzt werden. Also möchte ich euch hier ein paar meiner Plugins vorstellen.

ActivityPub

ActivityPub ist ein, vom W3C veröffentlichtes, offenes, dezentrales Protokoll für soziale Netzwerke.

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

https://www.w3.org/TR/activitypub/
Schaubild welches die Funktionsweise von ActivityPub zeigt

Es ermöglicht das dezentrale kommunizieren über Text, Bild, Video und Audio über ein simples Inbox/Outbox Prinzip.

WebFinger Plugin

WebFinger ist kein fester Bestandteil von ActivityPub, wird aber von allen großen Netzwerken unterstützt und von Mastodon sogar verlangt. WebFinger ist eine Art Meta-Data System für alle möglichen URIs. Der gängige Identifier im Fediverse ist @username@domain.tld, das Plugin erlaubt aber auch die Author URL oder die Instant-Messaging Accounts eines Users, wenn diese unter der gleichen Domain erreichbar sind.

Mein Identifier ist Beispielsweise pfefferle@notiz.blog und die Meta-Daten können über folgenden API-Endpunkt abgerufen werden: https://notiz.blog/.well-known/webfinger?resource=acct%3Apfefferle%40notiz.blog

NodeInfo Plugin

NodeInfo (2) ist auch kein fester Bestandteil von ActivityPub, wird aber auch von den Meisten Netzwerken unterstützt. NodeInfo stellt, wie der Name schon sagt, Infos über einen „Node“ (Server) bereit. Dank NodeInfo gibt es eine ganze Reihe an Statistik-Seiten wie the-federation.info, die bei der Auswahl der richtigen Plattform bzw. des richtigen Servers helfen.

ActivityPub Plugin

Das eigentliche ActivityPub Plugin macht WordPress zu einem (kleinen) Teil des Fediverse. User von Mastodon, Pleroma, Friendi.ca oder Pixelfed können dem Blog „folgen“ und sehen ab dann alle neuen Blog-Posts in ihrer Timeline und können diese kommentieren. Das Plugin ist immernoch in einem frühen Stadium und bekommt sicherlich noch das ein oder andere Feature, im Fokus soll aber das Bloggen stehen. Wer ein vollwertiges, dezentrales, soziales Netzwerk möchte, sollte sich erstmal für eine der oben genannten Plattformen entscheiden.

IndieWeb

Der IndieWeb Wapuu

Das IndieWeb ist eine Grassroots Bewegung mit dem Ziel, die eigene Webseite als zentralen Kommunikations-Hub zu nutzen.

The IndieWeb is a community of individual personal websites, connected by simple standards, based on the principles of owning your domain, using it as your primary identity, to publish on your own site (optionally syndicate elsewhere), and own your data.

https://indieweb.org/IndieWeb

Mehr zum IndieWeb findet ihr hier oder unter dem Tag „indieweb“ hier im Blog.

IndieWeb Plugin

Das IndieWeb Plugin hat nahezu keine Funktionalität, es ist vielmehr eine Art Installer um die IndieWeb Plugins über eine zentrale Stelle verwalten zu können.

Es gibt immer wieder Kritik am Aufbau des Plugins, bzw. kommt immer wieder die Frage auf, warum das Plugin nicht einfach die komplette Funktionalität der einzelnen Plugins beinhaltet. Meine Antwort darauf: Das IndieWeb ist mehr eine Idee als eine Spezifikation und es gibt verschiedene Möglichkeiten diese Idee mit WordPress umzusetzen. Für einen Usecase gibt es also oft verschiedene Lösungen, die von verschiedenen Personen entwickelt werden. Ein IndieWeb Plugin im Stil von ActivityPub ist in meinen Augen nicht möglich. Ich lasse mich aber gerne eines besseren belehren 😉

Webmention Plugin

Webmentions sind eine moderne Alternative zu Pingbacks und Trackbacks. Im Gegensatz zu der eher unglücklichen Darstellung von Pingbacks ([...] super, wie war nochmal der kontext, oder [...]) versucht das IndieWeb (über Webmentions und Microformats), den Sinn und die Art einer Verlinkung heraus zu bekommen um die Reaktion dann als Like, Bookmark oder vollwertiges Kommentar anzuzeigen.

Das Webmention Plugin implementiert aktuell nur den Kommunikations-Teil, für das Interpretieren der Websemantiken benötigt ihr zusätzlich das „Semantic Linkbacks“ Plugin.

Mehr über Webmentions hier oder unter dem „webmention“ Tag hier im Blog.

Semantic Linkbacks Plugin

Wie oben beschrieben sorgt das Semantic Linkbacks Plugin für die hübsche Darstellung der Webmentions, Pingbacks und Trackbacks. Wir sind gerade dabei, die Funktionalität in das Webmention Plugin zu übertragen, deshalb hat das Plugin aber nur noch temporär Bedeutung.

WebSub Plugin

WebSub (formerly known as: PubSubHubbub) ist ein simples PubSub Protokoll für das Web. Es wurde ursprünglich entwickelt um updates von RSS und Atom Feeds in „echtzeit“ zu konsumieren. Push statt pull. Die Restriktion auf RSS und Atom, wurde mit der aktuellen Version aufgehoben.

WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks. Subscription requests are relayed through hubs, which validate and verify the request. Hubs then distribute new and updated content to subscribers when it becomes available. WebSub was previously known as PubSubHubbub.

https://www.w3.org/TR/websub/

Über das WebSub Plugin (ursprünglich entwickelt von Josh Fraser) kann man die Standard-Feeds von WordPress abonnieren. Das Plugin kann aber auch über andere Plugins und Themes erweitert werden.

MF2 Feed Plugin

Das IndieWeb setzt im, Gegensatz zum Fediverse, nicht auf APIs, sondern auf Semantisches HTML:

The idea is rather than publishing something twice (repeating yourself) with (x)HTML for browsers and XML for aggregators – you simply publish once using (x)HTML and allow the tools to take care of the rest.

http://microformats.org/wiki/dry
Das Microformats Logo

In einer Welt in der jeder WordPress Theme Developer Wert auf Microformats, Schema.org oder Ähnliches achtet, funktioniert das Konzept super. Die Erfahrung zeigt aber, dass nur wenige Themes (seit fast 9 Jahren eigentlich sogar nur ein Theme) im WordPress.org Repo Microformats2 unterstützt.

Ich habe viel herum experimentiert um Themes über ein Plugin mit den nötigen Semantiken zu erweitern, was aber, durch Output Escaping, zu komischen Nebeneffekten geführt hat (das alles aber nur der Vollständigkeit halber, das Thema ist eigentlich einen ganzen Artikel wert).

Letztendlich haben wir für WordPress ein Plugin gebaut, das einen Feed bereit stellt, der genau dem JSON Format entspricht, welches auch die Microformats Parser ausspucken. Das Webmention Plugin sucht also erst den pre-parsed Feed und versucht erst im zweiten Schritt, die Seite selbst zu parsen.

Ihr versteht die Ironie? Microformats(2) sind geschaffen worden um XML/JSON APIs abzulösen und weil das bei WordPress nicht wirklich dolle funktioniert bieten wir die Infos als JSON API an! 😀

Decisions, not Options

Ich bin ein Freund von kleinen Plugins die nur einen spezifischen Anwendungsfall abdecken und im besten Fall auch vollkommen ohne Settings aus kommen. Frei nach dem Motto von WordPress:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.

https://wordpress.org/about/philosophy/#decisions

(Ironischerweise führt aber gerade das Fehlen von Settings oft für Verwirrung 😉 )

OpenGraph Plugin

Das Open Graph Protokoll wurde von Facebook entwickelt und hat einen ähnlichen Nutzen wie oEmbed:

The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook.

https://ogp.me

Es wird aktuell von fast jedem großen Netzwerk oder fast jeder Messaging App benutzt und sorgt dafür, dass ihr die kleinen hübschen Vorschausnippets seht, wenn ihr einen Link mit euren Freunden teilt.

Das OpenGraph Plugin wurde ursprünglich von Will Norris geschrieben und generiert alle notwendigen Meta-Tag Header. Keine Settings, keine Entscheidungen, aber mit wohl definierten Filtern zum erweitern.

Hum Plugin

Hum generiert schöne, semantische Short-URLs für WordPress Posts und Pages. Das Plugin ist ursprünglich auch von Will Norris, integriert sich in die WordPress Core-Funktionen und kommt auch komplett ohne Settings aus.

Hum basiert auf Whistle

Whistle is an open source, algorithmically reversible, personal URL shortener.

http://tantek.pbworks.com/w/page/21743973/Whistle

…und New Base 60

A base 60 numbering system using only ASCII numbers and letters.
or
a side effect of building a personal URL shortener

http://tantek.pbworks.com/w/page/19402946/NewBase60

…zwei Specs von Tantek Çelik.

Open Search Document Plugin

Die OpenSearch Spezifikation bietet Möglichkeiten um die lokale Blog-Suche für Browser oder Suchmaschinen zugänglich zu machen.

OpenSearch is a collection of simple formats for the sharing of search results.

https://github.com/dewitt/opensearch

Es gibt Integrationen für alle bekannten Browser wie z.B. Chrome, Safari, Firefox und Microsoft Edge.

Das Plugin wurde ursprünglich von johnnoone Entwickelt, es stellt eine XML Beschreibung der Suche und einen Endpunkt für Such-Vorschläge basierend auf Tags bereit.

Das wars auch schon 🙂

Mehr?

Natürlich gibt es noch mehr, das würde aber den Rahmen sprengen. Ich nutze WordPress gerne um neue Specs und Ideen auszuprobieren und daraus entstehen meist kleine Plugins, die es oft nicht wert sind, auf WordPress.org veröffentlichen zu werden.

Ihr könnt aber gerne:

Ihr könnt fast alle Plugins auch bequem über Composer installieren und updaten.

Ich freue mich IMMER über Hilfe, also feel free to contribute!

Torsten Landsiedel hatte 2019 die Idee zum #Projekt26:

  • Alle zwei Wochenmuss“ ein Blogartikel geschrieben werden.
  • Alle zwei Wochen „muss“ ein anderer Blogartikel kommentiert werden – das ist neu, aber wichtig, damit wir den Blog wieder als zentralen Ort für den Austausch nutzen und das nicht auf den Social Media Plattformen diverser Konzerne machen.
  • Das Thema sollte WordPress sein, angrenzende Themengebiete, wie CSS, JavaScript, etc. gehen natürlich auch. Bonuspunkte gibt es für Artikel zum Thema Gutenberg.
  • Der Hashtag lautet #projekt26 und sollte selbstredend bei der Bewerbung der Artikel genutzt werden.
  • Am liebsten sind mir echte, originäre Artikel, keine Zweiverwertungen, Listen, Linktipps, etc. – Faustformel könnte die Mindestlänge der VG Wort sein (1800 Zeichen).

Ich mag den Fokus auf WordPress, auch wenn das ja hier eher nicht mein Haupt-Thema ist. Das gibt meinem Blog aber ein wenig Abwechslung und ich schaffe es vielleicht mal über die ganzen Plugins zu schreiben, die ich in den letzten Jahren so verbrochen habe… und da wären wir ja wieder beim Thema 😉

Neben dem regelmäßigen Bloggen, mag ich aber auch den Punkt mit dem Kommentieren. Was uns in den letzten Jahren immer mehr verloren gegangen ist, woran ironischerweise die SOZIALEN Netzwerke nicht ganz unschuldig sind, ist der Diskurs direkt im Blog. (Das ist übrigens mit einer der Gründe warum ich das Webmention und ActivityPub Plugin geschrieben habe.)

Da ich in den letzten Jahren hier eher weniger aktiv war, motiviert mich die Idee der selbstauferlegte Druck hoffentlich, in diesem Jahr regelmäßiger zu schreiben.

…und dass ich diesen Artikel statt in Kalenderwoche 1 oder 2, erst jetzt schreibe, bestärkt mich nur noch mehr in dieser Ansicht!

(zum Glück kann man Artikel zurück datieren 😀 )