Anlässlich der groooßen An- bzw. Verkündigung des revolutionären, einzigartigen, neuen und höchst offfffizielllllen "Share to Mastodon Buttons" bin ich über eine echt tolle Möglichkeit gestolpert, einen "Share to FEDIVERSE Button" auf den eigenen Seiten einzubauen...

Anlässlich der groooßen An- bzw. Verkündigung des revolutionären, einzigartigen, neuen und höchst offfffizielllllen "Share to Mastodon Buttons" bin ich über eine echt tolle Möglichkeit gestolpert, einen "Share to FEDIVERSE Button" auf den eigenen Seiten einzubauen. Ich bin im ersten Teil "Teile im Fediverse?" nur auf share2fedi eingegangen und hatte nicht nach Alternativen geschaut.

Share2fedi hat ja einen "Nachteil" (was man so "Nachteil" nennen mag)... man greift auf eine fremde Ressource zu. Der Code gibt zwar keinerlei Hinweise auf irgendeine Datenverarbeitung durch den Betreiber her, und man kann den Dienst ja auch selbst hosten (der Code steht als Open Source auf github unter der AGPL3-Lizenz zur Verfügung). Selbst hosten... also einen Dienste-Service auf dem Server installieren... schon was umständlich und mit der Notwendigkeit, einen Reverse Proxy zu nutzen.

Aber es gibt da eine echte Alternative, die wesentlich leichtgewichtiger daherkommt: Fediverse Sharing Button von Stefan Bohacek

Um diesen "Button" einzubauen, braucht man nur ein Snippet in die eigene Seite einfügen... und schon ist er betriebsbereit.

Im Repo zu diesem Button liegt das Snippet zum Kopieren vor. In diesem Fall wird zwar auch auf externe Ressourcen zugegriffen, der Klick auf den Button nimmt aber keinen Umweg über einen fremden Dienst, wie es bei share2fedi der Fall ist. Die eine externe Ressource sind Grafiken mit den Logos verschiedener Fediverse-Dienste (mit denen der Button funktioniert). Bei dem Button ist es nämlich so, dass nach dem Eingeben der URL des genutzten Fediverse-Dienstes das Logo der Fediverse-Software automatisch auf dem Button angezeigt wird. Und es wird auf den fediverse-info Server zugegriffen, die node-info Daten zu den Servern zu bekommen, ohne die eigentlichen Instanzen mit Anfragen zu belasten. Es wird also nirgendwo etwas gespeichert und es fließen auch keine Daten zu dubiosen Diensten ab.

Also... gespeichert wird schon etwas (kann man aber abstellen): die eingegebene URL der Instanz und die Bezeichnung der darauf laufenden Fediverse-Software.

Das allerdings wird nicht irgendwo gespeichert, sondern beim Nutzer selbst lokal im localStorage-Speicher. Und man kann es auch verhindern, wenn man unbedingt jedes Mal wieder neu die Domain des Fediverse-Dienstes eingeben möchte.

Das Snippet, das auf der Webseite des Projekts zur Verfügung steht, nutzt die Ressourcen (die Icon-Dateien, eine Javascript-Bibliothek und eine CSS-Datei), die der Entwickler auf seinem eigenen Server zur Verfügung stellt. Man kann diese Dateien aber auch auf dem eigenen Server ablegen und von dort aus verwenden.

Dafür lädt man das Verzeichnis fediverse-share-button/icons samt enthaltener Grafiken, sowie die Dateien script.min.js und styles.min.css in ein Verzeichnis auf dem eigenen Server (das Verzeichnis muss öffentlich zugreifbar sein, damit der Button auch bei jedem funktioniert) und ändert die Referenzen im Snippet auf die eigene URL.

Der Button funktioniert aktuell mit Diaspora, Firefish, Friendica, Glitch-soc, Hometown, Hubzilla, Lemmy (aktuelle Versionen), Mastodon, Misskey und Sharkey. Also mit etlichen Diensten des Fediverse... ist ja auch ein Fediverse-Share-Knopf und kein Du-sollst-keine-anderen-Götter-haben-neben-Mastodon-Button. Der funktioniert dann auch bei Besuchern unserer Webseite, die keinen Mastodon-Account haben, aber sehr wohl einen bei den anderen unterstützten Diensten.

Ich persönlich würde IMMER diesen Button empfehlen, anstatt eine sehr große Zahl Fediversenutzer durch einen einseitigen Button auszugrenzen.

Heute trinke ich mir zur Feier des Tages mal einen Pálinka (was selten vorkommt)...

Auf den Tag genau zehn Jahre ist es nun her (28. Februar 2016), dass ich meine ersten Schritte mit Hubzilla gemacht habe...

Heute trinke ich mir zur Feier des Tages mal einen Pálinka (was selten vorkommt)...

Auf den Tag genau zehn Jahre ist es nun her (28. Februar 2016), dass ich meine ersten Schritte mit Hubzilla gemacht habe. Fragt mich bitte nicht nach der genauen Version... muss irgendwas um die 1 herum gewesen sein. Damals war das Hubzilla-Universum nur das Grid, denn ActivityPub war noch nicht implementiert. Ich hatte mir dann einen Hub ausgesucht und wollte mich registrieren, aber das hat nicht wirklich geklappt, weshalb ich einen eigenen Hub auf Uberspace installierte, was aufgrund einer im Netz vorhandenen Anleitung sehr einfach war. So war ich von Anfang an also auch Hubzilla-Admin.

Am 13. März 2016 veröffentlichte ich dann auch einen ersten Artikel zu Hubzilla: Schon wieder was neues? Hubzilla.

Denn ich war begeistert von den Möglichkeiten dieses Netzwerks und der Software. Und ich bin seit dem auch nie wieder wirklich von Hubzilla weggekommen. Zwar habe ich etliche Dienste als "Gast" auf fremden Instanzen, aber sehr oft auch auf selbst gehosteten Instanzen ausprobiert, aber es hat mich immer wieder zu Hubzilla zurückgezogen... und ich hatte auch immer(!) einen eigenen Hub am Laufen.

Anfangs hatte ich viele Kontakte zu Diaspora-Nutzern (weil Hubzilla die Verbindung durch ein Addon erlaubte) und zu etlichen Hubzilla-Kanälen. Die große Welt des Fediverse erschloss sich dann im Sommer 2017, als Hubzilla –zusätzlich zum Protokoll Zot – auch noch ActivityPub implementierte, was es möglich machte, sich mit den (damals noch wenigen) Diensten zu verbinden, die auch schon ActivityPub verwendeten (Pleroma war das wohl und an Herbst 2017 kam dann Mastodon hinzu, auf welches viele GNU Social Nutzer umgestiegen waren). Von da an ging die Post ab.

Aktuell habe ich mit meinem Hauptkanal Der Pepe (Hubzilla) ⁂ 114 Zot6/Nomad-Verbindungen, zwei RSS-Verbindungen und 212 ActivityPub-Verbindungen. Diaspora-Kontakte habe ich keine mehr.

Über die Jahre habe ich mir einiges an Wissen zu Hubzilla angeeignet und versuche, dieses Wissen auch weiterzugeben und auch für Einsteiger möglichst verständlich aufzubereiten.

Im Sommer 2024 habe ich dann begonnen, die hubzilla-interne Hilfe, also die eingebaute Dokumentation grundlegend zu überarbeiten (sie war wirklich sehr veraltet) und neu aufzubauen. Nebenbei pflege ich auch noch meine Hubzilla KnowledgeDB, die Informationen noch einmal anders aufbereitet und auch Themen behandelt, die im Manual nicht oder nur in beschränktem Umfang vorkommen. Und für die Nutzung von Hubzilla als Content Management System habe ich auch eine Online-Dokumentation begonnen, die hoffentlich helfen kann, auch andere Dinge, als nur Social Media mit Hubzilla zu machen.

