und willkommen zur neuen Ausgabe meines Newsletters, den ich künftig wieder regelmäßig, nämlich alle zwei Wochen, verschicken werde. Ich nutze einen neuen Dienstleister und werde in den kommenden Wochen sicherlich noch an den Stellschrauben drehen müssen. Ich freue mich, wenn du weiterhin dabei bleibst.

Diese Woche werfe ich einen Blick auf Substack und deren Umgang mit Nazis auf der Plattform und wie man, meiner Meinung nach, in einem offenen Web damit umgehen sollte.

. . .

Ein offenes Web schließt alle mit ein, warum regen sich dann gerade alle darüber auf, dass auch Nazis Dienste und Plattformen nutzen, um Geld zu verdienen und Reichweite zu bekommen?

Vor wenigen Wochen schwappte eine Welle der Empörung durch das Netz, als herauskam, dass Substack verwendet wird, um antisemitische Inhalte zu verbreiten. Nazis im Web sind nichts Neues, warum also die Aufregung, schließlich darf in einem offenen Web doch jeder sagen, was er will?

Der Reihe nach.

Substack, was ist das eigentlich? Substack ist eine Newsletter-Plattform, die sich in den vergangenen Jahren zunehmender Beliebtheit erfreut.

Denn Substack hat sich vom reinen Dienstleister zum Verschicken von Newslettern weiterentwickelt und einen großen Fokus darauf gelegt, Newsletter besser auffindbar zu machen, Inhalte zu empfehlen und – ähnlich wie medium.com – eine Infrastruktur geschaffen, die es ermöglicht mit dem eigenen Newsletter Geld zu verdienen.

Wer einen Substack-Newsletter betreibt, kann die Empfängerinnen zu Abonnentinnen machen. Nur wer Geld bezahlt, bekommt dann auch die E-Mails zugeschickt. Bald machten die ersten Erzählungen die Runde, wie toll man doch mit Substack Geld verdienen kann. Das lockt natürlich viele Interessenten.

Nun konnten aber nicht nur nette, zuvorkommende Autorinnen mit Substack Geld verdienen, sondern auch Nazis. Das fand The Atlantic heraus. Antisemitische Inhalte wurden nicht nur verbreitet, sondern hätten im schlimmsten Fall sogar weiterempfohlen oder gar finanziell unterstützt werden können.
Substack hat nicht eingegriffen und will nach eigener Aussage möglichst viel Redefreiheit und möglichst wenig Zensur bieten, im Gegenteil, man halte das für einen Fehler, der alles nur noch schlimmer mache:

. . .

I just want to make it clear that we don’t like Nazis either—we wish no-one held those views. But some people do hold those and other extreme views. Given that, we don’t think that censorship (including through demonetizing publications) makes the problem go away—in fact, it makes it worse.

. . .

Die Reaktionen auf diese Aussagen vielen nicht besonders positiv aus. Die Argumente sind auch nicht neu, wir kennen sie zum Beispiel auch von Ex-Twitter und sogar von Facebook, die aber inzwischen ihre Richtlinie angepasst haben.

Aber wir sind doch im offenen Web, in dem jeder sagen kann, was er will. Das ist natürlich richtig und wichtig. Redefreiheit ist ein hohes Gut und sollte gewahrt werden. Das schließt auch Meinungen ein, die einem nicht gefallen oder die unangenehm sind.

Dass das ebenfalls Antisemitismus und Nazipropaganda einschließt, ist jedoch vollkommener Quatsch.

Wie alles, hat auch die Redefreiheit ihre Grenzen. Und eine dieser Grenzen, eine Grenze, die unüberwindbar sein sollte, eine Grenze, die nicht debattierbar ist, ist die Menschenwürde. Im Grundgesetzt klingt das so:

. . .

(1) Die Würde des Menschen ist unantastbar. Sie zu achten und zu schützen ist Verpflichtung aller staatlichen Gewalt.

(2) Das Deutsche Volk bekennt sich darum zu unverletzlichen und unveräußerlichen Menschenrechten als Grundlage jeder menschlichen Gemeinschaft, des Friedens und der Gerechtigkeit in der Welt.

Grundgesetz für die Bundesrepublik Deutschland

. . .

Jegliche Form von Antisemitismus ist damit zu bekämpfen.

Und auch Artikel 2 zementiert dies noch einmal:

. . .

(1) Jeder hat das Recht auf die freie Entfaltung seiner Persönlichkeit, soweit er nicht die Rechte anderer verletzt und nicht gegen die verfassungsmäßige Ordnung oder das Sittengesetz verstößt.

(2) Jeder hat das Recht auf Leben und körperliche Unversehrtheit. Die Freiheit der Person ist unverletzlich. In diese Rechte darf nur aufgrund eines Gesetzes eingegriffen werden.

Ebda

. . .

Hätten wir das also geklärt.

Nun gibt es wahrscheinlich auf jeder größeren Plattform auch Nazis, die sich dort breit machen. Bei manchen Plattformen fallen sie mehr auf als auf anderen.

