- Primo v3.2 stellt eine Website zugleich als lokale Dateien und als Zeilen in einer Server-Datenbank dar, sodass Agenten den Code ändern können und nichttechnische Redakteure dieselbe Website im Browser bearbeiten können
- Entwickler arbeiten mit Svelte-Komponenten und YAML-Dateien für Seiten, Inhalte, Einstellungen und Routen und synchronisieren diese mit
primo push mit der relationalen Datenbank des Servers
- Der Browser-Editor bietet Textbearbeitung direkt auf der gerenderten Seite, Drag-and-Drop für Blöcke sowie benutzerdefinierte Seitentypen und Felder, sodass er weniger von formularzentrierten CMS-Oberflächen abhängt
- Die Hauptzielgruppe sind Entwickler, Freelancer und Agenturen, die nichttechnischen Redakteuren maßgeschneiderte Websites übergeben müssen; angeboten werden 12 Starter und mehr als 40 Blöcke
- Inhalte liegen in einem auf PocketBase basierenden SQLite, der Code bleibt im Repository des Nutzers, und mit MIT-Lizenz sowie statischem Export per
primo pull lässt sich die Abhängigkeit vom Dienst verringern
Ein CMS-Modell mit Dateien und Datenbank zugleich
- Primo v3.2 ist ein Open-Source-CMS, das seit 2019 weiterentwickelt wird und die gesamte Website gleichzeitig als Dateien und Datenbankzeilen abbildet
- Lokale Dateien werden direkt von Agenten bearbeitet, während die Server-Datenbank für die visuelle Bearbeitung durch Menschen im Browser dient
- Der grundlegende Ablauf besteht darin, eine Website mit einem Agenten zu erstellen und anschließend Kunden oder Bekannten Bearbeitungsrechte im Browser zu übergeben
- Im Beispiel erstellt
claude einen Seitentyp für die Preisseite, schreibt pages/pricing.yaml und blocks/pricing-tiers/component.svelte und deployt dann mit primo push drei Dateien
- Nach dem Deployment können Nutzer Formulierungen und Preise der Preisstufen direkt im Browser ändern
Lokale Dateistruktur für Agenten
primo pull lädt die komplette Website als normale Dateien herunter
- Enthalten sind Komponenten, Seiten, Inhalte, Einstellungen und Routen
- Blöcke sind Svelte-Komponenten, Inhalte und Einstellungen sind YAML
- Man kann eine neue Website scaffolding-basiert erstellen oder eine bestehende herunterladen
- CLI-Agenten wie Claude Code, Cursor und Codex bearbeiten das gesamte Repository
- Der Ablauf entspricht dem Bearbeiten einer kompletten Codebasis wie bei Next.js oder SvelteKit
- Das Beispielkommando lautet
$ claude "redesign the pricing page"
primo push synchronisiert geänderte Dateien mit der relationalen Datenbank des Servers
- Kunden bearbeiten dieselbe Website im Browser direkt auf der gerenderten Seite
- Von Blöcken deklarierte Felder werden als bearbeitbare Felder bereitgestellt
Ein CMS, das direkt auf der gerenderten Seite bearbeitet wird
- Der Editor arbeitet direkt auf der gerenderten Seite und verlangt keinen separaten CMS-Tab oder eine Formularansicht als primäre Bearbeitungserfahrung
- Alle von Blöcken deklarierten Felder werden als anklickbare Flächen und Labels angezeigt
- Dabei wird dasselbe Modell verwendet, das auch der Renderer liest; eine separate Transformationsschicht gibt es nicht
- On-Page-Bearbeitung bedeutet, dass Text auf der gerenderten Seite angeklickt und sofort eingegeben werden kann
- Feld-Chips zeigen an, welches Element gerade bearbeitet wird
- Mit Drag-and-Drop-Blöcken lassen sich Blöcke im Seitenbaum neu anordnen, hinzufügen und entfernen, und Änderungen werden sofort in die Quelle geschrieben
- Benutzerdefinierte Seitentypen definieren eine Seitenform einmal, danach können Kunden beliebig viele Seiten nach demselben Modell erstellen, ohne es zu beschädigen
- Benutzerdefinierte Felder unterstützen Text, Rich Text, Bilder, Links, Zahlen, Gruppen und Repeater
- Die Bearbeitungs-UI wird aus dem Schema erzeugt
- Echtzeit-Zusammenarbeit ermöglicht mehreren Personen, dieselbe Seite gleichzeitig zu bearbeiten, einschließlich Live-Anwesenheitsanzeige und konfliktfreier Bearbeitung
- Strukturierte Formularansichten werden für Felder verwendet, die nicht auf der Seite sichtbar sind, etwa SEO, Metadaten, Repeater oder versteckte Einstellungen
Starter und Blöcke für Anbieter maßgeschneiderter Websites
- Primo richtet sich an Entwickler, Freelancer und Agenturen, die maßgeschneiderte Websites für nichttechnische Redakteure erstellen
- Der Marketplace bietet Starter für verschiedene Kundentypen sowie allgemeine Abschnittsblöcke
- Als Beispiele werden Starter für Restaurants, Coaches, Portfolios und lokale Dienstleistungen genannt
- Angeboten werden 12 Starter und mehr als 40 Blöcke
- Jeder Starter ist eine in sich abgeschlossene Website
- Enthalten sind Svelte-Komponenten und Typfelder
- Er wird als Repository scaffolded
- Es gibt keinen Framework-Lock-in und keine versteckte Runtime
- Nutzer können Starter forken, anpassen und deployen oder eigene Starter und Blöcke kuratieren
Unterschiede zu WordPress, Headless CMS und Site Buildern
- WordPress kann Kunden bearbeitbare Websites bereitstellen, wird hier aber mit einer Struktur verglichen, in der Inhalte und PHP-Themes miteinander verflochten sind
- Ein Headless CMS kann die Codestruktur sauber halten, aber das Schema befindet sich in einer separaten Admin-Oberfläche
- Site Builder bieten Drag-and-Drop, werden hier aber als Modell dargestellt, bei dem das Ergebnis von einer Plattform geliehen wird
- Primo betont als Unterschied, dass Teams und Agenten gemeinsam dieselbe einzige Quelle bearbeiten
- Der Code liegt in Svelte-Dateien und im Repository des Nutzers
- Kunden bearbeiten auf der gerenderten Seite
- Das Schema liegt in
fields.yaml neben .svelte
- Agenten können die gesamte Website als Dateien bearbeiten
- Hosting und Lizenz werden als Self-Host und MIT präsentiert
Dateneigentum und Betriebsstatus
- Inhalte werden über PocketBase in SQLite gespeichert, der Code bleibt im Repository des Nutzers
primo pull bietet jederzeit einen statischen Export von Code und Inhalten- Primo steht unter MIT-Lizenz und erklärt, dass laufender Code und erstellte Websites auch dann weiter funktionieren, wenn das Projekt verschwinden sollte
- Der Betriebsstatus wird als im 7. Jahr, v3.2 beschrieben; Beispiele für produktive Websites sind Kundenprojekte von Agenturen, kleine Commerce-Stores, Dokumentationsseiten und die eigenen Marketing-Seiten
- Agenten werden nicht als neues Produkt behandelt, sondern als neuer Client für dasselbe Modell, das seit 2019 gepflegt wird
Payload, TinaCMS, Sanity Studio und React-Unterstützung
- Payload ist ein Headless CMS, bei dem sich das Schema in einer Admin-Oberfläche befindet und Inhalte per API abgerufen werden
- TinaCMS wird mit einem Git-basierten Editor vor Markdown-Dateien verglichen
- Sanity Studio ist eine React-basierte Admin-Oberfläche über einem gehosteten Content Lake
- Primo verwendet dieselben Svelte-Dateien und Datenbankzeilen für Editor und Renderer; dazwischen gibt es keine API-Transformationsschicht
- React wird derzeit in Primo-Blöcken nicht unterstützt
- Primo wurde rund um den Compile-Time-Ansatz von Svelte entwickelt, und diese Struktur macht Blöcke zu Dateien, die Editor und Renderer direkt lesen können
- Unterstützung für React innerhalb von Primo-Blöcken steht nicht auf der Roadmap
- Auf der Roadmap steht
primo integrate <framework>
- Zuerst kommt ein Ansatz, bei dem Primo auf eine bestehende SvelteKit-App aufgesetzt wird
- Danach wird Astro erwähnt, während Next.js ein Wunsch bleibt
- In dieser Richtung verbleiben produktive Komponenten im jeweiligen Framework, während Primo nur Inhalte und Editor übernimmt
Blockstruktur und CLI-Authentifizierung
- Ein Block besteht aus zwei zusammenliegenden Dateien
- Die Komponente übernimmt das Rendering
- Das Schema teilt dem Editor mit, welche Felder vorhanden sind
- Das Beispiel
blocks/hero/fields.yaml deklariert die Felder headline, subheadline und cta
headline und subheadline sind textcta ist link
- Die CLI-Authentifizierung liest die Umgebungsvariable
PRIMO_TOKEN
- Das Token wird pro Website in der Admin-Oberfläche erzeugt
primo pull <host> klont ein Projektprimo push lädt nur geänderte Dateien hoch
- Die Authentifizierung ist dieselbe wie für Redakteure, es muss also keine separate API-Oberfläche erlernt werden
- Sie funktioniert per HTTPS mit allen Primo-Instanzen, einschließlich self-hosted Instanzen
Startbefehl
- Ein neuer Workspace wird mit folgendem Befehl erstellt
npx primo-cli init my-workspace
- Nach der Erstellung werden die Zustände
workspace ready und server.yaml written angezeigt
- Lizenz- und Preisangaben werden als MIT, Open Source und dauerhaft kostenlos beschrieben
1 Kommentare
Hacker-News-Kommentare
Ein CMS-Editor, in dem man Blöcke per Drag-and-drop platziert, sieht in Demos beeindruckend aus, aber nachdem wir intern einen ähnlichen Editor betrieben haben, war es eine endlose Update-Hölle.
Ständig kamen Anfragen wie: „Kann man den Text rechtsbündig ausrichten und blau machen?“, und am Ende bekamen die einzelnen Blöcke immer mehr Eigenschaften.
Die tatsächlichen Content-Autoren tun sich schwer, ihn effektiv zu nutzen, und die Ergebnisse sind meist auch nicht zufriedenstellend.
Mit mehr Schulung kann es besser werden, aber der Kompromiss zwischen Freiheitsgrad und Wahrung der Markenidentität bleibt bestehen.
In unserem Fall scheint ein Headless CMS der bessere Ansatz zu sein. Besser ist es, nur den Content bereitzustellen und ein paar Fachleute ihn passend zum Design in Code umzusetzen, aber nicht jeder hat diesen Spielraum, also haben solche CMS sicher ihren Platz.
Vor ein paar Monaten haben wir die E-Commerce-Website eines Kunden überarbeitet und mit Maglev editierbare Sections/Blöcke gebaut; die Editor-Erfahrung selbst war gut.
Nach dem Launch stellte der Kunde jedoch einen Marketing-Mitarbeiter ein, der sehr grundlegende HTML/CSS-Kenntnisse hatte, und es war mühsam, ihn davon zu überzeugen, dass er nicht selbst HTML/CSS schreiben, sondern benötigte Sections von einem Entwickler erstellen lassen sollte.
Man könnte wie bei Primo einen Entwickler-Editor einbauen, aber nach langer Erfahrung will ich nicht, dass Kunden direkt am HTML/CSS der Website herumfummeln.
Ich will auch keine Beziehung nach dem Motto: „Wenn du es kaputtmachst, musst du zahlen.“
Allgemeiner gesagt hat jedes CMS dasselbe Problem. Ich habe auch schon einem Unternehmen geholfen, dessen Webflow-Site kaputt war; ein typischer Fall, in dem ein Designer sie erstellt hatte und dann ein Marketing-Mitarbeiter die UI „verbessern“ wollte und alles zerstört hat.
Die Anzahl der Komponenten, die man bauen kann, ist begrenzt.
Idealerweise braucht der Kunde ein CMS, mit dem er HTML ohne Code leicht ändern kann. So lädt die Seite schnell, ist gut für Suchmaschinen optimiert, und Entwickler müssen das Rad nicht neu erfinden.
Deshalb habe ich Versoly (https://versoly.com/) gebaut. Ich fragte mich, warum man jedes Mal einen Entwickler kontaktieren muss, nur um eine Hintergrundfarbe zu ändern oder eine neue Section hinzuzufügen.
Allerdings scheint mir das Problem, dass Content-Editoren Text rechtsbündig ausrichten und blau machen wollen, unabhängig vom verwendeten CMS weiterhin zu bestehen.
Es gibt noch kaum offizielle Dokumentation, aber wenn Interesse besteht, würde ich mich freuen, wenn ihr euch die Startseite anseht und prüft, ob es einen Versuch wert ist.
Ich würde auch gern allgemeines Feedback oder Erkenntnisse aus eigenen Erfahrungen hören.
https://brick-cms.com/
GitHub:
https://github.com/primocms/primo
Frühere Diskussionen:
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
Show HN mit Text, offenbar von einem anderen Account des ursprünglichen Autors:
https://news.ycombinator.com/item?id=36801101
SSG scheint für Static Site Generator zu stehen, aber sobald man sich auch nur ein wenig aus einem bestimmten Fachgebiet herausbewegt, sollte man nicht versuchen, es für Leser verständlicher zu schreiben?
Obwohl ich Webentwicklung mache, musste ich kurz nachdenken, um dieses Akronym zu entschlüsseln.
Trotzdem kann es für Nutzer, die es noch nicht wissen, hilfreicher sein, es auszuschreiben.
Es wäre schön, ein solches Tool für fortlaufende dynamische Inhalte wie Blogposts oder Reviews zu haben.
Viele Leute hängen an WordPress, aber Customizing und Themes sind nahezu ein Albtraum.
Damals war es eine der wenigen Möglichkeiten, einfach ein Blog zu erstellen.
Das Problem ist, dass man, sobald man den Standardumfang verlässt, plötzlich tiefes Wissen über die interne Struktur von WordPress braucht.
Vor etwa drei Jahren hat HN das Open-Source-CMS Primo auf die Frontpage gebracht (https://news.ycombinator.com/item?id=23820201); dadurch habe ich mitten in der Pandemie meinen bequemen Remote-Job gekündigt und mich Vollzeit darauf gestürzt.
Danach habe ich meine Ersparnisse aufgebraucht, die Domain primo.af an die Taliban verloren und sogar meine Frau dazu überredet, als Entwicklerin/Designerin mitzuhelfen.
Trotzdem bin ich stolz auf das, was in dieser Zeit entstanden ist, und wenn ich sehe, wie es Menschen hilft, Webentwicklung zu lernen, persönliche Websites online zu stellen und Kundenseiten zu verwalten, überzeugt mich das nur noch mehr von der Stärke und Einfachheit dieses Ansatzes.
Primo 2, das heute als öffentliche Beta erscheint, bietet unter anderem Content-Bearbeitung direkt auf der Seite und Page Building.
Ich habe Primo ursprünglich entwickelt, weil ich davon erschöpft war, wie mühsam das Erstellen von Websites ist und wie schwer sie für nichttechnische Nutzer zu verwalten sind.
Bei Freelance-Projekten hatte ich mit fragilen WordPress-Themes, Dashboard-Navigation und Plugin-Kombinationen zu kämpfen; als Agenturentwickler fand ich monolithische CMS und Metaframework-/Headless-CMS-Lösungen für Landingpages oder einfache Unternehmensseiten überdimensioniert.
Als Coding-Dozent habe ich gesehen, wie Studierende eingeschüchtert wurden, sobald sie mit CLI, API, Paketmanagern, Bundlern, Frameworks und Metaframeworks konfrontiert waren, nur um das Web nutzen zu können.
Es gab keinen schlanken, zugänglichen Weg, gängige Websites wie Blogs, Landingpages und einfache Unternehmensseiten zu erstellen, zu verwalten, zu entwickeln und zu hosten.
Primo ist im Kern ein CMS, das Content-Verwaltung einfach macht, bündelt aber Page Building, Code-Editing, Static-Site-Generierung sowie Deployment/Hosting über GitHub in einer Oberfläche.
Blöcke werden in Svelte geschrieben, also in HTML/CSS/JS, sind dadurch responsiv und haben gekapselte Styles.
Da es sich um statische Sites handelt, profitiert man außerdem von den Kosten-, Sicherheits-, Skalierungs- und Geschwindigkeitsvorteilen von Serverless.
Primo richtet sich weniger an Menschen, die WYSIWYG-Designkontrollen im Stil von SquareWixFlow bevorzugen, sondern an diejenigen, die ihre Sites mit HTML/CSS/JavaScript vollständig kontrollieren und sich selbst sowie nichttechnischen Freunden/Kunden/Mitwirkenden zugleich eine sehr einfache Content-Editing-Erfahrung bieten wollen.
Es zielt auf Menschen, die von No-Code-Tools und proprietären Plattformen frustriert sind, aber die Macht von Code behalten und trotzdem etwas Einfacheres wollen.
Darüber hinaus ist Primo ein Versuch, das Web in den Händen der Einzelnen zu belassen.
Wenn Web-Publishing zugänglicher wird, hoffe ich, dass das die technische Mündigkeit erhöht und Menschen freie Ausdrucksmöglichkeiten in die Hand gibt, statt sie leicht in Blackboxes und ummauerte Gärten zu drängen.
Das Problem war allerdings das Content-Management-System. Ich hatte erwartet, wie bei einem normalen Static-Site-Generator Markdown-Dateien in Ordner zu legen und daraus je nach Template Artikel oder Blogposts zu erzeugen.
Eine Zeit lang habe ich das Primo-Repository geforkt und einen eigenen Ansatz implementiert, der Datenbankeinträge in eine Datei-/Ordnerstruktur umwandelt; der umgekehrte Weg sah aber knifflig aus, also bin ich einen anderen Weg gegangen und habe, inspiriert von diesem Guide, meinen eigenen Markdown-Static-Site-Generator gebaut: https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
Mein Use Case ist vielleicht nicht die Zielgruppe, aber wenn ein Projekt statt in eine Datenbank in eine dynamische Datei-/Ordnerstruktur geschrieben würde und sich wie ein normales SvelteKit-Projekt bearbeiten und versionieren ließe, wäre das ein großartiges Produkt.
Im Grunde wäre es dann ein Svelte-basiertes Static-Site-Generator-Framework mit Komponentenbibliothek und eigener UI.
Das Forum ist auch gut, und auf ein paar Fragen, die ich hatte, gab es bereits Antworten.
Ich nutze WordPress schon lange und spiele in letzter Zeit mit Svelte herum; das hier kommt dem, wonach ich gesucht habe, wirklich sehr nahe.
Großen Respekt für die Arbeit, die in so etwas steckt.
Ein gutes Projekt, aber ich finde es etwas enttäuschend, dass man für „Self-Hosting“ ein Supabase-Konto braucht.
Es scheint nur mit bestimmten Hosting-Diensten zu funktionieren, die sich mit Supabase verbinden lassen, und es führt einen dazu, Seiteninhalte aus GitHub zu beziehen.
Daher wirkt es eher wie ein CMS, das zusammen mit bestimmten Service-Anbietern läuft, als wie ein CMS, das man tatsächlich selbst hosten kann.
Das Ziel war, es den Leuten so einfach wie möglich zu machen, ihren eigenen Server aufzusetzen, deshalb wurde es an solche Dienste angebunden.
Allerdings arbeite ich daran, das Backend zu entkoppeln, damit man es wirklich selbst hosten kann.
Der einzige wirklich nötige externe Dienst ist GitHub, und später könnten wohl auch andere Anbieter wie GitLab dazukommen.
Ein gutes Projekt, aber ehrlich gesagt bin ich inzwischen an einem Punkt, an dem ich für Entwickler wie Nutzer weniger JavaScript oder sogar einen Ansatz ohne JavaScript für besser halte.
Ich migriere meinen alten Blog gerade auf einen neuen Blog, der mit Zola (https://www.getzola.org) generiert wird, und baue auch meine neu erstellte Portfolio-Site mit React/Gatsby wieder in Zola nach, weil der Performance-Unterschied so groß ist.
Manchmal surfe ich im Web mit deaktiviertem JavaScript; wenn eine Site dann gar nicht vollständig funktioniert oder nicht einmal lädt, ist das ein großes Ausschlusskriterium.
Meine alte Site nutzte jQuery, was schon ziemlich nervig war, und Dinge wie React auszuprobieren war ein Albtraum.
Intern verwendet es den Svelte-Compiler.
Es ist kaum zu glauben, dass es schon mehr als zehn Jahre her ist, dass ich 2010 einen Site-Generator namens Stiqr gebaut habe
Die Website ist nicht mehr in Betrieb, aber in einem YouTube-Video kann man noch Spuren davon sehen
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
Damals, 2010, kam Responsive Design auf, wodurch ich das Projekt einstellte, aber ich glaube weiterhin, dass die Art, wie Websites in naher Zukunft erstellt werden, in diese Richtung geht
Die Kombination aus Drag-and-drop/Block-Ansatz und Svelte ist wirklich großartig, aber für mich wirkt das Tool am falschen Ende des Spektrums angesiedelt
Es ist ein visueller Website-Builder, bei dem man Blöcke in einem Online-Editor anpasst
Was ich möchte, ist ein Online-Interface, mit dem ein Kunde Texte hinzufügen oder ändern und kleine Anpassungen an einer Svelte-Website vornehmen kann, die ich offline mit meinen eigenen Tools gebaut habe
Es wäre gut, wenn ich die Site nach einem bestimmten Interface-Standard bauen könnte, Primo sie dann lesen kann und der Kunde sie über ein visuelles Interface bearbeiten kann
Größere Änderungen kämen wieder zu mir zurück, und ich könnte die Geschwindigkeit und Freiheit meines Offline-Workflows beibehalten
Man könnte sagen, dass ich ein Headless CMS brauche, aber alles, was ich ausprobiert habe, war übermäßig komplex und verursachte schon durch Einrichtung und Wartung große Kopfschmerzen
Solange du keine bestimmten Felder anlegst, lassen sich visuelle Aspekte – etwa ob ein Bild rund oder rechteckig ist – nicht bearbeiten
Wenn das Problem ist, dass du keine lokale IDE verwenden kannst: Derzeit ist es möglich, Svelte-Komponenten in Vanilla JavaScript zu bündeln, sie in Primo-Blöcke zu importieren und Daten über Felder zu übergeben
Allerdings würde ich empfehlen, vor dem Einsatz in Produktion noch ein paar Wochen zu warten, bis es stabilisiert ist
Der beschriebene Ansatz entspricht im Grunde genau der Art, wie ich Kundenprojekte umsetze. Ich schreibe den gesamten Code, verwende in der Regel Blöcke aus anderen Projekten wieder und übergebe dann eine Site, die der Kunde vom ersten Tag an mit minimaler Schulung bearbeiten kann
Ich frage mich, ob du meinst, dass „Blöcke anpassen“ keine Textänderungen umfasst, oder ob die möglichen Aktionen nicht ausreichend eingeschränkt sind, um sie an Kunden zu übergeben
Man kann per Drag-and-drop verwaltete Sections in normales Seiten-Markup einfügen, und es scheint die meisten Frameworks einschließlich Svelte zu unterstützen
Die Einrichtung erfolgt per FTP