Und obwohl ich nun schon so lange "mit Hubzilla rummache", entdecke ich trotzdem immer wieder Möglichkeiten und Funktionen, die ich bislang nicht kannte. Das geht übrigens nicht nur mir so, sondern sogar die Entwickler stolpern ab und an über Dinge, die ihnen vorher unbekannt waren. Gerade kürzlich entdeckte Harald Eilertsen (einer der Entwickler) einen "Experten-Modus" für die Warteschlangenverwaltung (was natürlich sofort in der KnowledgeDB landete und auch ins Manual kommt), was Jupiter Rowland zu einem Kommentar veranlasste, der jetzt auf meiner Kanalseite prangt:

Hubzilla is when even the main devs keep discovering hidden features they knew nothing about.
Quelle: Jupiter Rowland auf Hubzilla

Ende 2024 wurde ich dann Mitlied der Hubzilla Association, der Organisation, welche die Entwicklung, Förderung und Verbreitung von Hubzilla unterstützt und bei der Pflege der Dokumentation und der Website hilft. Sie betreibt auch die Projekt-Webseite hubzilla.org und verschiedene Support-Kanäle, wie z.B. das "berühmte" (und absolut empfehlenswerte) Hubzilla Support Forum.



Auch wenn Hubzilla heute immer noch "unter dem Radar" fliegt, ist es das System meiner Wahl. Ich schätze es wegen der kontinuierlichen und unaufgeregten Weiterentwicklung. Gerade hat z.B. ein echtes Hammer-Feature Einzug gehalten: die Integration von Collabora über das neue WOPI-Addon. Damit ist die Bearbeitung von Cloud-Inhalten extrem komfortabel geworden und eine Zusammenarbeit wesentlich einfacher, als über den Umweg z.B. über die Wiki-Funktion. Fehler werden schnell ausgemerzt und der Support ist in der wundervollen Gemeinschaft rund um Hubzilla einfach hervorragend.

Im Rückblick waren es zehn aufregende Jahre, Jahre die Spaß gemacht haben und Jahre, die Lust auf weitere zehn Jahre mit Hubzilla machen.

Und falls jetzt jemand neugierig geworden ist: Probiert es einfach einmal aus... Join Hubzilla

Oktober vergangenen Jahres habe ich begonnen, ein kleines "Buch" über die Nutzung von Hubzilla als CMS zu schreiben. Inzwischen ist es vorerst fertig. Wobei "fertig" nicht stimmt, denn es wird nach und nach weitergeführt und um weitere Kapitel und Themen erweitert. Aber es ist nun auf einem Stand, der für Nutzer hilfreich sein sollte...

Oktober vergangenen Jahres habe ich begonnen, ein kleines "Buch" über die Nutzung von Hubzilla als CMS zu schreiben. Inzwischen ist es vorerst fertig. Wobei "fertig" nicht stimmt, denn es wird nach und nach weitergeführt und um weitere Kapitel und Themen erweitert. Aber es ist nun auf einem Stand, der für Nutzer hilfreich sein sollte.

Es ist grundsätzlich erst einmal ein "Online-Buch" und unter der URL https://cms.hubzilla.hu/ zu finden. Allerdings habe ich auch eine PDF-Version erstellt, die zum Download zur Verfügung steht. Dieser PDF-Version wird immer, wenn einiges dazugekommen ist, ebenfalls aktualisiert.

Schaut es Euch einfach einmal an...

Hier das derzeitige Inhaltsverzeichnis:



Demnächst wird es auf jeden Fall ergänzt, denn mit der Veröffentlichung von Hubzilla 11.0 hat ein echter Gamechanger Einzug gehalten. Es gibt nun das Addon "WOPI", welches es ermöglicht, die Cloud von Hubzilla mit Collabora Office zu nutzen. Streng genommen ist Cloud-Funktionalität zwar nicht zwingender Bestandteil eines CMS, sie wird aber immer öfter bei solchen Systemen angeboten und die diesbezügliche Erwartungshaltung nimmt zu, weshalb die Cloud im Buch ebenfalls entsprechend gewürdigt wird. Insbesondere, weil sie auch für das Bereitstellen statischer Webseiten genutzt werden kann.

Zum Thema Cloud kommt, zusätzlich zur Collabora-Nutzung, auch noch ein wenig mehr. Ich werde beschreiben, wie man eine automatische Synchronisation des Cloud-Verzeichnisses mittels "Rclone" oder mit einem Python-Programm realisieren kann, so dass es sich anfühlt wie Nextcloud mit dem Synchronisierungs-Tool.

Über Anregungen und Themenwünsche freue ich mich natürlich auch. So kann das Buch weiter wachsen.

Code-Schnipsel, Tools, Stylesheets, Blöcke und Webseiten-Vorlagen zum Buch können aus meinem Repository https://codeberg.org/derpepe/hubzilla_website_building heruntergeladen werden.

Sharing für  Fediverse-Dienste, also ein "Share im Fediverse Button" ist kein ganz triviales Ding.

Das Problem besteht darin, dass das Fediverse dezentral ist...

Sharing für  Fediverse-Dienste, also ein "Share im Fediverse Button" ist kein ganz triviales Ding.

Das Problem besteht darin, dass das Fediverse dezentral ist. Ein "Teile bei X", "Teile bei Facebook", etc. Button hat es leicht. Alle diese zentralisierten Dienste laufen auf einem Server bzw. sind unter einer einzigen URL erreichbar. Für "X" muss "x.com" aufgerufen werden, für "Facebook" entsprechend "www.facebook.com" etc. Damit ist man an der richtigen (wenn man es denn so empfindet) Stelle.

Es gibt aber nicht "die eine URL" für das Fediverse. Jeder, der z.B. auf eine Webseite mit einem Inhalt stößt, den er gerne im Fediverse teilen möchte, kann und wird auf einer anderen Instanz sein... und dann auch noch in der Regel bei einem anderen Fediverse-Dienst. Und jede Instanz hat eine andere URL. Der Betreiber der Webseite weiß aber nicht, welchen Dienst der Besucher verwendet. Und womöglich verwendet dieser ja sogar mehrere verschiedene Fediverse-Dienste, die natürlich unter unterschiedlichen URLs erreichbar sind. Mit welcher er den Inhalt nun teilen möchte, kann der Website-Betreiber natürlich auch nicht wissen. Dilemma!

Das ist der Grund, weshalb man fast nirgendwo einen "Teile im Fediverse Button" findet. Und es ist auch ungerecht, den Betreiber dafür zu schimpfen.

Es gibt aber eine recht gut einsetzbare Lösung dafür. Sie ist weit entfernt davon, perfekt zu sein und unterstützt derzeit auch bei weitem nicht alle Fediverse-Dienste. Aktuell werden Mastodon (inklusive Hometown, Fedibird, GlitchCafé), Misskey (inkusive Calckey/Firefish, FoundKey und Meisskey, nicht jedoch Sharkey, Iceshrimp und Iceshrimp.NET), Friendica, Hubzilla und GNU Social unterstützt. Gotosocial, Mitra, Pleroma/akkoma und die meisten anderen Dienste sind derzeit leider (noch) nicht unterstützt.

Aber immerhin, das ist schon eine ganz gute Auswahl fürs Erste.

Die Lösung heißt "Share2Fediverse" und ist unter "s2f.kytta.dev" verfügbar. Ein Button, der ein "Teile im Fediverse" mit diesem Dienst anbietet, nimmt einen kleinen Umweg diese Seite und der Besucher muss dort die URL (Webadresse) der Fediverse-Instanz angeben, bei der man über einen Account verfügt. Dieser Zwischenschritt muss sein, weil Fediverse-Dienste auf unzählige Server mit unterschiedlichen Webadressen aufgeteilt ist.



Um es nun ganz einfach zu machen... auch und gerade für Webseiten-Besitzer ohne große technische Kenntnisse, habe ich einfach einen kurzen „Schnipsel“ HTML geschrieben, den man einfach unter seinen Beitrag/Artikel etc. packen muss. Er zeigt einen Fediverse-Button an und führt zu besagter Seite, wobei Titel und Link des Beitrags übernommen werden. Hier gibt nun der Leser die Adresse seines Fediverse-Dienstes ein und kann den Beitrag teilen:

<p><a href="https://s2f.kytta.dev/" onclick= "location.href=this.href+'?text='+document.title+' '+window.location; return false;"><img src="https://pepecyb.hu/files/share_fediverse.png" alt="Teile im Fediverse" title="Teile im Fediverse"/></a></p>

Das funktioniert z.B auch prima mit WordPress. Dafür erstellt man einfach einen HTML-Block mit diesem Code und speichert ihn als Vorlage. So kann man ihn mit zwei Klicks unter jeden Artikel packen.

Natürlich besteht rein technisch die Möglichkeit, dass "s2f.kytta.dev" gewisse Daten des Nutzers abgreift. Stimmt! Aber es ist eher unwahrscheinlich. Zumal der Quelltext des Dienstes in einem Git-Repository einsehbar ist: https://github.com/kytta/share2fedi.

Als weitere Alternative könnte man in Erwägung ziehen, Share₂Fedi einfach auch selbst zu hosten. Das sollte sogar kostenneutral möglich sein, wenn man es mit Vercel macht... aber möchte man, dass die eigenen Leser über einen Server in den USA geleitet werden? Also ich nicht! Man kann Share₂Fedi aber auch auf einem eigenen Server (mindestens VPS) installieren... doch das ist dann auch wieder etwas für Spezialisten.

Es gibt auf jeden Fall eine Möglichkeit, einen "Teile im Fediverse Button" einzusetzen, auch wenn er mit einigen wenigen Einschränkungen behaftet ist.

Mein Schnipsel ist zumindest einfach... mehr soll er auch nicht sein.

Ich habe ihn selbst verwendet, als ich meine Blogs noch mit WordPress betrieben habe.

Auf die Grafik des Buttons ist man übrigens nicht festgenagelt. Da kann man auch die URL zur Grafik eines anderen Buttons einsetzen.

...was die ganze Sache nun soll?

Seit ein, zwei Tagen tauchten mehr und mehr Postings in meinem Stream auf, in welchen es um das "Forkiverse" ging.

...was die ganze Sache nun soll?

Seit ein, zwei Tagen tauchten mehr und mehr Postings in meinem Stream auf, in welchen es um das "Forkiverse" ging.

Forki... Was?

Also das Fediverse kenne ich ja... und dann kenne ich noch die Forkeys, also Fediverse-Software, die als Forks oder Forks von Forks oder... na ja... Forks halt von Misskey entstanden sind (also Sharkey, Calckey - Firefish, Iceshrimp und wie sie alle heißen)... aber was ist denn das "Forkiverse" und weshalb wird darüber so viel geschrieben?

So rein vom Namen klingt es so, als würde da jemand das Fediverse "forken" wollen, also ein neues, abgeleitetes, aber dennoch anderes Fediverse schaffen.

Aber ist dem wirklich so? Und braucht es sowas? Und möchte irgendwer sowas? Und überhaupt...

Wirklich fundierte Informationen darüber, was das "Forkiverse" nun ist, findet man nicht wirklich.

Es gibt eine Mastodon-Instanz (also schonmal nix mit "Fork") mit dem Namen "Forkiverse" unter der Domain theforkiverse.com. Und da steht dann auch ein Satz:

Building a better internet with your friends from Hard Fork and Search Engine.

Also...

Gemeinsam mit Ihren Freunden von Hard Fork und Search Engine ein besseres Internet schaffen.

Wer oder was sind jetzt "Hard Fork" und "Search Engine"? Und wer sind diese Freunde, die meine Freunde sein sollen und mit mir ein "besseres Internet" aufbauen möchten?

Mehr Infos findet man unter der Domain zunächst nicht. Außer, dass es (stand 12. Januar 2026) um die 3.200 Accounts auf der Instanz gibt und die Instanz von einem gewissen Kevin Roose betrieben, adminstriert, moderiert wird.

Wer ist das denn nun schon wieder? Ein amerikanischer Journalist ist es. Kein Wunder, dass mir der Name nicht geläufig ist. Und er arbeitet irgendwie auch für die New York Times. Da zeichnet er auch für den Podcast "Rabbit Hole" verantwortlich und er ist außerdem Co-Moderator eines weiteren NYT-Podcasts mit dem Namen "Hard Fork".

Aaahhh... jetzt... "Hard Fork" ist also ein NYT-Podcast, der von Kevin Roose und einem gewissen Casey Newton moderiert wird... und in welchem es um die "Radikalisierung des Internets" geht.

Der Name Casey Newton taucht im Zusammenhang mit "Forkiverse" auch immer mal auf. Und wer ist das nun? Na auch ein amerikanischer Journalist.

Gräbt man dann in den Infos zu diesen Protagonisten und den Podcasts stößt man irgendwann auch auf "Search Engine", was ein Podcast von CBC bzw. TVOntario ist, ursprünglich moderiert von einem Jesse Brown, jetzt wohl von einem gewissen PJ Vogt, dessen Name auch im Zusammenhang mit dem "Forkiverse" immer wieder fällt.

Na ok... das mit "meinen Freunden von Hard Fork und Search Engine" war wohl nix. Hab da keine Pfroinde. Egal...

Und die wollen jetzt ein "besseres Internet" aufbauen. Stellt sich also die Frage, was denn ein "besseres" Internet auszeichnen soll.

Liest man die wenigen (habe nur zwei mit "etwas Fleesch uffe Rippen" gefunden) Artikel zum "Forkiverse", bekommt man eine grobe Vorstellung, was es damit auf sich haben soll. [1] [2]

Also... das "Forkiverse" ist ein Kind dreier Podcaster: Kevin Roose, Casey Newton und PJ Vogt. Sie wollen ein "besseres" Internet schaffen, wobei "besser" von ihnen nicht wirklich definiert wird. "Besser" halt! Und wer würde das nicht wollen, denn schließlich soll ja "die derzeitige Version des Internets" laut ihrer Ansicht die "wohl die schlechteste, die es je gab" sein.

Also... na ja, so richtig ein neues Internet trauen sie sich dann doch eher nicht zu. Ihre Vision ist ein "besseres Soziales Netzwerk". Das wollen sie aber mal machen. Und dafür nutzen sie Mastodon. Ist ja prima! Aber damit schaffen sie ja nichts Neues, denn Mastodon gibt es nun schon seit dem 16. März 2016 und das Fediverse, dessen Teil es ist, bereits seit dem 18. Mai 2008. Was sie geschaffen haben, ist eine weitere Mastodon-Instanz zu den bis dahin (Zahlen laut FediDB) 9.181 anderen Mastodon-Instanzen bzw. eine weitere Fediverse-Instanz zusätzlich zu den bis dahin 42.906 Fediverse-Instanzen.

Nun ist aber auch ihre Instanz Teil des Fediverse (und deshalb spülte es mit Postings von dieser Instanz in meinen Stream) und damit war es das dann auch schon mit dem vermeintlich "besseren" Sozialen Netzwerk nach ihren Vorstellungen. Denn sie haben ja keinen Einfluss darauf, was im gesamten Fediverse so alles passiert.

Hätte sie einen wirklichen "Reinraum" erschaffen wollen, hätten sie ihre Instanz entweder deföderieren müssen oder womöglich gleich eine andere Social-Network-Anwendung (sowas wie Oxwall, HumHub, Elgg etc.) oder eine Foren-Software nutzen können. Solange aber ihre Forkiverse-Instanz im Fediverse drinhängt, sind sie Teil dieses großen Netzwerks und nur beschränkt in der "Reinhaltung".

Der Artikel von Maho Pacheco offenbart auch, dass weder er, noch die drei Forkiversisten das Fediverse an sich verstanden haben. Man benötigt nämlich für eine Art Community, wie sie sich eine vorstellen, keine eigene Instanz. Und es ist auch nicht im Sinne der Dezentralisierung, nun möglichst viele Gleichgesinnte auf eine einzige Instanz zu locken (mit einem irgendwie gearteten Heilversprechen à la "besseres Internet").