Je größer eine Plattform wird, desto höher ist auch die Wahrscheinlichkeit, dass dort Nazis und antisemitische Inhalte zu finden sind. Je größer eine Plattform wird, desto schwieriger wird es auch, Inhalte zu moderieren und zu filtern. Viele Plattformen versuchen sich dieser schwierigen Verantwortung zu entziehen, indem sie sagen, dass sie nur Infrastruktur bereitstellen und mit den eigentlichen Inhalten nichts zu tun haben.

Wer aber anfängt, Inhalte zu empfehlen, Algorithmen zu entwickeln, die ähnliche Accounts vorschlagen, stellt ebene nicht mehr nur Infrastruktur zur Verfügung. Und muss seiner Moderationspflicht nachkommen. Wenn das passiert nicht passiert, weil man nicht "zensieren" will, ist das schlimm genug, richtig widerlich wird es dann, wenn auch nach einer Meldung von Beiträgen oder Profilen nichts passiert.

Über 200 Substack-Autor:innen haben sich zusammengetan und einen Brief an Substack geschrieben, der auf die Situation aufmerksam machen sollte.

Reagiert hat Substack so schlecht, wie es eben geht. Man wolle eben nicht zensieren. Erst nach massivem Druck von außen hat sich Substack überwunden und eine Handvoll Accounts gesperrt.

Wirklich ändern wolle man aber nichts, ein wenig genauer hinschauen vielleicht. Weiterhin wolle man für Dezentralität und Freiheit stehen. Die Redefreiheit endet laut The Verge bei Substack scheinbar nicht bei Nazis, sehr wohl aber untenherum, denn der dezentrale Moderationsansatz

. . .

[…] does not allow content it deems as spam, or written by sex workers, but does allow Nazis.

. . .

The Platformer schrieb dazu noch ganz richtig:

. . .

If it won’t remove the Nazis, why should we expect the platform to remove any other harm?

. . .

Viele Autor:innen wechseln nun also den Dienst. Denn es gibt einige Alternativen zu Substack.

Aber natürlich sind wir auch dort nicht vor Antisemitismus gefeit. Da, wo wir Demokratinnen uns registrieren können, können sich auch Nazis registrieren. Es bleibt aber zu hoffen, dass die nächste Plattform einen besseren Umgang pflegt und konsequent durchgreift.

Die größte Sicherheit vor Antisemiten in unserer virtuellen Nachbarschaft ist wahrscheinlich die eigene Webseite. Damit machen wir uns maximal unabhängig, müssen aber an einigen Stellen ggf. auf etwas Komfort verzichten. Das ist es meiner Meinung nach aber wert.

Ganz sicher können wir jedoch auch dann nicht sein, denn schließlich könnte es auch sein, dass der gewählte Hoster ebenfalls von Nazis genutzt wird. Wir müssen also wachsam bleiben, den Finger immer wieder in die Wunde legen und für ein echtes offenes Web kämpfen. Ein Web, das auf dem wichtigsten Grundsatz fußt, dass die Menschenwürde unantastbar ist.

Danke, dass Du meinen RSS-Feed abonniert hast!

Danke, dass Du meinen RSS-Feed abonniert hast!

Unter den Beiträgen auf meiner Webseite, möchte ich weitere Artikel empfehlen, die zum Thema passen. In den ersten Versionen meiner Webseite habe ich diese Auswahl noch selbst vorgenommen. Das ist natürlich mit der Zeit etwas umständlich, denn es kommen schließlich ständig neue Beiträge hinzu und die Relevanz untereinander ändert sich laufend. Ich müsste also immer wieder alte Artikel bearbeiten, damit die Zuordnungen wieder stimmen.

Natürlich war und bin ich nicht der Einzige, der so etwas auf seiner Webseiten hat. Weshalb es schnell entsprechende Kirby-Plugins und diesen Cookbook-Artikel gab.

Nach einiger Zeit stelle sich für mich allerdings heraus, dass die angebotenen Plugins und Beispiele nicht die Ergebnisse lieferten, die ich mich vorgestellt habe. Deshalb habe mich dazu entschlossen, mich genauer mit dem Thema auseinanderzusetzen und eine eigene Lösung zu bauen.

Auch abseits von "Related Posts" finde ich das Thema "Auffindbarkeit" extrem spannend. Wir alle haven vermutlich irgendwo Inhalte im Netz, von denen wir wollen, dass sie nicht sang- und klanglos in der Masse untergehen. Im großen Maßstab möchte man in Suchmaschinen gefunden werden, im kleineren Maßstab sind es vielleicht Empfehlungen zu anderen Beiträgen auf der eigenen Webseite.

Für Kirby gibt es aktuell ein Plugin, was sich dem Problem annimmt: Similar.

Similar hatte ich eine ganze Weile im Einsatz, an einigem Stellen, war es mir aber nicht genau genug und das habe ich auch durchs Verfeinern von Einstellungen nicht in den Griff bekommen. Ich habe mir dann angesehen, wie Sonja die Sache angeht und mir ein paar Ideen gestohlen und auf meine Seite übertragen.

