Vor einigen Wochen habe ich Ian Steward auf einem Automattic Meetup kennengelernt. Er kam auf mich zu, um mir zu erzählen, dass er kürzlich auf einen ziemlich alten Artikel von mir gestoßen ist. In diesem Artikel geht es darum, wie man die Reihenfolge der Sidebars im K2-WordPress-Theme ändert.

Ich habe K2 sehr lange auf notiz.Blog eingesetzt und mich viel und lange mit dessen technischem Aufbau und der semantischen HTML-Struktur beschäftigt!

Aber außer dem kurzen Schwelgen in alten Erinnerungen hab ich mir nicht weiter Gedanken zu dem Thema gemacht. Immerhin gibt es das Theme schon seit einer halben Ewigkeit nicht mehr und Sidebars sind auch aus der Mode!(?)!

Dann schreibt @ricmac letzte Woche aber folgendes auf Mastodon:

Sidebar Culture: remember things in your blog sidebar like blogrolls, “Influential articles”, Flickr photos, MyBlogLog (a proto-social network for bloggers). All this stuff and more helped make early 2000s blogging fun and more communal. Would love to find a way to bring that back in 2024…

https://mastodon.social/@ricmac/111477809540922177

…das hat mich dann doch noch einmal neugierig gemacht und ich habe eine alte notiz.Blog Version von 2008 (auf Basis von K2) raus gekramt.

Fast die Hälfte der Seite war Sidebar 😍

Vieles von damals hat mich schwer an den Artikel „The lost infrastructure of social media.“ von @anildash (und der IndieWeb Version davon) erinnert.

Ich bin gespannt was @ricmac sich einfallen lässt…

Thinking about a personal website re-design (or a new site), so I can play around with fediverse integration, sidebar culture, and other fun things. Thinking of using @eleventy (have used Hugo before and this seems better). Maybe a new site is better, as I don’t want to have to migrate ricmac.org from WordPress…for now, anyway. Is it normal for people to have two personal websites these days? I should just start a test site with 11ty and see how it goes…

https://mastodon.social/@ricmac/111489177217562043

… und ich werde die Position meiner Sidebar vielleicht nochmal überdenken!

Alles kommt wieder ☺️

Das Logo und der Wapuu von dem 20 Jahre WordPress Projekt

WordPress wurde 20 Jahre alt! 20 Jahre!

Vor etwas mehr als 20 Jahren bin ich über Brett Taylors wunderbar nerdiges Blog gestolpert: webfroot.co.nz

Am 04. April 2002 schreibt Brett: „News script is powered by b2, allowing for an RSS XML, better archive system, and improved comments system too.“

Das war Inspiration genug um einen Monat später mit meinem eigenen kleinen b2 Blog an den Start zu gehen.

Mittlerweile begleitet mich das kleine stückchen PHP-Code fast mein halbes Leben und ich hätte nie daran gedacht, dass ich mit meinem Hobby-Projekt irgendwann mein Geld verdienen würde!

Happy Birthday WordPress!

„The early years“

Zum 15. Jubiläum habe ich angefangen meine „WordPress Origin Story“ zu dokumentieren. Der Vollständigkeit halber hier also die folgenden 5 Jahre 😉

2019

2019 stand im Zeichen des ActivityPub Plugins. Hätte ich damals gewusst… 😉

2020

Während meinen 7++ Jahren bei IONOS hatte ich nebenher immer mal wieder mit WordPress zu tun. 2020 bekam ich aber die Möglichkeit, mit einem kleinen Team zusammen, das WordPress Hosting neu/mit zu gestalten. Aus diesem kleinen dreiköpfigen WordPress-Team wurde in den folgenden drei Jahren ein großartiges Haufen von 15+ Personen (inklusive Support, PO, PM, …).

Neben dem daily business haben wir IONOS in dieser Zeit ein kleines bisschen näher an die Community „geschubst“ (zumindest rede ich mir das ein 😉 ). Wir haben einen GitHub Account gestartet, den Entwicklern Zeit für die Five for the Future Initiative frei geräumt und IONOS wurde Teil der (Make) Hosting Community.

In diesem Zuge habe ich mich auch persönlich engagiert und dafür im Juni das Hosting Team Badge „verliehen“ bekommen.

2021