Und, auch wenn ich viele hier vielleicht enttäuschen mag: Es ist und bleibt völlig egal, welche Instanz Ihr für Euren Account auswählt. Zumindest themenbezogen oder in Bezug auf die Region. Die Instanz-Regeln können einen Ausschlag für die Auswahl geben oder die Zuverlässigkeit (Verfügbarkeit). Aber eine "Angler-Instanz" ist auch für Nicht-Angler genauso gut zu nutzen, wie eine andere Instanz und sie bringt auch Angelbegeisterten keine wirklichen Vorteile. Lediglich die lokale öffentliche Timeline enthält dann wahrscheinlich mehr Angler. Aber wolltet Ihr nicht Algorithmen loswerden? Wolltet Ihr nicht, dass Euch nichts ungefragt in die Timeline gespült wird. Ist der lokale Stream wirklich so wichtig?

Das Fediverse macht ein klein wenig Mühe. Damit Angler als Angler gefunden werden, müssen sie diese Info halt in ihrem Profil unterbringen. Oder man sucht, auch wenn man einen Account bei einer anderen Instanz hat, einfach mal eine Angler-instanz auf und schaut sich deren lokale Zeitleiste an, um auf Angelfreunde zu stoßen. Himmel! Wenn Ihr war vorgekaut haben wollt, müsst Ihr halt bei den Walled Gardens bleiben und Euch von einem undurchsichtigen Algorithmus vor den Latz knallen lassen, was dieser meint, dass es Euch interessiert.

Und der Titel ihres Projekts ist jetzt auch nicht unbedingt sehr geschickt gewählt. "Forkiverse" klingt nämlich erstmal so, als gibge es wirklich um eine Abspaltung von Fediverse... was es aber ja eben wieder nicht ist, weil ins Fediverse eingebunden. Der Name weckt Erwartungen, die das Projekt nicht erfüllen kann. Ob das jetzt ein Versehen aus Unwissenheit war oder ob es eher eine Art Marketing-Gag sein sollte... keine Ahnung. Sympathien kann man so nicht sameln. Und eine möglichst große Instanz anzustreben widerspricht sowohl dem dezentralen Gendanken des Fediverse und macht alle Bemühungen, die Nutzer auf möglichst viele Instanzen zu verteilen, zunichte.

Für mich sieht die ganze Sache wie eine mächtige Schaumschlägerei aus... nicht mehr und nicht weniger. Und wenn der Hashtag in absehbarer Zeit nicht mehr so wild durch die Gegend geworfen wird, dann lösche ich ihn auch wieder aus meinem Filter.

---

[1] The Forkiverse Experiment and Why Instance Choice Matters (arch)
[2] The Fediverse Experiment (arch)

Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss...

Bei allen Überlegungen, wie ich es denn letztlich realisieren möchte, läuft es in fast allen Fällen darauf hinaus, dass ich die Inhalte des WordPress Blogs exportieren muss. Auf welche Weise ich diese dann verarbeite, hängt vom gewählten Weg ab.

Die Export-Funktion von WordPress ist ganz einfach zu benutzen. Man findet sie in der Seitenleiste unter dem Menüpunkt "Werkzeuge".



Man kann dort alle möglichen Inhalte exportieren, ja sogar alle auf ein Mal. Nun, alle brauche ich nicht. Ich brauche tatsächlich nur die Beiträge (inklusive der Kommentare). Und weil in der DDP so viele Beiträge existieren und die Sicherungsdatei extrem groß werden würde, habe ich mich entschieden, je einen Export für jeweils ein Jahr zu erzeugen.





Und dann habe ich eine Export-Datei (die Sicherungsdateien werden von WordPress als WXR-Dateien – für WordPress eXtended RSS - bezeichnet) im XML-Format.



Diese Dateien sind für Publii und dessen Import-Funktion direkt nutzbar. Allerdings werden nur die Artikel selbst importiert. Die Kommentare bleiben unberücksichtigt.

Ansonsten sind die WXR-Dateien aber nicht wirklich für die direkte Nutzung geeignet. Um sie z.B. für die Artikel-App von Hubzilla zu verwenden, muss man die eigentlichen Artikel extrahieren und ins BBcode-Format umwandeln. Und die Kommentare müssen auch (am besten separat) extrahiert werden.

Per Hand ein riesiger Aufwand. Dafür müssen Helfer-Skripte her... aber dazu später mehr (sind schon in Arbeit).

Lediglich für die Variante mit einem externen statischen Archiv werden die Exportdateien nicht benötigt (schadet aber auch nicht, welche als Backup zu haben). Ich würde dafür Simply Static nutzen, mit dem ich schon gute Erfahrungen gemacht habe.

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten...

Ich bin mir inzwischen sicher, bzw. ich bin fest entschlossen, mein Blog "Die Dampfdruck-Presse" (aktuell noch mit WordPress) in Zukunft nur noch mit Hubzilla als CMS anzubieten.

Die Gründe dafür sind die irrsinnigen KI-Ideen der WordPress-Entwickler und auch ein Stück weit Glaubwürdigkeit (immerhin predige ich ja schon lange, dass Hubzilla auch als vollwertiges CMS gut nutzbar ist).

Die Basis existiert ja auch schon eine ganze Weile: Dampfdruck-Presse bei Hubzilla. Ich pflege dieses Parallel-Blog seit dem Start mit den neuen Artikeln, die ich in der WordPress-Version veröffentliche. Und ein paar ältere Artikel habe ich auch schon konvertiert... zu Fuß.

Und genau da liegen die Probleme! Das wirklich per Hand einzeln zu machen, ist ein enormer Aufwand. Immerhin gibt es ja (aktueller Stand) 1.075 Artikel. Wenn ich die alle einzeln konvertieren möchte und vielleicht am Tag durchschnittlich drei bis vier Artikel hinbekäme, dann wäre ich locker bis zu einem Jahr damit beschäftigt.

Schöne Scheiße!

Nun gibt es mehrere Möglichkeiten.

Die einfachste wäre, das WordPress Blog als Archiv bestehen zu lassen und künftig nur noch im Hubzilla-Blog zu veröffentlichen. Allerdings müsste ich dann die Updates dafür abschalten oder es in ein statisches Blog umwandeln (das funktioniert ganz manierlich).

Der Vorteil: Die Kommentare blieben sauber bestehen. Es würde nichts verloren gehen.

Der Nachteil: Die DDP wäre in zwei Teile aufgeteilt, also quasi zerrissen.

Hier überwiegt der Nachteil! Ich könnte die statische Version (denn so würde ich es machen, um WordPress auch wirklich loszuwerden) unter dampfdruck-presse.de laufen lassen und das aktuelle Blog (also das mit Hubzilla) unter dampfdruck-presse.hu laufen lassen. Es gefällt mir so aber nicht!

Eine weitere Möglichkeit wäre, das WordPress Blog per Import als Publii-Blog zu konvertieren. Das funktioniert auch sehr gut. Dieses statische Blog könnte ich dann auch mit Hubzilla anbieten. Das wäre dann das "Archiv". Das aktuelle Blog würde mit Hubzilla und der App "Artikel" fortgeführt. Es gäbe dann halt einen Link zum Archiv, der zum Publii-Archiv in der Hubzilla-Cloud führen würde.

Der Vorteil: Alles wäre an einem Ort und unter einer Domain zu erreichen.

Der Nachteil: Die Kommentare müsste ich per Hand einpflegen, denn die werden von der Import-Funktion nicht erfasst.

Und schließlich könnte ich tatsächlich das ganze Blog komplett als Hubzilla-Artikel konvertieren.

Der Vorteil: Alles wäre aus einem Guss.

Der Nachteil: Wie schon erwähnt, wäre das eine Mords-Arbeit bei so vielen Artikeln. Da müsste ich mir Helfer-Skripte basteln.

Nun, ich werde jetzt nach und nach an allen Varianten herumtüfteln, schauen, was sich automatisieren und vereinfachen lässt und es sicher irgendwann irgendwie schaffe, die DDP komplett zu Hubzilla umzuziehen.