Um ähnliche Beiträge zu finden, werde ich auf drei Content-Felder zurückgreifen:

1. Tags
2. Text
3. Titel

Tags

Ich verpasse jedem Beitrag, den ich veröffentliche, mehr oder weniger viele Tags. Dazu verwende ich Kirbys Tag-Field. Tags sind bei mir global, das heißt, dass ich mir von allen Seiten alle Tags hole und mir diese dann als Autocomplete anzeigen lasse.

Im Panel sieht das so aus:

Das passende Blueprint dazu wie folgt:

label: Tags
type: tags
options: query
query: site.index.pluck("tags", ",", true)
translate: false

Via query hole ich mir den Inhalt aller Tag-Felder, um diese als Autocomplete zu haben. Eine Übersetzung soll nicht möglich sein, die Tags gelten für jede Sprache.

Diese Tags als Quelle für relevante Seiten zu verwenden, ist einfach. Zunächst hole ich mir die Tags der aktuellen Seite. Dann schaue ich in allen anderen veröffentlichten Seiten nach gleichen Tags:

$tags = $this->tags()->split(',');
$pagesWithTags = site()->index()->published()->filterBy('tags', 'in', $tags, ',')->not($this);

Da ich die Suche nach Related Pages in einem Page-Method-Plugin aufrufe, verweist in all diesen Beispielen $this auf die aktuelle Seite. Nachdem ich alle Tags der aktuellen Seite habe, filtere ich alle anderen Seiten nach diesen Tags. Als Resultat bekomme ich eine Liste an Seiten, die alle mindestens einen Tag mit meiner aktuellen Seite gemeinsam haben.

Da die aktuelle Seite auf jeden Fall immer im Resultat vorkommen würde, schließe ich sie noch aus, ich will natürlich nicht auf dieselbe Seite verweisen.

Jetzt könnte ich schon alle Seiten mit denselben Tags auflisten, das ist mir aber nicht genau genug. Viel mehr möchte ich noch in der Lage sein, den drei oben genannten Feldern eine Gewichtung zu geben. Das habe ich von Sonja geklaut.

Dazu gehe ich alle gefunden Seite noch einmal durch, hole mir die einzelnen Tags jeder Seite und lasse mir nur die Tags zurückgeben, die auch in der aktuellen Seite hinterlegt sind.

Hat meine aktuelle Seite die Tags kirby, cms und plugin, die ähnliche Seite kirby, cms und theme bekomme ich auf diese Weise die beiden identischen Tags kirby und cms als Ergebnis zurück.

Um mir alle ähnlichen Seiten zu merken, fülle ich ein Array. Ich will an dieser Stelle nicht die gesamte Seite speichern, sondern lediglich ihre ID, über die ich dann später wieder auf sie zugreifen kann.

Außerdem möchte ich wissen, wie relevant jede einzelne Seite wirklich ist, dazu zähle ich die identischen Tags und errechne daraus eine Gewichtung. Wie stark jedes Feld gewichtet werden soll, kann ich später in meiner config.php ändern:

foreach($pagesWithTags as $page) {
    $pageTags = $page->tags()->split(',');
    $similarTags = array_intersect($pageTags, $tags);
    $uuid = $page->uuid()->toString();

    $similarPages[] = [
        'page' => $uuid,
        'weight' => count($similarTags) * option('mauricerenck.similar-related.tags.weight', 1),
    ];
}

Als Ergebnis habe ich nun eine Liste von Seiten und ihre jeweilige Gewichtung.

Titel

Im nächsten Schritt schnappe ich mir den Titel, um auch hier Ähnlichkeiten zu erkennen. Das ist nicht ganz so naheliegend, wie es bei den Tags war, aber auch recht unkompliziert umzusetzen.

Um Ähnlichkeiten zu finden, vergleiche ich alle Titel Wort für Wort. Dazu hole ich mir den Titel der aktuellen Seite und teile ihn in seine Bestandteile. Dann geht es wieder an das Filtern aller veröffentlichten Seiten. Dieses Mal mit einem eigenen Filter.

Für jede dieser Seiten hole ich mir den Titel und teile ihn in einzelne Worte. Ich habe nun ein Array mit Worten von beiden Titeln und kann diese vergleichen. Wie bei den Tags schaue ich jetzt, ob es mindestens eine Übereinstimmung gibt. Gibt es die, bekomme ich die Seite als Ergebnis zurück. Und natürlich möchte ich auch hier die aktuelle Seite ausschließen:

$wordsFromTitle = $this->title()->split(' ');
$pagesWithTitle = site()->index()->published()->filter(function($child) use($wordsFromTitle) {
    $wordsFromChildTitle = $child->title()->split(' ');
    return count(array_intersect($wordsFromTitle, $wordsFromChildTitle)) > 0;
})->not($this);

Im nächsten Schritt geht es wieder daran, das Ergebnis-Array zu füllen. Wieder gehe ich durch alle gefundenen Seiten und gewichte sie. Das funktioniert genauso wie bei den Tags:

foreach($pagesWithTitle as $page) {
    $wordsFromPageTitle = $page->title()->split(' ');
    $similarWords = array_intersect($wordsFromTitle, $wordsFromPageTitle);

    $uuid = $page->uuid()->toString();

    $similarPages[] = [
        'page' => $uuid,
        'weight' => count($similarWords) * option('mauricerenck.similar-related.title.weight', 0.5),
    ];
}

Text

Schließlich kommen wir zum aufwändigsten Feldtypen. Ich möchte so weit gehen, dass ich sogar jeden einzelnen Text Wort für Wort miteinander vergleiche. Hier wird es etwas knifflig, denn ich muss auch hier den gesamten Text in seine einzelnen Worte aufteilen. Das kann bei einem langen Text natürlich eine ziemlich lange Wortliste werden und trägt sicherlich nicht dazu bei, dass die Seite schneller lädt. Dazu aber später mehr.

Ich hole mir auch hier das Feld als Quelle und teile es in einzelne Worte. In diesem Fall möchte ich nur Worte haben, die länger als ein Zeichen sind. Das schließt im Englischen schon mal ein paar Füllwörter wie I oder a aus:

$wordsFromText = $this->text()->split(' ');
$wordsFromText = array_filter($wordsFromText, function($word) {
    return strlen($word) > 1;
});

Nun geht es ans Aufräumen, ich möchte nur "echte" Wörter haben:

$wordsFromText = array_map(function($word) {
    return preg_replace('/[^A-Za-z0-9\-]/', '', $word);
}, $wordsFromText);

Jetzt wird es interessant. Um ein möglichst genaues Ergebnis zu bekommen, werde ich bestimmte Worte ausschließen. Das sind Worte, die im eigentlichen Sinne nichts mit dem Inhalt zu tun haben. Schwer zu beschreiben. Hier ein Beispiel:

Meine Seite besteht aus diesem Text:

Ich möchte eine Webseite mit dem CMS Kirby erstellen, dazu schreibe ich mir ein Blueprint und ein Template

Für meinen Vergleich interessieren mich bestimmte Worte gar nicht, etwa Ich, eine, mit, dem, ein, … Diese Worte kommen in so gut wie jedem Text vor und würden das Ergebnis verwässern. Wirklich interessant sind hier nur Worte wie Webseite, CMS, Kirby, Blueprint und Template.

Würde ich ausschließlich auf Deutsch schreiben, könnte ich mir das Leben recht einfach machen und einfach alle großgeschriebenen Worte holen. Im Englischen funktioniert das allerdings nicht.

Wie also vorgehen? Ich habe eine sehr lange Liste von sogenannten Stopwords. Das sind solche Füllwörter, wie oben beschrieben. Zum Glück bin ich nicht der Einzige, der vor so einem Problem steht und es gibt ein paar gut gepflegte Listen da draußen im Netz. Ich habe mich für die ISO-Stopwords entschieden, die gleich in mehreren Sprachen daher kommen.

Die Daten liegen mir als JSON-Datei vor. Ich muss die Datei laden. Vorher hole ich mir die Sprache der aktuellen Seite. In meinem Fall ist das entweder Deutsch oder Englisch:

$pageLanguage = kirby()->language()->code() ?? 'en';
$stopWordsForLanguage = [];

$languagesJson = file_get_contents(__DIR__ . '/stopwords-iso.json');

if($languagesJson !== false) {
    $stopWords = json_decode($languagesJson);
    $stopWordsForLanguage = (isset($stopWords->$pageLanguage)) ? $stopWords->$pageLanguage : $stopWords->en;
}

Sicherheitshalber prüfe ich noch, ob die Datei geladen werden konnte. Wenn nicht, gibt es einfach eine leere Liste. Ansonsten schaue ich nach, ob die aktuelle Sprache in den Daten vorhanden ist. Sollte das nicht der Fall sein, greift mein Fallback und ich nutze Englisch.

Nun geht es wieder ans Filtern. Ich entferne alle Stopwords aus der Wortliste der aktuellen Seite:

$wordsFromText = array_filter($wordsFromText, function($word) use($stopWordsForLanguage) {
    return !in_array(strtolower($word), $stopWordsForLanguage);
});

Und jetzt gehe ich den üblichen Weg mit einem eigenen Filter über alle Seiten. Dieses Mal vergleiche die Worte des Textes. Da ich in meinem Quelldaten jetzt schon keine Stopwords mehr habe, muss ich sie nicht auch noch bei jeder einzelnen Seite herausfiltern:

$pagesWithText = site()->index()->published()->filter(function($child) use($wordsFromText) {

    if($child->text()->isEmpty()) return false;
    $wordsFromChildText = $child->text()->split(' ');

    return count(array_intersect($wordsFromText, $wordsFromChildText)) > 0;

})->not($this);