Mein aktivstes Jahr beim Pluginkollektiv. Ich mag die Idee und schätze die Plugins sehr! Ich hoffe ich finde in Zukunft wieder etwas mehr Zeit für das Kollektiv, immerhin arbeite ich ja jetzt hauptberuflich an ActivityPub & Co. und brauche deshalb wieder ein neues Hobbie/Freizeitprojekt 😉

2022

Im März fand der CloudFest Hackathon im Europa-Park statt und ich hatte die Chance, ein Thema zu betreuen. Drei Tage WordPress, IndieWeb und Webmentions <3

2023

…und meine große Klappe auf Twitter, hat dafür gesorgt, dass ich seit diesem Jahr einen neuen Job habe.

Seit April darf ich mich from 9 to 5 mit dem „Open Web“ beschäftigen und bekomme dafür auch noch Geld!

Vielen Dank Matt und vielen Dank Automattic!

…dazu aber später nochmal mehr 🙂

Ich bin gespannt was dieses Jahr noch mit sich bringt und wie die Zukunft von WordPress aussieht.

Wenn es nach mir ginge, dann würde daraus ein „open, portable, interoperable, small, social, synaptic, semantic, structured, distributed, (re-)decentralized, independent, microformatted and federated social“ WordPress 😉

Ein Screenshot meines ersten Blogposts im Mai 2002

Heute vor 20 Jahren habe ich mit dem Bloggen angefangen! Das heißt ich schreibe jetzt fast mein halbes Leben lang Dinge in’s Internet!

Von 2002 bis 2005 ging es viel um persönliches und privates. Ich hatte ein Blog mit Freunden, das oft auch einfach als Ersatz zu einem Messenger benutzt wurde.

2005 hab ich dann angefangen hier zu bloggen. Von 2005 bis 2007 waren mein Studium, Web-Technologien und das Web 2.0 die großen Themen auf notiz.Blog. Ich war fasziniert von der Blogosphäre und den sozialen Netzwerken die (damals noch als die Guten) so nach und nach entstanden.

Ab 2007 entwickelten sich die großen „Communities“ immer mehr zu „Walled Gardens“ und ich schrieb und beschäftigte mich bis 2010 viel mit den Themen „Dezentrale Netzwerke“ und „Data Portability„.

Seit 2007 hab ich auch angefangen mich intensiver mit meiner Blogging-Plattform WordPress zu beschäftigen. Dadurch ist wesentlich mehr Code als Text entstanden und wenn ich zum schreiben kam, ging es meistens um die Entwicklung von Plugins und (dem einen) Theme(s).

Die Themen ab 2007 sind im Prinzip auch die Themen um die es bis heute geht. Wenig bis nichts persönliches, viel Technik, WordPress und noch mehr Open Web. Das ist OK für den Moment, muss aber nicht so bleiben 🙂

Auf die nächsten 20 Jahre! 🎉

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?

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 😀 )

Ich hatte es im Januar 2019 schon einmal erwähnt: Ich arbeite gerade an einem ActivityPub Plugin für WordPress. Da ich das ganze in meiner Freizeit mache, hat das auch seine Zeit gedauert, aber gerade ist es in einem ganz stabilen Zustand… immerhin funktioniert es mit den meisten bekannten Plattformen:

Es gibt zwar immer noch ’ne Menge zu tun, aber immerhin kann man:

  • dem eigenen Blog-Profil (Author-URL) auf Mastodon & Co. folgen
  • Blog-Posts werden mit den Followern geteilt
  • Kommentare auf Mastodon & Co. landen wieder im Blog

Ihr könnt das Plugin über WordPress.org oder GitHub installieren.

Wer Ideen hat oder Hilfe braucht, findet mich (immer mal wieder) im SocialHub von ActivitPub.rocks.

Ich bin gespannt auf euer Feedback!

Ich war am 05. August zu Besuch beim WordPress Meetup in Stuttgart um über das IndieWeb und WordPress zu sprechen. Wer es nicht sehen konnte, kann das hier nachholen:

Hier klicken, um den Inhalt von WordPress.tv anzuzeigen.
Erfahre mehr in der Datenschutzerklärung von WordPress.tv.

Ein großer Teil des Vortrags war eine Live-Demo, die nicht immer ganz perfekt geklappt hat, aber es war ein Versuch. Nächstes Mal wird besser… Versprochen 😉