Und ich nehme Euch gerne mit auf diese Reise, indem ich die einzelnen Schritte und Experimente hier dokumentiere und erläutere. Es kommen also jetzt nach und nach etliche weitere Artikel zu dem Thema "Von WordPress zu Hubzilla".

Heute bin ich über einen Artikel bei wordpress.org (genauer bei Make WordPress Core … das WordPress Developer Blog) gestolpert [...]

Heute bin ich über einen Artikel bei wordpress.org (genauer bei Make WordPress Core … das WordPress Developer Blog) gestolpert:

AI as a WordPress Fundamental (arch)

Ist das deren Ernst? WordPress soll also in absehbarer Zeit komplett KI-durchseucht werden?

Ok… aber ohne mich!

Ich habe zu dem, was alle Welt „KI“ nennt, eine ausgesprochen ambivalente Einstellung. Generell finde ich das eine wahnsinnig spannende Entwicklung, die man auch – das eigene Hirn eingeschaltet gelassen – durchaus nutzbringend einsetzen kann. Die immer mehr um sich greifende Faulheit aber, führt dazu, dass irgendwie die Tendenz besteht, sich das Denken nahezu völlig abnehmen zu lassen. Und überall bekommt man diese „KI“ inzwischen aufgedrückt. Immer mehr nehmen das auch an und verlassen sich auf Algorithmen, die eine Intelligenz vortäuschen und gerne auch mal enttäuschen. Das gehe ich nicht mit!

Ich selbst nutze das, was „KI“ genannt wird, auch. Aber als bewusste Entscheidung und als Unterstützung meiner eigentlichen Arbeit (nicht, um mir die Arbeit abnehmen zu lassen). Wenn ich Artikel (insbesondere in der Dampfdruck-Presse) schreibe, zu denen ich recherchieren muss, dann frage ich anfangs auch häufig ein LLM. Einfach, um Anhaltspunkte zu bekommen. Manches LLM nennt mir sogar weiterführende Links, wenn ich gezielt danach frage. Das ist schon eine nette Ausgangsposition. Solche Links verfolge ich dann auch und lese mir das, was hinter den Links steckt, aber selbst durch. Und trotz dieser recht neuen Einstiegs-Routine gehe ich dann letztlich doch wieder so vor, wie ich es schon immer gemacht habe. Ich bemühe echte Suchmaschinen, die ich mit möglichst geeigneten Suchbegriffen meist dazu bewegen kann, mir wirklich passende Ergebnisse (als Links… auf Zusammenfassungen kann ich echt verzichten) aufzuzählen. Und die verfolge ich dann. Ich nutze mein Hirn, denn der Artikel, den ich später aus den Informationen füttere, trägt ja auch meinen Namen (als Verfasser).

Bei Artikelbildern bin ich da sogar etwas freizügiger. Ich benutze, weil ich persönlich der Meinung bin, in meinem Blog sollten Artikel immer ein Titelbild haben (sieht in der Übersicht allein schon einfach stimmiger aus… mein Blog, mein persönlicher Geschmack), in letzter Zeit öfter einmal KI-Bildgeneratoren. Die meisten Artikelbilder haben aber sowieso rein „dekorativen“ Zweck. Sie sollen einen Bezug zum Inhalt des Artikels haben, sie sind aber nicht erforderlicher Teil des Artikels. Jeder Artikel „funktioniert“ auch ohne das Bild.

Es ist bei mir so, dass ich meist schon eine konkrete Idee habe, wie das Titelbild aussehen soll. In Ermangelung der künstlerischen Fähigkeiten habe ich früher lange nach freien Bildern und Grafiken gesucht und diese sehr oft auch mit meinen (besseren) Fähigkeiten mit Gimp nachbearbeitet oder kombiniert. Ich schaue auch heute noch, ob ich etwas finde oder ich versuche, mich selbst doch irgendwie künstlerisch zu betätigen und selbst etwas zu zaubern. Aber wenn ich nichts finde, weil die Idee in meinem Kopf zu speziell ist, dann lasse ich die KI ran und schaue, ob mich das Ergebnis überzeugt. Allerdings gebe ich mir bei der Erstellung des Prompts auch wirklich Mühe und versuche das gewünschte Ergebnis möglichst detailliert zu beschreiben. Bekomme ich dann womöglich das, was ich mir vorgestellt habe, bearbeite ich es aber nicht selten selbst noch nach.

Ich setze also KI in Maßen ein, um mir einige Arbeiten zu erleichtern oder um vielleicht noch besseres Futter für meine Artikel zu bekommen. Das mache ich aber 1. außerhalb von WordPress (im Fall der Dampfdruck-Presse) und 2. nur wenn ich es für angebracht oder erforderlich halte.

Ohnehin arbeite ich die meiste Zeit für meine Artikel außerhalb von WordPress. Ich schreibe inzwischen so ziemlich alles in Markdown… also nicht nur Artikel, sondern wirklich das Meiste, was ich so schreibe. Dafür nutze ich Typora (für das ich schon vor etlichen Jahren eine Lizenz erworben habe, die sich inzwischen mehr als gelohnt hat). Und so verfasse ich meine Artikel (so wie diesen hier) mit Typora in Markdown.



Bildbearbeitung inklusive Skalierung: Gimp!



Zeichnungen: Inkscape oder LibreOffice Draw.




Und dann lese ich oben stehenden Artikel und muss da Passagen ertragen, wie etwas diese:

Stellen Sie sich vor, jeder einzelne Entwickler würde mit KI-Fähigkeiten ausgestattet, ohne sich mit den Komplexitäten der KI-Integration auseinandersetzen zu müssen. Was wäre, wenn der Entwickler einfach etwas wie Folgendes tun würde

$$image = Ai_Client::prompt( ‚Erstelle ein Bild, das den Inhalt dieses Beitrags schön widerspiegelt‘ )
->with_text($post_content)
->generate_image();

