Es gibt viele treue Leser, die schon viele Jahre immer wieder auf meine Seite kommen. Bei vielen hat sie einen festen Platz in ihrem Feedreader oder sie haben die Beiträge per Newsletter abonniert. Daher werden viele von euch gerade überrascht sein, dass hier alles anders aussieht und auch nicht mehr nachbelichtet heißt.
Den ersten Post auf nachbelichtet gab es am 14. November 2005. Ja – richtig gelesen: Es ist über 20 Jahre her, als der erste Beitrag hier erschienen ist. WordPress war damals nur knapp 2 Jahre alt und ich startete mit der Version 1.5 „Strayhorn". Richtig los ging es dann 2006, mit der WordPress-Version 2.0 „Duke". Damit konnte man nun ganz einfach Bilder hochladen, hatte einen Rich-Text-Editor und vieles mehr.
Seitdem habe ich genau 50 WordPress-Versions-Updates mitgemacht, Themes und Designs wechselten und auch meine Themen und Schwerpunkte. WordPress hat mich zwei Jahrzehnte (mehr oder weniger 😏) zuverlässig begleitet – und trotzdem habe ich mich dazu entschieden, alles hinter mir zu lassen und auf Hugo umzustellen. Warum?
VARTA 40 Stück AA-Batterien
- High Performance Qualität "Made in Germany", in Deutschland produziertes Markenprodukt
- Batterien Vorratspack Mignon AA Alkalibatterien zum Sparpreis, 40 Stück in recycelbarer Verpackung
Fire TV Stick 4k+
- Unser leistungsstärkster Streaming-Stick – Mit dem leistungsstarken Prozessor sind blitzschnelle App-Starts und eine reibungslose Navigation garantiert, für Entertainment auf einem neuen Level.
- Bild und Klang in lebensechter Qualität – Genieße die Vorstellung in 4K Ultra HD, mit Unterstützung für Dolby Vision, HDR10+ und immersives Dolby Atmos-Audio.
soundcore by Anker P20i
- KRAFTVOLLER BASS: Die kabellosen soundcore P20i Earbuds haben übergroße 10-mm-Treiber, die einen kraftvollen Sound mit verstärkten Bässen liefern, damit du dich in deinen Lieblingssongs verlieren kannst.
- PERSONALISIERTE EQs: Mit der soundcore App kannst du die Steuerung der Bluetooth-Kopfhörer anpassen und aus 22 EQ-Voreinstellungen wählen. Mit "Find My Earbuds" kann ein verlorener Bluetooth-Kopfhörer Geräusche abgeben, damit du ihn wiederfindest.
Was ist Hugo HugoStatic Site Generator in Go. Erzeugt aus Markdown-Dateien und Templates eine statische Website – extrem schnell (Build in Millisekunden). fricklr.com läuft auf Hugo mit dem Blowfish-ThemeMehr dazu → – und was ist ein Static Site Generator? Anders als WordPress, das bei jedem Seitenaufruf HTML aus einer Datenbank und PHP-Skripten zusammensetzt, erzeugt Hugo alle Seiten einmalig vorab als fertige HTML-Dateien, daher ist Hugo ein Static Site Generator (SSG). Das Ergebnis: blitzschnelle Ladezeiten, keine Datenbank, keine Sicherheitslücken durch serverseitige Skripte – und kein Admin-Dashboard, das gehackt werden kann. Mehr dazu auf gohugo.io .
Nicht nur ein neues System – eine inhaltliche Neuausrichtung
Der Wechsel der Plattform ist nur die eine Seite. Mindestens genauso wichtig war für mich die inhaltliche Neuausrichtung.
Als ich 2005 mit nachbelichtet anfing, war Blogging etwas völlig Neues. Social Media, wie wir es heute kennen, gab es noch nicht. Meine Posts waren bunt gemischt – Random-Gedanken zu allen möglichen Themen, Zeitgeschehen, was mir eben in den Sinn kam. Die Professionalisierung von Blogs war noch in weiter Ferne. Meine Begeisterung für Digitalfotografie bildete dann schnell einen Schwerpunkt, der sich mit dem Erscheinen von Adobe Lightroom 2006 festigte. Zig Jahre drehten sich die meisten Inhalte um Fotografie, Lightroom, Fotoequipment und alles darum herum. Das führte auch zu Veröffentlichungen in Zeitschriften wie Dogma, ct Fotografie, Digital Photo, Fotopraxis und einigen mehr.
Ein weiteres großes Thema war und ist die Musikproduktion – Homerecording, DAWs, Software, Equipment. Dieses Thema wird mich wohl immer begleiten. Fotografie hingegen hat über die Jahre an Stellenwert verloren. „Nachbelichtet" passte irgendwann nicht mehr so recht als Name für meine Seite – wobei das letztendlich egal ist, ein Name ist nur ein Name.
Was mir heute am meisten Freude macht, sind Smarthome , DIY, Technik, Code-Beispiele für Home-Assistant-Skripte und Automationen. Ende 2015 habe ich meine Liebe zur Elektronik und dem Reparieren von Geräten, dem Entwurf und Umsetzung von elektronischen Schaltungen, Löten usw. wiederentdeckt. 3D-Drucker, CNC CNCComputerized Numerical Control – computergesteuerte Fräsmaschine. Im Hobbybereich oft als Portalfräse (z.B. Genmitsu PROVerXL 4030) zum Fräsen von Holz, Kunststoff und Aluminium. Gesteuert per G-Code aus CAM-SoftwareMehr dazu → -Fräsen, Lasercutter, Oszilloskop und vieles mehr stehen nun auf 30 qm Werkstattfläche - meinem “Lab”.
Frickeln ist ein großer Teil meiner DNA. Ich wollte nicht nur einen sauberen technischen Schnitt, sondern auch eine inhaltliche Neuausrichtung. Darum wird aus nachbelichtet.com ab heute fricklr.com.
Die Erkenntnis: Ich brauche kein CMS, ich brauche einen Text-Editor
Der entscheidende Moment kam nicht durch einen Ausfall oder ein kaputtes Update. Es war die schleichende Erkenntnis, dass WordPress mich zunehmend vom Schreiben abhielt, statt es zu ermöglichen.
Ich hatte für nachbelichtet.com einen ziemlich potenten Server zur Verfügung – und trotzdem wartete ich ständig. Datenbank-Zugriffe im Admin-Bereich, die sich träge anfühlten. Der Gutenberg-Editor, der bei jedem Tastendruck kurz stockte. Plugin-Updates, die vor dem eigentlichen Schreiben erledigt werden wollten. Plugins, die sich gegenseitig behindern, alle die gleichen JS-Bibliotheken in unterschiedlichen Versionen aufrufen und ihre eigenen CSS-Styles mitbringen die sich gegenseitig überschreiben.
Caching, das nach jeder Änderung geleert werden musste. Jedes Mal, wenn ich eine Idee für einen Beitrag hatte, standen gefühlt erst 15 Minuten Admin-Kram zwischen mir und dem ersten geschriebenen Satz. Irgendwann schrieb ich weniger, weil die Hürde, überhaupt anzufangen, zu hoch geworden war.
Hugo dreht den Spieß um: Ich öffne
Obsidian
ObsidianNotiz-App mit lokalem Markdown-Speicher und bidirektionalen Links. Beliebt für persönliches Wissensmanagement. Open Source, mit großer Plugin-Community. Speichert Daten als lokale Markdown-Dateien – keine Cloud-AbhängigkeitMehr dazu →
, tippe hugo new content de/posts/mein-thema/index.md --kind review, und schreibe los. Kein Login, kein Dashboard, kein „Wie, schon wieder ein Plugin-Update?". Der lokale Hugo-Server zeigt Änderungen sofort beim Speichern im Browser an – kein „Preview"-Button, kein Warten aufs Admin-Backend. Ich nenne das WYWIWYW: What You Write Is What You Want.
Ein hugo server --buildDrafts --navigateToChanged genügt und jede gespeicherte Änderungn im
Markdown
MarkdownVereinfachte Auszeichnungssprache für Text, die mit einfachen Zeichen wie #, *, [] arbeitet. Wird von Hugo, Obsidian, GitHub, Notion und vielen anderen Tools verwendet. Die Inhalte auf fricklr sind alle in Markdown geschriebenMehr dazu →
des Posts, wird sofort im Browser angezeigt. Legt man sich in seinem
Terminal
TerminalProgramm, das eine Shell anzeigt (z.B. macOS Terminal, integriertes Terminal in VS Code, Git Bash). Hier tippst du CLI-Befehle ein
einen Alias dafür an, genügt z. B. ein hugopreview.
Und ja: Man muss gewillt sein, ein bisschen mit der Kommandozeile zu arbeiten. Wer vor dem Terminal zurückschreckt, für den ist Hugo nichts. Aber der Aufwand ist überschaubar – ein hugo server zum Vorschauen, ein git push zum Veröffentlichen. Das war’s. Dafür schreibe ich Posts mit jedem beliebigen Editor – wenn es sein muss mit Notepad oder vim – praktisch vollständig mit allen Einstellungen. Kein Herumgeschubse von Blöcken (ich weiß, dass WordPress auch Markdown kann), keine Dropdowns, um Tags oder Kategorien auszuwählen. Ich greife praktisch nicht mehr zur Maus beim Schreiben. Ich kann sogar einen kompletten Blogpost mit allen Einstellungen diktieren …
Performance ohne Ballast
WordPress braucht PHP, eine MySQL-Datenbank, Caching-Plugins und ständige Updates – nur um am Ende HTML auszuliefern. Hugo generiert genau das beim Build: statische HTML-Dateien. Keine Datenbank, kein serverseitiges Rendering, keine Angriffsfläche.
Das Ergebnis sind Pagespeed-Werte nahe 100 – ganz ohne Cache-Plugins, ganz ohne stundenlanges Optimieren. Der Seitenaufbau ist rasend schnell, und Cloudflare Pages liefert alles weltweit per CDN aus. Kein Vergleich zu dem, was selbst ein gut konfigurierter WordPress-Server leisten kann. Cloudflare benutzt man ohnehin vor Wordpress, wenn man sich den Hacker-Horden draußen nicht komplett schutzlos ausliefern möchte.
Sicherheit ohne Aufwand
Kein Login-Bereich mehr, der gehackt werden kann. Keine XML-RPC-Angriffe. Keine wp-admin Brute-Force-Versuche. Hugo hat schlicht keinen Admin-Bereich – geschrieben wird lokal im Editor, deployed wird per Git-Push. Der Server ist reines CDN, da gibt es nichts zu kompromittieren. Ich habe keine schlaflosen Nächte mehr wegen kritischer WordPress-Sicherheitslücken, die sofort gepatcht werden müssen.
Die Dinge, die plötzlich trivial werden
Was mich an Hugo am meisten begeistert, sind die Dinge, die in WordPress entweder unmöglich oder nur mit teuren Plugins möglich waren:
Tags umbenennen? In WordPress brauchst du ein Plugin oder fummelst in der Datenbank herum. In Hugo ist es ein einfaches Suchen-und-Ersetzen über alle Markdown-Dateien. 2.000 Posts aktualisieren? Ein sed-Befehl - oder die Ersetzen-Funktion von VSCode. Kein Datenbank-Gefrickel.
Automatische Sicherung? Bei WordPress waren meine Inhalte in der Datenbank gefangen. Änderungen nachvollziehen? Fehlanzeige. Bei Hugo liegt alles im Git-Repo: Content, Layouts, Styles, Konfiguration, sogar die Affiliate-Produktdaten. Jede Änderung ist nachvollziehbar, jedes Experiment ein Branch. Rollback ist ein einfaches git revert. Versionierung durch GitHub, Gitea oder was auch immer – eingebaut, ohne Plugin.
Eigene Funktionen? In WordPress brauchst du functions.php-Gefrickel oder ein Page-Builder-Plugin. In Hugo schreibe ich Go-Templates für Layouts und Python- oder
Shell
ShellKommandozeilen-Interpreter, der Befehle entgegennimmt und ausführt. In HA: die Bash-Shell im SSH-Add-On; auf dem Mac z.B. zsh
-Skripte für alles andere. Praktisch jede Anforderung lässt sich mit einem Shell-Skript oder einem Python-Script realisieren – ohne Abhängigkeit von Plugin-Entwicklern, die vielleicht nächstes Jahr keine Updates mehr liefern. Meine komplette Hugo-Umgebung mit allen selbst programmierten Zusatzfunktionen lässt sich mit einem einzigen setup.sh auf jedem meiner Macs einrichten (ginge auch auf Windows oder Linux).
Mehrsprachigkeit – kein Plugin nötig
WPML oder Polylang waren ständige Quellen von Konflikten, Query-Performance-Problemen und Update-Ängsten. Jedes größere WordPress-Update ließ mich bangen, ob das Sprach-Plugin noch kompatibel ist. Und wehe, man musste die Datenbank migrieren – dann wurde aus einem Nachmittag schnell ein Wochenende. Shortcode-Leichen, HTML-Reste durch veraltete oder nicht mehr verfügbare Plugins - alles Geschichte.
Hugos natives Multilingual-System braucht kein Plugin: translationKey im Frontmatter verlinkt DE/EN, die URL-Struktur (/de/ und /en/) ist natives Hugo-Verhalten, und Partial-Templates sind von Haus aus sprachsensitiv. Keine zusätzlichen Datenbank-Tabellen, keine Query-Performance-Einbußen, keine Update-Angst. Es funktioniert einfach.
Bild-Workflow – vom Media-Uploader zur R2-Pipeline
In WordPress: Bilder über den Media-Uploader hochladen, warten, in den Post einfügen, hoffen dass die Thumbnail-Generierung durchläuft. Dann ein Optimierungs-Plugin installieren, das die Bilder nachträglich komprimiert - natürlich wieder mit Abo-Plan. Bei 20 Jahren Inhalt kamen da schnell mehrere Gigabyte an Medien zusammen, die gesichert, migriert und optimiert werden wollten. Nicht zu sprechen von den zig Bild-Varianten und Thumbnails die irgendwelche Plugins in wp-upload kacken.
Mein neuer Workflow mit Cloudflare R2 und meinem selbst entwickelten fricklr-img-Tool: Quelldatei rein → WebP-Optimierung + R2-Upload + Markdown-URL in die Zwischenablage. Aufrufbar per Terminal, Raycast oder direkt aus Obsidian. Kein Browser-Tab mehr für den Media-Uploader. Die Bilder liegen auf R2, werden per CDN ausgeliefert, und ich zahle Cent-Beträge statt für Server-Speicherplatz. Dazu eine lokale Gallery unter http://localhost:8787, die alle R2-Bilder in einem pfeilschnell durchsuchbaren Thumbnail-Grid anzeigt – Drag & Drop, Batch-Auswahl, Markdown-Links per Klick kopieren. Das hätte ich in WordPress nie so bauen können.
Volle Layout-Kontrolle
In WordPress brauchst du ein Page-Builder-Plugin oder kämpfst mit functions.php, um eigene Templates zu bauen. Und selbst dann stößt du schnell an Grenzen – oder dein Theme-Update überschreibt deine Änderungen.
In Hugo schreibe ich einfach Go-Templates. Die Homepage ist ein Bento-Grid aus Partial-Templates, die Kategorie-Seiten sind komplett custom, und der Split-Hero für Artikel wäre in WordPress ein teures Theme-Feature oder stundenlanges CSS-Gefrickel. Ich habe die volle Kontrolle über jedes
Was mich WordPress gekostet hat – und was Hugo kostet
Wordpress vor allem eines gekostet: Nerven! WordPress-Hosting mit ausreichend Performance kostet schnell einen mittleren, zweistelligen Betrag pro Monat. Dazu kommen gerne Pro-Plugins mit dem Geschäftsmodell jährlicher Zahlungen für Updates – für Features, die in Hugo entweder eingebaut oder mit einem Shell-Skript erledigt sind.
Meine aktuellen Kosten: Cloudflare Pages ist für statische Seiten kostenlos, R2 für Medien ist bis 10 GB ist ebenfalls kostenlos oder kostet wenige Cent pro Monat, wenn man das Gratis-Kontingent überschreitet. Unterm Strich zahle ich für das Cloudflare Hosting exakt: 0,00 Euro.
Der Preis: Entwicklungszeit – und die Migration
Seit Weihnachten 2025 habe ich am Umstieg auf einen Static Site Generator gearbeitet. Hugo selbst ist schnell installiert, aber die ganzen Extras – der Bild-Workflow mit R2, die Affiliate-Integration mit Amazon Creator API APIApplication Programming Interface – definierte Schnittstelle, über die Programme kommunizieren. Home Assistant bietet eine REST- und eine WebSocket-API (z.B. für MCP) , das Bento-Grid-Homepage-Layout, die benutzerdefinierten Shortcodes, das bilinguale Setup mit allen Templates – das war nicht an einem Wochenende erledigt.
Dazu kam die Migration der bestehenden Inhalte. Ein Umstieg auf ein völlig anderes System und eine neue Domain bedeutet normalerweise unheimlichen Aufwand: Inhalte konvertieren, URLs mappen, 301-Weiterleitungen einrichten, tote Links vermeiden. In über 20 Jahren nachbelichtet sind fast 3.000 Beiträge entstanden – das ist keine Kleinigkeit.
Allerdings war auch klar: Vieles davon war hoffnungslos veraltet. Die Google Search Console und meine Umami-Analytics-Daten zeigten mir, dass nur etwa 150 Beiträge den Löwenanteil der Besucher auf die Seite brachten. Also habe ich mich entschlossen, nur diese Traffic-Bringer und einige Posts, die mir persönlich wichtig waren, zu migrieren. Der Rest wurde sauber archiviert (mehr dazu in einem anderen Beitrag).
Das war auch eine Art Katharsis. Es ist nicht einfach, so viel Content aufzugeben – in jedem Beitrag steckten Zeit, Recherche und nicht zuletzt Herzblut und Erinnerungen. Aber der Schnitt war nötig, und rückblickend war es der richtige Schritt.
Technisch war die Migration dann mit ein paar Python-Skripten – und ja, Vibe-Coding hat dabei sehr geholfen – erstaunlich schnell und sauber erledigt. WordPress-Export-XML einlesen, Markdown-Dateien mit korrektem Frontmatter generieren, Redirects aus der alten URL-Struktur ableiten. Was in WordPress-Projekten gerne mal Wochen oder Monate frisst, war bei mir in wenigen Stunden durch. Ein weiterer Punkt, bei dem sich die Flexibilität eines dateibasierten Systems auszahlt: Du kannst mit simplen Skripten massenhaft Inhalte verarbeiten, ohne dich durch Datenbank-Tabellen und Plugin-APIs zu wühlen.
Der Unterschied zu WordPress: Diese Zeit habe ich einmal investiert, und sie zahlt sich jetzt jeden Tag aus. Bei WordPress hätte ich stattdessen kontinuierlich Zeit in Wartung, Updates und Workarounds gesteckt – ohne jemals den gleichen Grad an Kontrolle und Automatisierung zu erreichen. Ich habe lieber einmal 100 Stunden (okay - es waren deutlich mehr) in meinen perfekten Workflow investiert als jeden Monat 5 Stunden in Admin-Kram.
Deployment per Push statt Update-Angst
In WordPress lief eine Veröffentlichung so ab: Änderung im Editor machen, auf „Veröffentlichen" klicken – und hoffen, dass nicht genau in diesem Moment ein Plugin-Update den Cache leert, ein Theme-Update das Layout zerschießt. Bei größeren Änderungen kam noch der „Wartungsmodus" dazu, der die Seite für Besucher kurz lahmlegte.
In Hugo ist der Deployment-Workflow: Änderung comitten → git push → GitHub Actions baut die Seite → Cloudflare Pages deployt sie. Einige Sekunden später ist alles live. Kein SSH-Login, kein Wartungsmodus, keine Downtime. Und wenn doch mal etwas schiefgeht: git revert, nochmal pushen, fertig. Der gesamte Veröffentlichungsprozess ist ein einziger Git-Workflow – atomar, nachvollziehbar, rückgängig machbar.
Man benötigt auch kein Staging-System wie bei Wordpress, wenn man größere Umbauten oder neue Funktionen testen will. Alle Anpassungen und Änderungen lassen sich lokal durchführen.
Da Hugo im Gegensatz zu monolithischen Systemen keine Datenbank nutzt, liegt die gesamte Website als simpler Quellcode vor. Größere Umbauten, neue Kurzcodes (Shortcodes) oder tiefgreifende Design-Anpassungen werden einfach in einem eigenen Git-Branch isoliert entwickelt. Auf dem lokalen Rechner simuliert der Befehl hugo Server die fertige Website in Millisekunden und spiegelt jede Änderung in Echtzeit wider.
Der eigentliche Gamechanger ist jedoch das Preview Deployment moderner Hosting-Plattformen wie Cloudflare Pages oder Netlify: Sobald man den Branch zu GitHub oder GitLab pusht, baut die Pipeline im Hintergrund automatisch eine exakte Kopie der Website unter einer privaten Vorschau-URL. So lassen sich neue Funktionen auf echten Endgeräten testen oder Feedback einholen, während die produktive Live-Seite völlig unberührt und stabil bleibt. Erst wenn alles perfekt funktioniert, wird der Branch zusammengeführt (gemergt) – sicher, deterministisch und ohne das Risiko von Datenbankkonflikten.
Keine Vendor-Lock-in – reines HTML, überall hostbar
Ein strategischer Punkt, der mir wichtig ist: Hugo generiert am Ende nichts als statische HTML-Dateien, CSS und JavaScript. Keine proprietäre Datenbank, kein PHP, kein spezielles Server-Setup.
Selbst wenn Cloudflare Pages morgen vom Markt verschwindet – ich nehme den public/-Ordner, werfe ihn auf irgendeinen x-beliebigen Webserver, und die Seite läuft. Kein Export-Tool, kein Migrations-Plugin, kein „Jetzt konvertiere ich mal meine WordPress-Datenbank". Der Server kann das billigste Shared Hosting sein, denn es braucht weder PHP noch Datenbank. Diese Unabhängigkeit ist mir nach 20 Jahren in einem proprietären Ökosystem enorm viel wert.
Gleiches gilt für die Inhalte: Alle Posts und Seiten sind einfaches Markdown. Keine proprietären Blockfunktionen, kein HTML im Inhalt. Einfach Markdown. Damit lassen sich die Inhalte problemlos konvertieren und wiederverwenden. Die Inhalte liegen nicht in einer Datenbank, sondern ganz einfach im Dateisystem.
Für wen ist Hugo nichts?
Ich will nicht so tun, als wäre Hugo die Lösung für jeden. Ein Static Site Generator erzeugt statische Seiten – das heißt: keine serverseitige Logik, keine Formularverarbeitung, keine Buchungsseiten, keine Shops. Wenn du WooCommerce, BuddyPress, ein Buchungssystem oder interaktive Formulare brauchst, bist du bei WordPress (oder einem anderen CMS) besser aufgehoben. Hugo kann all das nicht, und das ist auch nicht sein Anspruch.
Wenn du eine Seite mit mehreren Autoren betreibst, die keinen Bock auf Terminal und Git haben – bleib bei WordPress. Wenn du nie wieder eine Kommandozeile sehen willst – bleib bei WordPress. Wenn du keine Zeit in die initiale Entwicklung investieren kannst oder willst – bleib bei WordPress.
Hugo ist die richtige Wahl, wenn du die volle Kontrolle willst, keine Angst vor dem Terminal hast und bereit bist, einmalig Zeit in deinen Workflow zu investieren, um danach nie wieder Admin-Pflichten zu haben. Es ist ein Werkzeug für Leute, die gerne basteln und optimieren – nicht für Leute, die einfach nur schnell einen Blog starten wollen. Es ist aber auch ein Werkzeug für Leute, die Wert auf effiziente Workflows, schnellen Seitenaufbau und Sicherheit vor Hacker haben möchten.
Fazit: Weniger Admin, mehr Schreiben
Ich habe Admin-Pflichten, Betriebskosten und Ablenkung eliminiert und einen Tool-Stack aufgebaut, der aufs Schreiben optimiert ist. Keine Plugin-Updates mehr, keine Datenbank-Optimierung, keine Sicherheits-Patches für eine Software, die ich gar nicht brauche. Keine trägen Admin-Seiten, die mich vom Schreiben abhalten.
WordPress 7 ist gerade erschienen – und zum ersten Mal seit 20 Jahren ist mir das völlig egal. Kein Update einspielen, keine Kompatibilität prüfen, keine Release Notes lesen. Ich schreibe einfach.
Nach 20 Jahren WordPress war der Wechsel ein Befreiungsschlag. Ich schreibe wieder, statt zu administrieren. Und genau darum geht es doch.
Es mag noch den ein oder anderen Fehler geben und manche Detailverbesserungen stehen noch aus, aber ich hoffe, dass die Seite für euch gut funktioniert. Falls ihr Probleme entdeckt, freue ich mich über einen Kommentar unter diesem Beitrag oder eine Mail an schreibt mir einfach.
Übrigens gibt es nun neben dem RSS-Feed mit allen Beiträgen auch RSS-Feeds für jede Kategorie. Wenn ihr euch also nur für Musik interessiert, könnt ihr einen sortenreinen Feed nur dafür abonnieren.
In den nächsten Tagen gibt es auch wieder die Möglichkeit, den Newsletter zu abonnieren. Auch dieser läuft auf einem völlig neuen, eigenen System ohne Abhängigkeiten von irgendwelchen Plugins oder Anbietern – frisch von eigenen, fränkischen Bio-Servern.
Hallo! Ich bin Markus – der Fricklr. ⚡ Elektrotechniker, 🎵 Musiker (Bass, Gitarre, Keyboard) und seit über 30 Jahren beruflich „irgendwas mit Internet“ 🌐 – inzwischen auch mit KI 🤖 – ein 55-jähriger Generalist aus Bayern.
Dein Feedback hilft mir, noch interessantere Beiträge zu schreiben. Bei „Ja“ findest du danach eine kleine Option, meine Arbeit zu unterstützen.
Verwandte Themen entdecken
Inhaltskarte →Verbindungen als Liste anzeigen
- Homebrew: der komfortable Paketmanager für deinen Mac - Teil 1 Kategorie-Kontext: tools
- macshot: kostenloses Open-Source-Screenshot-Tool für macOS Kategorie-Kontext: tools
- macOS: Das automatische Öffnen von Programmen beim Neustart verhindern Kategorie-Kontext: tools
Was sagst du dazu? Kommentiere jetzt!
Teile deine Gedanken, Fragen oder Erfahrungen mit der Community.