Ich prüfe ich noch, ob die Seite auch wirklich einen Text hat. Es könnte Seiten geben, die nur ein Listing sind oder Blöcke oder Layouts nutzen. Die will ich nicht in meinem Ergebnis haben und schließe sie direkt aus. Den Rest prüfe ich wieder auf mindestens eine Übereinstimmung und nehme sie entsprechend in die Liste auf.

Jetzt geht es wieder in die Schleife durch alle Resultate und ans Füllen des Ergebnis-Arrays:

foreach($pagesWithText as $page) {

    $wordsFromPageText = $child->text()->split(' ');
    $similarWords = array_intersect($wordsFromText, $wordsFromPageText);
    $uuid = $page->uuid()->toString();

    $similarPages[] = [
        'page' => $uuid,
        'weight' => count($similarWords) * option('mauricerenck.similar-related.text.weight', 0.95),
    ];

}

Nun habe ich im besten Fall eine sehr lange Liste an ähnlichen Seiten. Manche dieser Seiten haben dieselben Tags, manche einen ähnlichen Titel oder Text. Es kann sein, dass Seiten mehrfach vorkommen, das ist sogar sehr wahrscheinlich, denn wenn die Tags sich schon gleichen, dann werden sich vermutlich auch Textfragmente gleichen. Hat eine Seite den Tag kirby, ist die Wahrscheinlichkeit ziemlich hoch, dass auch im Fließtext das Wort Kirby vorkommt und die Seite demnach zweimal in der Liste zu finden ist.

Es gibt zwei Möglichkeiten, damit umzugehen:

Ich könnte von Anfang an, doppelte Seiten ausschließen. Habe ich schon eine Liste an Seiten, die ähnliche Tags haben, könnte ich diese beim Abfragen ähnlicher Titel bereits ausschließen. Beim Text könnte ich dann bereits Seiten ausschließen, die sowohl ähnliche Tags als auch Titel haben.

Ich möchte hier aber etwas schlauer damit umgehen. Ich gehe davon aus, dass eine Seite, die ähnliche Tags und einen ähnlichen Titel und einen ähnlichen Text hat, viel relevanter ist, als eine Seite, die sich nur einen Tag teilt oder in der sich ein paar gleiche Worte wiederfinden.

Deshalb ist der nächste Schritt das Zusammenführen der Daten und die Gewichtung der jeweiligen Seite unter Rücksichtnahme verschiedener Vorkommen:

$result = [];
foreach($similarPages as $page) {
    $uuid = $page['page'];

    if(!isset($result[$uuid])) {
        $result[$uuid] = [
            'page' => $uuid,
            'weight' => $page['weight'],
        ];
    } else {
        $result[$uuid]['weight'] += $page['weight'];
    }
}

Zuerst erstelle ich mir ein leeres Array für mein Ergebnis, dann gehe ich durch alle ähnlichen Seiten und hole mir ihre UUID. Taucht die Seite bisher nicht in meiner Ergebnisliste auf, füge ich sie hinzu. Als Array-Schlüssel nutze ich ihre UUID, wieder merke ich mir die UUID und die Gewichtung.

Taucht die Seite bereits in der Liste auf, füge ich sie nicht erneut hinzu, sondern addiere die Gewichtung. Steht eine Seite also dreimal in der Liste, nämlich mit Tags, Titel und Text, so werden alle drei Gewichtungen addiert.

Schließlich habe ich eine Liste aller Seiten, ohne Duplikate, mit der Summe Ihrer jeweiligen Gewichtungen. Jetzt möchte ich sie noch nach Gewicht sortieren:

usort($result, fn($a, $b) => $a['weight'] <=> $b['weight']);

Da ich in meinem Template wenig mit einem Array von UUIDs anfangen kann, wird mein Ergebnis im letzten Schritt noch in eine Page Collection umgewandelt:

$pages = array_map(function($page) {
    return page($page['page']);
}, array_reverse($result)) ?? [];

Als Ergebnis habe ich nun eine Collection aller passenden Seite, mit der ich nun im Template arbeiten kann. Ich kann mir also von jeder Seite den Titel mit $pageFromCollection->title(); ausgeben lassen, oder meine Collection noch einmal filtern.

Ich muss meine Collection noch ans Template zurückgeben:

return new Collection($pages);

Das ganze Konstrukt habe ich in ein Plugin verpackt und als pageMethod zur Verfügung gestellt:

kirby::plugin('mauricerenck/related-pages', [
    'pageMethods' => [
    'relatedPages' => function () {
        // CODE
    }
];

In meinem Template kann ich indessen einfach diese Methode aufrufen, bekomme eine Collection von Seiten zurück und kann damit etwas anstellen. Ich limitiere sie noch auf drei Einträge und zeige diese dann in einer Schleife an:

$related = $page->relatedPages()->limit(3);

// Render related pages

Ein Wort der Warnung

Ich bin mit dem Ergebnis sehr zufrieden. Die Related-Pages, die auf den Seiten angezeigt werden, passen meist ziemlich gut. Ich überlege noch, ob den ich den zeitlichen Aspekt einbringe, also neuere Seiten höher gewichte, als ältere Seiten.

Was jedoch gesagt werden muss: Bei einer Webseite mit ziemlich vielen Seiten und/oder langen Texten könnte der Ansatz zu Problemen führen. Da passiert ziemlich viel, gerade beim Textvergleich und das kann unter Umständen lange dauern, im schlimmsten Fall zu Timeouts oder Speicherüberläufen führen.

Vermutlich wäre es daher schlauer, den ganzen Prozess nicht bei jedem Seitenaufruf durchzuführen, sondern via Cronjob oder Hook. Das Ergebnis könnte man dann in der jeweiligen Seite speichern. Beim Aufruf der Seite muss dann nichts mehr berechnet werden.

Für mich wäre das der nächste Schritt meines kleinen Plugins. Derzeit läuft es theoretisch noch bei jedem Seitenaufruf. Das sehe ich bei mir als nicht so kritisch an, weil ich alle Seiten cache. Der Cache wird nur geleert, wenn ich den Code der Seite aktualisiere, oder der Inhalt sich ändert. Dann wird beim Seitenaufruf das obige Prozedere durchlaufen, danach aber nur noch statisches HTML ausgeliefert. Geschwindigkeitseinbußen kann ich auf meiner Seite bisher nicht feststellen.

Ich überlege, meinen Code noch etwas zu sortieren, vielleicht obige Anmerkungen noch einzubauen und dann zu veröffentlichen. Allerdings nur, wenn Interesse besteht – das Plugin von Sonja funktioniert ja hervorragend.

Lass mich doch wissen, ob du das Plugin nutzen würdest!

Danke, dass Du meinen RSS-Feed abonniert hast!

Danke, dass Du meinen RSS-Feed abonniert hast!

Danke, dass Du meinen RSS-Feed abonniert hast!

Deine Podcasts sind jetzt ein wenig inklusiver. Apple führt automatische Transkripte ein, und das Podcaster-Plugin enthält jetzt auch eine neue Transkriptfunktion. Diese ermöglicht es dir, Transkriptdateien im VTT- oder SRT-Format hochzuladen und jedem Transkript eine Sprache zuzuweisen.

Auf diese Weise kannst du Apple (und anderen) Transkripte bereitstellen, ohne auf deren automatische Generierung angewiesen zu sein. Öffne einfach den Episoden-Tab, und du findest ein neues Feld unter dem Audio-Upload. Sobald du ein Transkript hochlädst, werden sie zu deinem RSS-Feed hinzugefügt und stehen allen Playern zur Verfügung, die diese Funktionalität unterstützen.

Das neueste Update ist über Composer oder die Podcaster-Website verfügbar.

Viel Spaß beim Podcasten!

Danke, dass Du meinen RSS-Feed abonniert hast!

File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom.

Love that!

Danke, dass Du meinen RSS-Feed abonniert hast!

Matthias betreibt den ganz wunderbaren Newsletter Own Your Web, der sich alle zwei Wochen mit Themen rund um die eigene Webseite befasst. In der achten Ausgabe beschäftigt Matthias sich mit Blogrolls.

Beim Lesen des Newsletters werde ich immer ein wenig nostalgisch, weil oft Themen aufgebracht werden, die es schon so lange gibt, die aber etwas verloren gegangen sind. Blogrolls gehören sicherlich dazu.

Sie stammen noch aus den Anfangszeiten der Blogs und dienen der Vernetzung. Im Grunde sind Blogrolls nichts anderes als einfache Listen von Blogs, die man selbst gerne liest und anderen ans Herz legen möchte. Das hat Matthias aber hier schon wunderbar und viel detaillierter erklärt.

Ich habe auch eine Blogroll. Die fand man bis zum letzten Redesign ganz klassisch in der Seitenleiste meines Blogs. Inzwischen gibt es diese Seitenleiste aber nicht mehr, sondern der ganze Spaß ist runter in Richtung Footer gewandert.

In den Replies auf Matthias Artikel haben viele Blogger:innen einen direkten Link zur eigenen Blogroll gepostet, sie haben also nicht nur irgendwo in der Seitenleiste eine Liste mit Blogs (wie ich), sondern zusätzlich eine dedizierte Seite.

Die Idee finde ich ziemlich gut. Gerade, wenn alle Blogger:innen sich an das gleiche Muster halten und man in jedem Blog einfach /blogroll an die Url hängen könnte, um eben jene zu sehen.

Ich hatte auch mein eine eigene Seite für die Blogroll. Die lag damals als "echte" Seite im CMS und das hat mich gestört, weil sie neben den Blogposts so ein wenig aus der Reihe fiel. Ich habe sie dann eingestampft und pflege meine Blogroll jetzt einfach direkt in den Blog-Settings.

Inzwischen kann ich mich etwas besser mit Kirby aus und würde Dinge anders umsetzen als damals – außerdem hat Kirby inzwischen zahlreiche weitere Features verabreicht bekommen, weshalb ich das Thema Blogroll jetzt noch einmal neu angegangen bin. Ich habe nun auch eine dedizierte Seite, die meine Blogroll ausliefert, ohne dass diese Seite im CMS existiert. Ich erkläre drüben im Hub, wie ich das gemacht habe.

Schaut euch auf jeden Fall Matthias Newsletter an und vielleicht baut ihr euch ja dann auch noch eine Blogroll ins eigene Blog ein!

Danke, dass Du meinen RSS-Feed abonniert hast!

In meinem Blog gibt es seit geraumer Zeit eine Blogroll. Was genau es damit auf sich hat, habe ich hier beschrieben. An dieser Stelle möchte ich erklären, wie ich meine Blogroll mit Kirby umgesetzt habe.

Meine Blogroll ist ziemlich simpel aufgebaut: In meinem Blog-Blueprint habe ich ein Structure-Feld, welches lediglich aus zwei Feldern besteht:

1. Der URL des Blogs
2. Dem Titel des Blogs

Bisher wurde unter meinem Bloglisting unter anderem die Blogroll in Icon-Form angezeigt. Das möchte ich erweitern, sodass die Blogroll auch unter /blog/blogroll erreichbar ist und ich somit einen Deeplink habe.

Da ich die Blogroll nicht als eigenständige Seite im CMS liegen haben möchte, werde ich eine Route für die Blogroll anlegen und dort eine virtuelle Seite ausspielen.

Die Route

In der Datei site/config/config.php lege ich eine neue Route. Ich möchte, dass die Blogroll unter allen Sprachen unter blog/blogroll erreichbar ist:

[
    'pattern' => 'blog/blogroll',
    'language' => '*',
    'action' => function ($language) {
      // […]
    }
]

Damit kann die Seite unter der entsprechenden URL ausgeliefert werden. Würden wir diese URL jetzt aufrufen, bekämen wir allerdings einen 404-Fehler an den Kopf geworfen. Eine Route benötigt immer entweder eine Ausgabe oder muss auf eine andere Route weiterleiten.

Deshalb lege ich im nächsten Schritt eine virtuelle Seite an, die wir dann zurückgeben können:

    $data = [
        'slug' => 'blogroll',
        'parent' => page('blog'),
        'template' => 'listing-blogroll',
        'translations' => []
    ];

    $page = Page::factory($data);
    site()->visit($page, $language);

    return $page;

Zunächst lege ich den Slug fest, also blogroll, dann gebe ich die übergeordnete Seite an, in meinem Fall das Blog. Schließlich benötigt die Seite noch ein Template, damit sie gerendert werden kann. Ich verwende hier ein spezielles Blogroll-Template. Auf die Übersetzungen werde ich später noch zu sprechen kommen.

Template

Ich werde hier nicht das komplette Template beschreiben, sondern nur die relevanten Teile. Das sind im Wesentlichen der Seitenkopf mit einer kurzen Beschreibung und das eigentliche Listing.

Der Seitenkopf besteht aus dem Titel und einer kurzen Beschreibung:

<div class="page-intro">
    <h1><?= $page->title(); ?></h1>
    <?= $page->intro()->kt(); ?>
</div>

Das Listing verwendet ein Snippet, welches ich in den Notizen schon im Gebrauch habe:

<ul class="note-list">
    <?php foreach ($blogroll as $blog) : ?>
        <?php $site->organism('list-entry-note', ['note' => $blog]); ?>
    <?php endforeach; ?>
</ul>

Hier sei kurz angemerkt, dass ich für Snippets zwei Site-Methods nutzen, die ich mir selbst geschrieben haben. In diesem Fall organism(). Im Grunde funktionieren sie genauso wie Kirbys snippet() Funktion. Ich nutze meine Methoden, um etwas mehr Ordnung in meine Snippets zu bekommen. Darauf komme ich bestimmt in einem anderen Beitrag noch zu sprechen.

Mein Snippet list-entry-note bekommt also ein Blog aus meiner Blogroll hereingereicht und stellt es dann dar. Es braucht drei Informationen:

1. Einen Titel
2. Eine Url
3. Ein Icon

Die Daten kommen aus dem entsprechenden Controller

Der Controller

Controller dienen in Kirby dazu, die Templates von Datenlogik zu befreien. Ich mag den Ansatz und versuche deshalb meine Templates möglichst dumm zu halten. Alles, was mit Daten zu tun hat, sollte möglichst im Controller passieren.

So sieht der Controller für die Blogroll aus:

return function ($page) {
    $blogroll = page('blog')->blogroll()->toStructure();
    $blogEntries = [];

  foreach ($blogroll as $blog) {

    $url = str_replace(['https://', 'http://', '/'], ['', '', ''], Url::stripPath($blog->url()->value()));
    $icon = $page->getSiteIcon($url);

    $blogEntries[] = new StructureObject([
        'content' => [
            'title' => $blog->title(),
            'url' => $blog->url(),
            'icon' => $icon,
            'intendedTemplate' => 'blogroll'
        ]
    ]);
    }

    $blogrollStructure = new Structure($blogEntries);

  return [
    'blogroll' => $blogrollStructure,
  ];
};

Zunächst hole ich mir das Blog, denn dort sind die Daten hinterlegt. Ich greife direkt auf das Blogroll-Feld zu und lasse es mir als Struktur zurückgeben. Dann fülle ich das $blogEntries Array mit Daten. Es bekommt jeweils den Titel, die Url und ein Icon.

Für das Icon verwende ich eine eigene Methode, die versucht, das Favicon einer Seite zu holen und ggf. einen Fallback liefert. Das Ergebnis ist ein data:image/png;base64String. Also keine Bild-URL. Das ermöglicht mir, die Favicons eine Weile zu cachen. So muss ich nicht bei jedem Seitenaufruf etliche andere Seiten anfragen (dazu in einem anderen Post mal mehr).

Schließlich erzeuge ich mir aus dem Array eine neue Struktur, denn mein Note-Entry-Snippet erwartet das so (es bekommt ja normalerweise eine Notiz rein und das ist eine Kirby-Page).

Abrunden der virtuellen Seite

Jetzt bin ich fast so weit, es fehlen noch ein paar Informationen in der virtuellen Seite, denn diese benötigt u. a. einen Titel und eine Beschreibung. Diese verstecken sich in den Übersetzungen. Ich habe mich dazu entschiede diese Daten zunächst nicht im Panel zu pflegen, weil ich sie vermutlich nicht besonders häufig anpassen werde:

'translations' => [
    'en' => [
        'code' => 'en',
        'content' => [
            'title' => 'Blogroll',
            'date' => '2024-01-30',
            'intro' => 'Blog I read regularly and can recommend.',
            ]
        ],
    'de' => [
        'code' => 'de',
        'content' => [
            'title' => 'Blogroll',
            'date' => '2024-01-30',
            'intro' => 'Blogs, die ich regelmäßig lese und die ich empfehlen kann.',
            'uuid' => Uuid::generate(),
        ]
    ]
],

Wie man sieht, stehen die nötigen Daten nun in der virtuellen Seite. Die deutsche Sprachvariante bekommt zusätzlich noch eine uuid, sie ist bei mir die Hauptsprache.

Die fertige Blogroll

Damit ist die Seite nun unter blog/blogroll abrufbar. Das Template bekommt die Daten vom Controller und rendert sie mithilfe des Snippets. Das Resultat könnt ihr hier sehen.

Neue Einträge kann ich somit weiterhin einfach im Blueprint vom Blog vornehmen und die virtuelle Seite kümmert sich um den Rest, ohne, dass ich im Panel noch extra eine Seite dafür anlegen muss.

Danke, dass Du meinen RSS-Feed abonniert hast!

Vor 40 Jahren wurde der erste Apple Mac veröffentlicht. Damit ist er jünger als ich, was ich zunächst anprangern muss. Spätestens beim Durchsehen alter Bilder, auf der Suche nach benutzten Computern, muss ich dann aber wohl eingestehen, dass das alles schon verdammt lange her ist.

Apple-Rechner benutze ich produktiv seit etwa 2006. Vorher war ich lange mit Linux unterwegs, hatte ja sogar dieses Linux-Blog und war bei RadioTux dabei. Dass ich bei Linux fast alles so konfigurieren konnte, wie ich wollte, fand ich toll. Das Terminal war ein stetiger Begleiter.

Irgendwann fing ich aber immer mehr an so ein bisschen neidisch auf die hübsche Oberfläche von Apple zu schauen. Ich versuchte das in GNOME nachzubauen, das ging zumindest so ein bisschen.

Irgendwann verdiente ich dann genug Geld, um mir einen aktuellen Mac leisten zu können, das erste weiße Intel Macbook wurde es. Endlich eine tolle Benutzeroberfläche und trotzdem das Terminal und ein UNIX zur Hand. Das war die perfekte Mischung. Außerdem musste ich dann auch nicht immer irgendwo ein Windows laufen haben, wenn ich mal mit einer etwas umfangreicheren DAW arbeiten wollte.

Seither bin ich beim Mac geblieben, zumindest als Desktop-Rechner. Linux läuft hier immer noch auf Servern oder dem OrangePi.

Meinen allerersten Mac kaufte ich übrigens gebraucht bei einer Redaktionsauflösung. Da lieft noch Mac OS 9 drauf und er war zum Kaufzeitpunkt eigentlich schon veraltet. So wirklich genutzt hatte ich ihn dann auch nicht, aber hey! Ich hatte einen Mac.

Weiter ging es dann mit besagtem Intel Macbook, einem iMac und seitdem immer mal wieder einen neuen Mac Mini, die für mich das beste Preis-Leistungsverhältnis haben.

Auf alte Bilder schauend, muss ich sagen, dass mein Setup zwar größer und moderner geworden ist, aber grundlegend immer gleich blieb. Ein Mac, Monitor, Mikrofon und irgendwo steht noch ein Midi-Keyboard rum. Manche Dinge ändern sich wohl nie…

Danke, dass Du meinen RSS-Feed abonniert hast!