So einfach ist das. Mehr ist nicht erforderlich, um mit der KI zu interagieren. Man könnte alles erstellen, von einfachen interaktiven Tools bis hin zu leistungsstarken Agenten. Wenn KI für WordPress von grundlegender Bedeutung ist und im Ökosystem eingesetzt wird, gibt es einfach keinen Konkurrenten, der mithalten kann. (Anmerkung: Dieser Code ist nicht nur eine Idee, sondern Realität! Es handelt sich um den WP AI Client, der für WordPress 7.0 vorgeschlagen wird!

Gruselig! Horror! Da fehlt nur noch ein Prompt, der einen Artikel (also den für die Bilderzeugung erforderlichen Inhalt) auch ohne Zutun zu einem vorgegebenen Thema erstellt. Am besten noch vollautomatisch anhand einer Themenliste… und die kann man sich womöglich auch noch zu einem Kernthema von der KI erstellen lassen… unter Einbeziehung der ermittelten Trends.

Dann braucht es echt kein Blog mehr, denn ein Blog ist immer auch ein persönliches „Tagebuch“ oder eine persönliche „Kladde“. Doch wenn immer mehr Dinge von einer vermeintlichen maschinellen „Intelligenz“ ohne das Zutun des Betreibers erledigt wird, dann ist da nichts „persönliches“ mehr dran. Dann ist es ein Produkt ohne menschliche Note. Fehlen nur noch die rein automatischen virtuellen Leser, die KI-generierte Kommentare abgeben… und schon gibt es ein echtes Paralleluniversum.

Nun, wer da hinein möchte… nur zu… Reisende soll man nicht aufhalten.

Aber diese Reise findet ohne mich statt!

Und wenn WordPress in absehbarer Zeit zu einem KI-Monster mutiert (auch wenn ich diese Features ja vielleicht nicht nutzen müsste), dann wird es seinen Weg auch ohne mich gehen müssen. Allein schon deshalb, weil ich nicht möchte, dass irgendwer denkt, ich lasse mir meine Inhalte nun von einer KI schreiben.

Und womit werde ich das dann tun? Na klar: mit Hubzilla!

Schließlich habe ich ja kürzlich angefangen, ein Online-Buch zu dem Thema zu schreiben (kann auch schon gelesen werden: Hubzilla – das Social Network CMS) und außerdem hatte ich ja schon einmal begonnen, die Dampfdruck-Presse damit umzusetzen (Hubzilla-DDP) und pflege inzwischen alle neuen Artikel dort ein.

Wenn ich den Schritt gehe, dann wird das ein echter Kraftakt mit enormem Zeitaufwand. 1.074 Artikel und etliche Seiten müssten dann konvertiert werden… inklusive der 2.475 Kommentare. Wie ich das realisiere, weiß ich noch nicht. Aber wenn es erforderlich wird, weil WordPress diesen Schritt geht, dann tu ich das.

Dann halt nur noch Hubzilla auch als CMS!

Denn das hier

AI is an industry shift, quickly becoming a cornerstone of the next generation of technology. For WordPress to grow into the next phase it’s critical that AI become a fundamental part of WordPress itself, and for this to succeed everyone has a role to fulfill.

können die sich dorthin stecken, wo die Sonne nie hinscheint!

Henning Uhle hat sich auch damit befasst: WordPress-KI? Habt ihr Lack gesoffen?


Titelbild: Bearbeitung des Bildes von Seanbatty auf Pixabay

Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".

Was ist damit denn gemeint? ...

Im Zusammenhang mit Hubzilla liest man immer wieder vom "Grid".

Was ist damit denn gemeint?

Ganz einfach: Als Grid wird das gesamte Netzwerk von Servern bezeichnet, welche untereinander mit dem Kommunikationsprotokoll Nomad/Zot6 kommunizieren. Das ist vergleichbar mit der Bezeichnung "Fediverse", welches für das Netzwerk aller Server steht, die mit dem Kommunikationsprotokoll ActivityPub kommunizieren.

Erzeugt man also einen Kanal auf einem Hubzilla-Hub, so ist man in diesem Moment Teil des Grid. Die Kommunikation und vor allem die Interaktionsmöglichkeiten im Grid sind groß und umfassender, als die im Fediverse. Erst wenn man in seinem Hubzilla-Kanal das ActiviyPub Protokoll aktiviert, ist der Kanal auch Teil des Fediverse. Während die Urfassung von Hubzilla, damals noch unter dem Namen red bzw. Redmatrix, mit dem Protokoll Zot im Juli 2012 veröffentlicht wurde, hielt das Protokoll ActivityPub erst am 18.07.2017 Einzug in Hubzilla (am 03.09.2017 zog Mastodon, welches am 16.03.2026 released wurde, mit ActivityPub nach).

Dass Hubzilla so lange ohne und derzeit noch ohne generell aktiviertes ActivityPub daherkommt, hat historische Gründe und liegt im Zweck der Software begründet.

Es wurde und wird als

Hubzilla – Community-Server

bezeichnet und wurde ursprünglich mit

Groupware neu gedacht und neu erfunden. Verbinden und verknüpfen Sie dezentrale Web-Communities.

beschrieben.

Und weiter...

Was sind Hubz?
Hubz sind unabhängige, universell einsetzbare Websites, die nicht nur mit ihren Mitgliedern und Besuchern verbunden sind, sondern auch untereinander, um persönliche Nachrichten und andere Informationen auszutauschen.
Dadurch können Hub-Mitglieder auf jedem Hub alles sicher und privat mit jedem auf jedem Hub – überall – teilen oder, wenn gewünscht, Inhalte öffentlich mit jedem im Internet teilen.
Hubzilla ist die Server-Software, die dies ermöglicht. Es handelt sich um eine ausgeklügelte und einzigartige Kombination aus einem Open-Source-Content-Management-System und einem dezentralen Identitäts-, Kommunikations- und Berechtigungs-Framework sowie einer Protokollsuite, die unter Verwendung gängiger Webserver-Technologie (PHP/MySQL/Apache und beliebte Varianten) erstellt wurde. Das Endergebnis ist ein Maß an Systemintegration, Datenschutzkontrolle und Kommunikationsfunktionen, das Sie weder in einem Content-Management-System noch in einem dezentralen Kommunikationsnetzwerk für möglich gehalten hätten. Es bringt auch ein neues Maß an Zusammenarbeit und Datenschutz ins Web und führt das Konzept des persönlichen „Single Sign-On” für Webdienste im gesamten Internet ein.

Schließlich noch...

Hubzilla-Hubs sind

• dezentralisiert
• von Natur aus sozial
• optional mit anderen Hubs vernetzt
• datenschutzfähig (Datenschutzausnahmen gelten im gesamten Internet für jede registrierte Identität auf jedem kompatiblen Hub)

Mögliche Website-Anwendungen sind

• dezentrale Social-Networking-Knoten
• persönlicher Cloud-Speicher
• Datei-Dropboxen
• Verwaltung der Kommunikation und Aktivitäten von Organisationen
• Zusammenarbeit und gemeinschaftliche Entscheidungsfindung
• Websites für kleine Unternehmen
• Öffentliche und private Medien-/Dateibibliotheken
• Blogs
• Veranstaltungswerbung
• Feed-Aggregation und -Wiederveröffentlichung
• Foren
• Dating-Websites
• So ziemlich alles, was Sie auf einem traditionellen Blog oder einer Community-Website tun können, aber besser tun könnten, wenn Sie es einfach mit anderen Websites verbinden oder Dinge privat über Website-Grenzen hinweg teilen könnten.

Quelle: hubzilla-1.12

Sehr viel Zitat – sorry... aber damit erklärt sich, als was Hubzilla ursprünglich gedacht war und auch immer noch gedacht ist. Es handelt sich letztlich um eine Content Management Software (CMS), die auch Social Networkig (Macro- und Microblogging inklusive) erlaubt. Bis zum Einzug von ActivityPub war die Föderation auf das Grid (also alle Hubzilla-Hubs) und auf alle Server, welche das Diaspora Federation Protokoll sprachen (also alle Diaspora-Pods), beschränkt. Als sich dann ActivityPub als das verbindende Protokoll aller anderen Dienste herauskristallisierte, wurde Hubzilla um eben diese Protkoll erweitert. Es kann aber auch, wenn man AP nicht benötigt, weiterhin nur mit Nomad/Zot6 genutzt werden.

Ich bewerbe Hubzilla ja meistens als Fediverse-Software mit ganz besonderen Eigenschaften. Und das hat auch einen Grund. Oder mindestens zwei. Einmal ist Hubzilla wirklich hervorragend für die Teilnahme am Fediverse geeignet und wartet mit vielen Features auf, die andere Dienste nicht bieten. Und zweitens kann Hubzilla nur erfolgreich werden, wenn es von mehr und mehr Nutzern verwendet wird. Ja, und das sind erstmal Menschen, die ins Fediverse wollen oder mehr im Fediverse machen wollen.

Die andere und eigentliche Zielgruppe, nämlich diejenigen, die ein CMS benötigen, sind nicht so leicht zu erreichen und für Hubzilla zu begeistern. Man kann es durchaus auch anstatt WordPress oder Ghost verwenden und hat dabei noch den Vorteil, dass die Hubs im Grid schon miteinander verbunden sind und interagieren können (was bei WordPress- und Ghost-Servern untereinander nicht möglich ist). Die Anbindung an das Fediverse kann dann aber (wie es ja bei WordPress und Ghost auch der Fall ist) zugeschaltet werden. Damit wird aus Hubzilla ein echtes Fediverse CMS, also ein Social-Networking CMS.

Es ist an der Zeit, Hubzilla als CMS bekannter zu machen und Ein- bzw. Umsteigern die Nutzung zu erklären und zu erleichtern.

Fortsetzung zu Individuelle Anpassungen mit dem PDL-Editor (Einsteiger)

Eine Digitaluhr im simplen Text-Format in die Seitenleiste schieben und umständlich ein Hubzilla-Menü zu bauen... das ist jetzt nicht die "Hohe Schule" der Hubzilla-Gestaltung. Und auch nicht besonders schick und modern...

Fortsetzung zu Individuelle Anpassungen mit dem PDL-Editor (Einsteiger)

Eine Digitaluhr im simplen Text-Format in die Seitenleiste schieben und umständlich ein Hubzilla-Menü zu bauen... das ist jetzt nicht die "Hohe Schule" der Hubzilla-Gestaltung. Und auch nicht besonders schick und modern. Die Beispiele aus dem Artikel sollten nur dem grundlegenden Verständnis der Seitengestaltung bei Hubzilla dienen.

Das Thema ist auch kaum vollumfassend abzuhandeln. In diese Artikel hier gehe ich auch nur beispielhaft auf die Möglichkeiten ein und ich kann vielleicht Anstöße zu neuen Ideen geben, wie sich Nutzer ihr eigenes Hubzilla zusammenbauen können, ohne mit Admin-Rechten irgendetwas zu installieren.

Im ersten Teil habe ich ja gezeigt, wie man mit der App "Webseiten" ein Menü erstellt und dieses im PDL-Editor in die Seitenleiste packen kann... etwas umständlich und so eigentlich auch nicht vorgesehen.

Die Optik eines solchen Menüs ist ohnehin nicht sonderlich ansprechend und tut damit auch nichts gegen den Vorwurf, Hubzilla würde mit seinem Standard-Theme "Redbasic" doch recht altbacken aussehen.

Sinnvoller und auch so vorgesehen ist die Gestaltung mit selbst erstellten Blöcken. Nutzt man ein moderneres Theme, so passt sich die Optik auch halbwegs an das Theme an. So richtig schick wird es aber erst, wenn man auf ein modernes Framework zurückgreift.

Voraussetzungen

Voraussetzung für all die Dinge, die ich hier einmal vorführen möchte, sind die installierten Apps "PDL-Editor" und "Webseiten" und die Freigabe für Code für den Kanal, den man aufpeppen möchte.

Sofern man nicht selbst der Administrator ist, muss man für den letzten Punkt den Hub-Administrator kontaktieren und ihn bitten, Code für den eigenen Kanal zuzulassen. Für den Admin ist das nur ein einfacher Klick. Am besten schreibt man dem Admin bei der Bitte um Freischaltung auch gleich, wofür man das benötigt.

Sind diese Voraussetzungen geschaffen, die Apps also installiert und der Code erlaubt, kann es auch gleich losgehen.

Bootstrap und/oder W3.CSS

Die meisten Themes für Hubzilla bieten entweder ein Subset oder teilweise zumindest das Basis-Stylesheet von Bootstrap. Möchte man aber die Fähigkeiten von Bootstrap umfassend für die Gestaltung nutzen, ist es sinnvoll, das Framework auch original einzubinden.

Das funktioniert mit dem Inhaltstyp "HTML" auch völlig problemlos. Man muss nur führend im Block (gilt natürlich auch für Webseiten, wenn man sie so erstellen möchte) Bootstrap einbinden:

<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"   rel="stylesheet">`

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

Damit bringt man dann allerdings eine Fremdquelle mit ein. Nun ist Bootstrap nicht extrem groß (aktuell 8,3 MB), weshalb es sich anbietet, es einfach in der eigenen Hubzilla-Cloud vorzuhalten. Dazu legt man sich am besten im Wurzelverzeichnis der eigenen Cloud ein Verzeichnis bootstrap an, in welches man dann den Inhalt der Bootstrap-Distribution hochlädt.

Eingebunden wird es dann mit

<link href="https://<URL_des_Hub>/cloud/<Kanal>/bootstrap/css/bootstrap.min.css"   rel="stylesheet">`

<script src="https://<URL_des_Hub>/cloud/<Kanal>/bootstrap/js/bootstrap.bundle.min.js"></script>

Ich persönlich nutze aber auch sehr gerne das W3.CSS Framework, weil es ohne Javascript-Bibliothek auskommt und wesentlich kompakter ist (24,2 KB).

Auch dieses Framework muss man am Beginn eines Blocks einbinden:

<link rel="stylesheet" href="https://www.w3schools.com/w3css/5/w3.css">

Oder man lädt w3.css herunter, packt es z.B. in ein Verzeichnis css in der eigenen Cloud und bindet es mit

<link rel="stylesheet" href="https://<URL_des_Hub>/cloud/<Kanal>/css/w3.css">

ein.

Blöcke

Blöcke werden von der App "Webseiten" zur Verfügung gestellt. Sie dienen dazu, wiederholt benutzbare Inhalte aufzunehmen, welche man dann über den Blocknamen in Webseiten, Webseiten-Layouts oder aber auch in die Seitenlayouts von Hubzilla einbinden kann.

Der Vorteil ist, dass selbst erstellte Blöcke im ITEM-Bereich des PDL-Editors zur Verfügung stehen und per Drag-and-Drop an die passende Stelle geschoben werden können.

Ein Block kann so ziemlich "alles" beinhalten. Und man kann ihn mit verschiedenen Inhaltstypen erstellen.

Es stehen die Inhaltstypen

• bbCode
• HTML
• Markdown
• Text (plain Text)
• Comanche-Layout
• PHP

zur Auswahl.

bbCode erlaubt zwar keine Einbindung eines Web-Frameworks, dafür bietet es spezielle Auszeichnungen für hubzilla-spezifische Dinge.

HTML ist der universellste Inhaltstyp, sofern man sich mit HTML auskennt. Mit einem HTML-Block kann man auch die erwähnten Frameworks nutzen und tolle Effekte und Funktionen einsetzen.

Markdown eignet sich für formatierte Texte, ist also eher etwas für Beitrags-Inhalte und weniger für Blöcke, die man z.B. in die Seitenleiste einer Ansicht packt. Verwenden kann man es aber schon dafür.

(Plain) Text, also reiner, unformatierter Text, ist die einfachste Variante, gibt aber für unsere Zwecke nichts her.

Die Comanche-Layout Auszeichnungssprache ist für den Einsatz für die Dinge, welche hier behandelt werden auch nicht sinnvoll.

PHP hingegen kann man durchaus nutzen, wenn man dynamische Inhalte erzeugen möchte. Setzt allerdings das Verständnis und die Fähigkeit zum Programmieren voraus.

Ich werde jetzt hier fast ausschließlich Blöcke im HTML-Format einsetzen, weil damit die größte Flexibilität gegeben ist.

Beispiel 1: Navigationsleiste für die Kanalseite

Und jetzt fange ich einmal mit einem konkreten Beispiel an: Eine Navigationsleiste, die ich ganz oben im Inhaltsbereich der Kanalansicht einbauen möchte. Ich möchte damit Besuchern meiner Kanalseite eine einfache Navigation zu wesentlichen Bereichen meines Kanals ermöglichen. So sollen sie mit einem Klick, ohne länger zu suchen, auf meine Artikelseite, zu meinen Karten, zu meinem Wiki, meiner Galerie und zu meinem öffentlichen Kalender gelangen können. Damit es auch noch wirklich schick aussieht, gibt es als ersten Navigationspunkt eine Logo-Grafik des Hubs, die bei Anklicken zur Hub-Beschreibung führt.



Zunächst habe ich mir für den "Home-Button" eine passende Grafik gebaut, die transparenten Hintergrund hat und zur Schriftgröße der weiteren Buttons passt (100 x 24 Pixel):



Die Navigationsleiste realisiere ich in diesem Fall mit W3.CSS. Außerdem mach ich es noch ein wenig bunt, indem ich die Hover-Farbe für die Buttons auf verschiedene Standard-Farben des Frameworks festlege.

Den Block erstelle ich mit dem Block-Editor der App "Webseiten". Als Namen habe ich "wnavbar" festgelegt. Als Inhaltstyp

<link rel="stylesheet" href="https://hub.hubzilla.hu/cloud/pepecyb/css/w3.css">

<div class="w3-bar w3-border w3-light-grey">
  <a href="https://hub.hubzilla.hu/page/pepecyb/about" class="w3-bar-item w3-button"><img src="https://hub.hubzilla.hu/cloud/pepecyb/whoville/whoville-logo.png" alt=""></a>
  <a href="https://hub.hubzilla.hu/articles/pepecyb" class="w3-bar-item w3-button w3-hover-green">Artikel</a>
  <a href="https://hub.hubzilla.hu/cards/pepecyb" class="w3-bar-item w3-button w3-hover-blue">Karten</a>
  <a href="https://hub.hubzilla.hu/wiki/pepecyb" class="w3-bar-item w3-button w3-hover-teal">Wikis</a>
  <a href="https://hub.hubzilla.hu/gallery/pepecyb" class="w3-bar-item w3-button w3-hover-purple">Galerie</a>
  <a href="https://hub.hubzilla.hu/cal/pepecyb" class="w3-bar-item w3-button w3-hover-red">Kalender</a>
</div>

Anschließend muss der Block im PDL-Editor noch an die oberste Stelle des Inhaltsbereichs im MODUL "channel" geschoben und die Änderungen mit Klick auf den Button "APPLY" übernommen werden.



Nicht schlecht für den Anfang, oder?

Beispiel 2: Nochmal das Menü aus dem ersten Teil - aber besser

Im ersten Einführungsteil hatte ich ja ein Menü zu Artikeln von mir als Beispiel gebastelt. Allerdings nicht als Block, sondern als Hubzilla-Menü, welches man nur umständlich mit dem PDL-Editor einbauen kann:



Im Endeffekt ist ein natives Hubzilla-Menü nichts anderes als eine Liste von Links. Und eine Link-Liste kann man auch ohne die Menü-Funktion erstellen.

Für diese Beispiel jetzt, erstelle ich wiederum ein Menü zu einigen (drei) Artikeln meines Kanals. Allerdings als Link-Liste.

Der HTML-Code für den entsprechenden Block sieht dann z.B. so aus:

<a href="https://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a><br>
<a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a><br>
<a href="https://hub.hubzilla.hu/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a>

Hier einfach als einzelne Links untereinander mit dem <br>-Tag (nicht schön und elegant).

Sieht so aus:



Oder vielleicht besser als unsortierte Liste?

<ul><li><a href="https://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a></li></ul>

Sieht schon etwas besser aus:



In die Kanalseite eingebaut (und mit einem Titel versehen):



Nett! Aber... Nett ist die kleine Schwester von Scheiße! 😉😂

Also packen wir mal ein wenig Schnick und Schnack vom W3.CSS Framework dazu:

<link rel="stylesheet" href="https://hub.hubzilla.hu/cloud/pepecyb/css/w3.css">

<ul class="w3-ul w3-card-4 w3-pale-green" style="width:100%">
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/hhowama">Hubzilla-Häppchen: Hubzilla-Magie - OpenWebAuth / MagicAuth</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/folhsh2">Hubzilla: Hashtags folgen - Variante 2</a></li>
<li><a href="https://hub.hubzilla.hu/articles/pepecyb/irrungenwirrungen">Irrungen und Wirrungen - Hubzilla-Accounts, -Kanäle, -Profile</a></li>
</ul>

Und schon sieht es fetziger aus, oder?

Beispiel 3: Kontakt-Widget

Nun möchte ich noch in der Seitenleiste ein Element haben, welches die Kontaktmöglichkeit mittels Delta Chat anzeigt. Dafür möchte ich den QR-Code meines Delta Chat Accounts verwenden.

Nun könnte man einfach ein Bild, nämlich den QR-Code dort hinpacken. Und das sogar mit bbCode, weil's einfacher ist.



Dann sieht das halt so aus:



Nicht sehr ansprechend... und es frisst Platz, weshalb das Artikelmenü (oder andere Inhalte, falls man noch weitere in die Seitenleiste geschoben hat) nach unten rutscht und man erst scrollen muss, um es zu erreichen.

Besser wäre es, wenn dort ein Button "Kontakt" zu sehen wäre, welche bei Klick den QR-Code einblendet... und den man mit einem weiteren Klick wieder ausblenden kann. Dafür bietet sich das "Accordeon" von W3.CSS an.

Und damit es nicht so langweilig aussieht, peppe ich es noch mit einer Karte als Inhalt und einer kleinen Animation auf. Ach... und der Button wird schwarz und hat ganz leich abgerundete Ecken.

Der Code dafür:

<link rel="stylesheet" href="https://hub.hubzilla.hu/cloud/pepecyb/css/w3.css">

<button onclick="myFunction('contact1')" class="w3-button w3-block w3-black w3-left-align w3-round w3-margin-bottom">Kontakt</button>
<div id="contact1" class="w3-hide w3-container w3-animate-zoom">
<div class="w3-container">
  <div class="w3-card-4 w3-center" style="width:100%;max-width:400px">
  <h2>Delta Chat</h2>
    <img src="https://hub.hubzilla.hu/cloud/pepecyb/Pepes%20pic/delta.png" alt="" style="width:100%">
    <div class="w3-container w3-center">
      <p>derpepe@morpork.email</p>
    </div>
  </div>
</div>
</div>

<script>
function myFunction(id) {
  var x = document.getElementById(id);
  if (x.className.indexOf("w3-show") == -1) {
    x.className += " w3-show";
  } else {
    x.className = x.className.replace(" w3-show", "");
  }
}
</script>

Schnell noch in die Seitenleiste geschoben... und schon ist die Delta Chat Karte da!

Beispiel 4: Sinnfreier PHP-Block

Einfach, um zu zeigen, dass man auch was mit PHP machen kann, hier ein Block, der anzeigt, wann die aktuelle Seite aufgerufen wurde. Mir ist einfach nichts Nützliches eingefallen...

Dazu legt man einen Block mit dem Inhaltstyp "PHP" an. Ich nenne ihn hier einfach mal "aufrufzeit".

Der Code ist extrem simpel!

date_default_timezone_set('Europe/Budapest');
echo 'Seite aufgerufen am: ' . date('d.m.Y - H:i:s');

Beachte hier: Es darf kein <?php davor und kein ?> am Ende stehen!

Das Ding packe ich in die Profilansicht ganz ans Ende, damit jeder weiß, wann er sich das Profil angeschaut hat:

Soviel dazu...

Damit lasse ich es jetzt einfach bewenden. Ich wollte hier einfach nur zeigen, was über die einfachen Dinge aus dem ersten Teil mit Hubzilla alles möglich ist.

Man ist extrem frei, die Oberfläche für sich selbst, aber auch für Besucher attraktiver und praktischer zu gestalten.

Und man ist nicht auf die Fähigkeiten vorhandener Widgets und Styles vorhandener Themes beschränkt. Mit aktuellen Frameworks kann man sehr viel gestalten, was frisch und modern aussieht.

Und da geht manches, was man vielleicht gar nicht für möglich hält. So habe ich einfach einmal was ausprobiert (in einem Test-Kanal... weil ich es eigentlich nicht nutzen würde)...

Zum einfachen Verfassen von bbCode-Beiträgen nutze ich gerne den SCEditor. Den habe ich mir lokal in eine HTML-Datei abgelegt und als Lesezeichen in die Lesezeichen-Symbolleiste meines Browsers gepackt. Ein Klick und er öffnet sich... und ich kann losschreiben.

Und da dachte ich mir einfach mal: Ob man das auch in eine Hubzilla-Ansicht packen kann?

Und tatsächlich ist es ohne große Anstrengung dort umsetzbar. Sah dann so aus:



Ihr seht also... es ist echt viel möglich. Einfach einmal ausprobieren.

Um Euch in die Frameworks einzuarbeiten oder den Einstieg in PHP zu schaffen, empfehle ich persönlich die Tutorials von w3 schools:

• Bootstrap 5 Tutorial
• W3.CSS Tutorial
• PHP Tutorial

Viel Spaß beim Experimentieren und bei der Gestaltung Eures Hubzilla-Kanals!

---

Artikel in der Hubzilla KnowledgeDB