PageKit — der selbst gehostete GrapesJS-Website-Builder, als Quellcode. Early Access sichern
Füge deinem Headless CMS einen visuellen Drag-and-Drop-Editor hinzu, ohne deine bestehende Content-API, dein Frontend oder deine Infrastruktur anzufassen.
Der Bildschirm oben ist ein Mock-up des Arrangements, in CSS gezeichnet, sodass es die Seite nichts kostet. Die dahinterstehende Editor-Engine ist real und öffentlich: Öffne die offizielle GrapesJS-Demo, ziehe einen Abschnitt auf die Canvas, und du siehst auf dieselben Canvas-, Komponentenbaum- und Stilkontrollen, die dein Content-Team auf deinem eigenen CMS bekommen würde.
Die Demo läuft auf grapesjs.com mit Browserspeicher. Nichts darauf berührt deine Inhalte.
Ein Headless CMS gibt deiner Anwendung eine API-erste Inhaltsgrundlage. Was es den Autoren des Inhalts nicht immer bietet, ist eine Möglichkeit, die Seite beim Erstellen zu sehen.
Strukturierte Felder eignen sich hervorragend für einen Artikel, einen Produktbericht oder ein Einstellungsdokument. Sie passen schlecht zu einer Seite, deren Bedeutung ihr Layout ist – eine Kampagnenseite, eine Feature-Tour, ein Preisvergleich. Für diese Fragen fragen die Verantwortlichen meist nach derselben Shortlist:
Was Redakteure verlangen
GrapesJS bietet diese visuelle Bearbeitungsebene, ohne dass du dein CMS ersetzen musst.
Eine headless-Architektur trennt Inhalte von der Präsentation, genau deshalb bleibt eine Bearbeitungslücke: CMS kennt die Felder, das Frontend kennt das Rendering, und nichts dazwischen kennt die Seite. Das Hinzufügen einer visuellen Bearbeitungsschicht schließt diese Lücke, ohne eine Seite zu entprangern.
Traditionelles Headless CMS
Fehlt
Headless CMS + GrapesJS
Fügen Sie visuelle Bearbeitung hinzu, ohne auf die Headless-Architektur zu verzichten.
Denn jede der drei Ebenen ist gut in etwas, das die anderen beiden nicht können, und eine visuelle Bearbeitungsebene ist die einzige, die niemand für dich ausliefert. Hier ist, wer was besitzt, sobald der Editor installiert ist.
Dein Headless CMS
Die Inhaltsinfrastruktur, die du bereits betreibst.
GrapesJS
Die visuelle Bearbeitungsebene, die du hinzufügst.
Dein Frontend
Unverändert. Es behält alles, was es vorher besessen hat.
Behalten Sie die Architektur bei. Verbessern Sie das Bearbeitungserlebnis.
Das visuelle Bearbeitungserlebnis: Canvas, Komponentenbaum, Blöcke, Stilsteuerungen, Gerätebreiten.
Persistenz über REST, GraphQL oder Ihr eigenes API. Ein Speicheradapter besteht aus zwei Funktionen – eine, die lädt, eine, die speichert.
Deine bestehende Inhaltsinfrastruktur. Sie behält das Schema, die Medienbibliothek, die Nutzer und die bereits vorhandenen Veröffentlichungsregeln.
Die Delivery-API, von dem deine Frontends bereits gelesen haben. Einen Editor hinzuzufügen fügt einen Autor hinzu, nicht eine zweite Inhaltsquelle.
Jedes Frontend, das dein CMS API verbraucht.
Eine Inhaltsquelle. Mehrere Frontends.
Sehen Sie, wie der Editor in eine Anwendung eingebettet wirdDie Bearbeitungsschicht wird über dasselbe API angehängt, das Ihr Frontend bereits aufruft. Egal, ob Sie Strapi, Contentful, Sanity, Directus, Hygraph, Prismic, Payload oder ein eigenes Team geschriebenes CMS ausführen, der Integrationspunkt ist ein Paar von Endpunkten, die ein Dokument laden und speichern.
Diese Plattformen lassen sich über ihre APIs integrieren; wie genau, hängt vom Inhaltsmodell und der API des jeweiligen CMS ab. GJS.Market veröffentlicht für die meisten davon keine offizielle Integration, und diese Seite behauptet auch nichts anderes.
Behalte dein CMS. Behalte dein Frontend. Füge einen besseren visuellen Editor hinzu.
Die untenstehenden Karten beschreiben die Integrationsfläche, die jede Plattform bietet, nicht einen Supportanspruch. Eine davon hat ein Community-Speicher-Plugin im GJS.Market-Katalog; die übrigen sind Integrationen, die du oder ein Implementierungspartner gegen deren veröffentlichtes API bauen würden.
REST · GraphQL
Selbstgehostet, mit Inhaltstypen, die du selbst definierst. Das Editor-Dokument wird in der Regel zu einem JSON-Feld auf einem Seitensammlungstyp.
REST · GraphQL
Getrennte Liefer- und Management-APIs. Der Editor schreibt über das Management-API; dein Frontend liest weiterhin das Liefer-API.
GROQ · GraphQL
Portable Text und einen Dokumentspeicher. Das Editor-Dokument liegt neben deinen bestehenden Feldern, anstatt sie zu ersetzen.
REST · GraphQL
Die einzige Plattform auf dieser Liste mit einem bereits auf GJS.Market veröffentlichten Community-Speicher-Plugin.
Das Plugin anzeigenGraphQL
GraphQL-first, also ist der Adapter eine Abfrage und eine Mutation statt zwei URLs.
REST
Slice-basierte Inhalte. Editor-Blöcke werden sauber auf Slices abgeordnet, wenn du die Block-Menge darauf ausrichtest.
REST · GraphQL
Code-definierte Sammlungen, sodass das Feld, in das der Editor schreibt, im selben Repository wie der Editor deklariert ist.
REST · GraphQL · Custom
Alles, was eine Ladeanforderung beantworten und eine Speicheranfrage akzeptieren kann. Zwei Endpunkte sind der gesamte Vertrag.
Der einzige CMS-benannte Adapter im Katalog
Directus Storage ist ein kostenloses, von der Community veröffentlichtes GrapesJS-Speicher-Plugin, das aus dem Silex-Projekt stammt. Es ist eine wirklich brauchbare Referenz dafür, wie ein Adapter aufgebaut ist – Authentifizierungsbefehle, Laden, Speichern –, aber im eigenen Eintrag steht, dass es auf ein älteres Directus SDK zielt. Behandle es also als Ausgangspunkt zum Nachlesen, nicht als unterstütztes Produkt zum Einbauen.
Directus StorageEin visueller Editor ist nur in einem headless Setup nützlich, wenn das, was er erzeugt, noch dem von dir entworfenen Schema entspricht. In GrapesJS deklariert ein benutzerdefinierter Komponententyp sein eigenes editierbares traits – und in diese traits gehören dein CMS-Feldnamen.
Ausgearbeitetes Beispiel
hero-section
editor.DomComponents.addType('hero-section', {
model: {
defaults: {
// Traits become the fields your CMS entry already has.
traits: [
{ name: 'title', label: 'Title' },
{ name: 'subtitle', label: 'Subtitle' },
{ name: 'image', type: 'image' },
{ name: 'ctaHref', label: 'Button link' },
],
},
},
});Der visuelle Editor sollte sich an dein Inhaltsmodell anpassen – und nicht dein CMS dazu zwingen, sich an den Editor anzupassen.
Zwei Darstellungen stammen aus demselben Editor und beantworten unterschiedliche Fragen. Eine kann zum Bearbeiten wieder geöffnet werden; die andere kann gerendert werden. Die meisten Produktionseinrichtungen behalten beide in verschiedenen Spalten, und das ist eine Designentscheidung und keine Regel.
editor.getProjectData()Der Komponentenbaum, Stile, Seiten und Assets sind strukturierte Daten. Es ist das, was der Editor braucht, um die Sitzung genau so zu rekonstruieren, wie sie gelassen wurde, was die einzige Darstellung ist, die eine zweite Bearbeitungsrunde intakt übersteht.
Verwenden Sie es, wenn: Jemand wird diese Seite im Editor wieder öffnen.
editor.getHtml() + editor.getCss()Markup und Stylesheet werden aus demselben Baum generiert. Das ist das, was eine Vorschau-iframe, ein statischer Export oder eine Veröffentlichungspipeline verbraucht, und es ist nicht zuverlässig als Bearbeitungssitzung wieder importierbar.
Verwenden Sie es, wenn: etwas nachgeschaltet muss es ohne den Editor rendern.
Speichere die Repräsentation, die dein Editor für zukünftige Bearbeitungen benötigt, und generiere die Ausgabe, die dein Frontend oder deine Veröffentlichungspipeline benötigt.
Die gleiche Bearbeitungsebene, die auf verschiedene Teile deines Produkts zeigt. Jede dieser Ebenen hat eine eigene Seite auf GJS.Market, weil jede andere Fragen aufwirft, sobald du am Editor vorbei bist.
Lass Content-Teams Seiten visuell erstellen, wobei die Einträge noch im CMS leben, das du bereits betreibst.
Visuelle Bearbeitung, in TiefeLassen Sie Marketingteams Kampagnen starten, ohne dass ein Entwickler bei jeder Layoutänderung eingeladen ist.
Landingpage-BuilderErstelle Seiten visuell, während jeder Inhalt in deinem CMS bleibt und jede URL bei deinem Frontend bleibt.
Drag-and-Drop-BuilderStellen Sie Ihren Kunden einen visuellen Editor innerhalb Ihres Produkts zur Verfügung, zusätzlich zu Ihrem Content API.
SaaS-Seiten-BuilderGib jeder Organisation in deinem Produkt eigene Seiten, Assets und Vorlagen hinter einem Editor.
Multi-Tenant-EditorenPassen Sie das Bearbeitungserlebnis rund um Ihre Marke an, sodass der Editor als Teil Ihres Produkts gelesen wird.
White-Label-BuilderErstelle wiederverwendbare E-Mail-Vorlagen mit demselben Komponentenmodell und einem Mail-Safe-Blockset.
E-Mail-Vorlagen-BuilderErstellen Sie strukturierte visuelle Dokumentationsseiten, die weiterhin über Ihre Inhalte API ausgeliefert werden.
Seiten-PresetsWas mit der Engine kommt, was ein Plugin hinzufügt und was bleibt die Aufgabe deiner Anwendung. Der Unterschied ist wichtig, wenn du die Arbeit abgrenzst, statt eine Feature-Liste zu lesen.
GrapesJS wird ohne CMS, ohne Hosting, ohne Benutzerkonten und ohne Berechtigungsmodell ausgeliefert. Diese bleiben bei deinem CMS und deiner Anwendung.
Das ist keine Entscheidung, die man einmal für das gesamte Produkt trifft. Es ist eine Entscheidung, die man pro Inhaltstyp trifft, und die meisten Teams nutzen am Ende beides.
Die eigene formularbasierte Bearbeitung deines CMS, gesteuert vom Schema.
Am besten für
Eine Canvas, bei der die Anordnung der Inhalt ist.
Am besten für
Verwende strukturierte Felder, wo Struktur wichtig ist. Nutze visuelle Bearbeitung, wo Layout und Komposition wichtig sind.
Bearbeiten und Veröffentlichen sind getrennte Ereignisse, und ein headless Setup macht das leicht durchzusetzen: Das Entwurfsdokument und das veröffentlichte Dokument sind unterschiedliche Zeilen, die von unterschiedlichen Token gelesen werden.
Der Eintrag existiert in deinem CMS mit Draft-Status.
Jemand schreibt die Seite auf der Canvas.
Dein Frontend rendert den Entwurf bei jeder Gerätebreite.
Eine zweite Person liest die Seite, da Besucher sie sehen werden.
Die Genehmigung wird von deiner Anwendung erfasst, nicht vom Editor.
Dein CMS bewirbt den Draft und dein Frontend validiert erneut.
Manuelle Freigabe
Was ein Rezensent wechseln sollte können
Trenne das Bearbeiten vom Veröffentlichen.
Das ist der Vorteil, den du dir bereits gekauft hast, als du ein Headless CMS gewählt hast, und ein visueller Editor verbraucht ihn nicht – solange das, was der Editor schreibt, im Content API bleibt und nicht in einer Vorlage.
Headless CMS
Ein Content API, gelesen von jedem Kanal
Webseite
Next.js
Mobil
React Native
Anwendung
Nuxt
Eine headless-Architektur ermöglicht es, dass dieselbe Inhaltsinfrastruktur verschiedene Frontends bedient.
Wenn der Editor Teil eines Produkts und kein internes Werkzeug ist, benötigt jede Kundenorganisation eigene Seiten, Assets und Vorlagen – und darf niemals die von jemand anderem sehen.
Deine Anwendung
Die Aufteilung wird hier auf dem Server durchgesetzt
Organisation A
Organisation B
Organisation C
GrapesJS bringt keine eigene Mandantenfähigkeit mit. Mandantenisolation, Branding pro Mandant und Veröffentlichungsregeln liegen bei deiner Anwendung, und jeder Speicheraufruf muss serverseitig eingegrenzt werden.
Wenn Ihre Kunden den Editor nutzen, sollte er wie Teil Ihres Produkts aussehen. Die Panels, das Icon-Set, die Blockbibliothek und die Vorlagen sind alle konfigurierbar, und die umliegende Anwendung liefert alles, was der Editor nicht tut.
Rollen und Berechtigungen stehen auf dieser Liste, weil ein gebrandeter Editor sie braucht – nicht weil der Editor sie bereitstellt. Sie werden von deinem Backend durchgesetzt.
Die Engine ist eine Sprosse des Stacks. Unten ist die ganze Leiter, mit einem ehrlichen Etikett auf jeder Sprosse: Was in GrapesJS selbst ausgeliefert wird, was du auf GJS.Market kaufen oder herunterladen kannst und was bleibt dein eigenes Werk.
Zwei Sprossen sind absichtlich als eigene Arbeit markiert. Die CMS-Integration ist spezifisch für dein Inhaltsmodell, und der Katalog hat keine Berechtigungen oder Audit-Log-Plugin – ein Implementierungspartner kann beides bauen, aber kein Produkt hier tut das.
Jede untenstehende Präsentation wurde mit dem Live-Katalog abgeglichen und ist veröffentlicht und kaufbar. Die Preise werden beim Bau vom Marktplatz abgelesen, also sieht man das, was man heute sieht.
Wohin das Projektdokument gehört und was passiert, wenn ein Browser ausfällt, bevor er dort ankommt.
Durchstöbern Sie diese KategorieEin kostenloses, von der Community veröffentlichtes Speicher-Plugin für Directus – der einzige CMS-benannte Adapter im Katalog und ein lesbares Modell zum eigenen Schreiben.
Ein Storage Wrapper für Cloud Firestore, wenn das Projektdokument in einer gehosteten Dokumentendatenbank und nicht in deinem CMS liegt.
Browserseitige Persistenz, nützlich als Offline-Puffer oder für eine Demo, die laufen muss, bevor API existiert.
Autosave und Absturzwiederherstellung. Ohne das ist eine nicht gespeicherte Sitzung weg, wenn der Tab geschlossen wird und dein Editor die Schuld bekommt.
Die Abschnittsbibliothek, aus der deine Editoren ziehen, und das dahinterliegende Wiederverwendungsmodell.
Durchstöbern Sie diese KategorieDer Grundblock, von dem man eine Bibliothek starten kann, statt eines leeren Blockpanels am ersten Tag.
Formulareingaben, Auswahlen, Kontrollkästchen und Buttons sind echte Komponenten, sodass eine Seite mit einem Formular immer noch ein Dokument ist.
Verwenden Sie ein Element seitenübergreifend wieder, sodass eine Änderung in einem gemeinsamen Abschnitt nicht von Hand wiederholt werden muss.
Registrieren und verwalten Sie eine benutzerdefinierte Komponentenbibliothek, ohne das Boilerplate für jeden Typ manuell zu schreiben.
Mehrseitige Projekte, wiederverwendbare Ausgangspunkte und eine Medienpipeline.
Durchstöbern Sie diese KategorieSeiten hinzufügen, umbenennen, duplizieren und exportieren – die mehrseitige Struktur, die eine von CMS unterstützte Seite benötigt.
Vorgefertigte Vorlagen, von denen deine Redakteure eine Seite starten und dann anpassen können.
MJML-Komponenten, die live im Canvas kompiliert werden, wird für die E-Mail-Vorlagen schließlich ein Content-Team anfordern.
Vermittle den Asset Manager an Cloudinary statt an den Standard-Uploader.
Das Projektdokument in etwas zu verwandeln, das ein Frontend oder ein Host bedienen kann.
Durchstöbern Sie diese KategorieKonvertiere die gespeicherten Projektdaten serverseitig in HTML und CSS, was genau der Schritt ist, den ein headless publish benötigt.
Ein Live-Accessibility Audit und ein SEO-Metadaten-Panel im Editor, wobei jeder Fund an die Komponente gebunden ist, die sie verursacht hat.
Exportiere das gesamte Projekt als Zip-Archiv für Handover, Backup oder einen statischen Host.
Deployen Sie aus dem Editor, wenn das veröffentlichte Artefakt eine Seite und kein CMS-Eintrag ist.
Fünf Startsets, die aus denselben verifizierten Angeboten stammen. Keines davon ist ein Bundle, das man mit einem Klick kauft – es sind die Kombinationen, die für jede Produktart immer wieder auftauchen.
Blöcke, Vorlagen, eine Formularkomponente und ein SEO-Panel – genug für ein Team, das Kampagnenseiten ohne Entwickler veröffentlicht.
Mehrseitige Projekte, gehosteter Speicher, autosave und wiederverwendbare Symbole – die Menge, die zählt, sobald der Editor Kunden hat.
Ein Adapter zum Lesen, Absturzwiederherstellung, Accessibility und SEO-Audit sowie serverseitige Darstellung des gespeicherten Dokuments. Genehmigungs- und Prüfspuren bleiben individuelle Arbeit.
Vorlagen, eine Medienpipeline, Export und ein Deploy-Befehl – für Seiten, die als Website statt als CMS-Eintrag enden.
Drag-and-Drop-BuilderMJML-Komponenten, gehostete Bilder und Export, für die Vorlagen, die ein Content-Team sendet, anstatt zu veröffentlichen.
E-Mail-Vorlagen-BuilderDie Preise stammen aus dem Live-Katalog zum Bauzeitpunkt. Kostenlose Angebote werden markiert.
Jede Fähigkeit auf der oben genannten Leiter ist baubar. Die Frage ist, welche sich die Zeit deines Teams wert sind, wenn es bereits eine gepflegte Erweiterung gibt.
| Alles selbst bauen | Erweiterung mit Plugins |
|---|---|
| Weitere Entwicklung | Schnellere Implementierung |
| Mehr Wartung | Wiederverwendbare Erweiterungen |
| Baue jedes Feature | Füge nur das hinzu, was du brauchst |
| Interne Werkzeuge | Fertige Lösungen |
Beginnen Sie mit dem visuellen Editor. Fügen Sie Funktionen hinzu, während Ihr Produkt wächst.
Kein Anbieter-Vergleich – ein Scope-Vergleich. Jede Zeile ist ein Subsystem, das ein visueller Editor benötigt, und die einzige Frage ist, ob dein Team es schreibt.
| Funktion | Von Grund auf | GrapesJS |
|---|---|---|
| Canvas | Selbst bauen | Enthalten |
| Drag & Drop | Selbst bauen | Enthalten |
| Komponenten | Selbst bauen | Enthalten |
| Blöcke | Selbst bauen | Erweiterbar |
| Styling | Selbst bauen | Enthalten |
| Responsive Bearbeitung | Selbst bauen | Enthalten |
| Ebenen | Selbst bauen | Enthalten |
| Assets | Selbst bauen | Erweiterbar |
| Vorlagen | Selbst bauen | Erweiterbar |
| Speicher | Selbst bauen | Erweiterbar |
| Export | Selbst bauen | Erweiterbar |
"Erweiterbar" bedeutet, dass das Subsystem existiert und einen Erweiterungspunkt besitzt – der Block-Set, die Template-Bibliothek, das Asset-Backend, das Speicherziel und das Exportformat stehen Ihnen zur Verfügung, sei es aus dem Katalog oder Ihrem eigenen Code. Katalogbehauptungen haben 2026-09-03 verifiziert.
Baue dein CMS-Produkt. Baue die visuelle Editor-Engine nicht neu auf.
Oft solltest du das tun. Ein eingebauter Editor ist bereits integriert, bereits berechtigt und bereits vertraut, und für strukturierte Inhalte ist er meist die richtige Lösung. Eine dedizierte visuelle Bearbeitungsebene verdient ihren Platz, wenn du Dinge brauchst, für die der integrierte Editor nicht gebaut wurde:
Dies ist keine Behauptung, dass eingebaute Editoren minderwertig seien. Es ist die Behauptung, dass die Bearbeitungsfläche und die Inhaltsinfrastruktur trennbare Entscheidungen sind.
Behalte dein CMS. Wähle deine eigene Bearbeitungserfahrung.
Definieren Sie Ihr Inhaltsmodell
Entscheide, was der Editor erstellen darf und in welche bestehenden Inhaltstypen er schreibt. Diese Entscheidung beschränkt alle folgenden Typen, also triff sie, bevor irgendein Editor-Code geschrieben wird.
GrapesJS konfigurieren
Richte die Komponententypen, die Blockbibliothek und die Stilkontrollen ein, die deine Editoren bekommen – und genauso wichtig, die, die sie nicht erhalten.
Speicher anbinden
Speichere das Projektdokument über REST, GraphQL oder dein eigenes API, wobei die Authentifizierung von der Sitzung übernommen wird, die dein CMS bereits ausführt.
Build-Vorschau
Rendere den Entwurf mit deinem echten Frontend, auf einer Route, die nur ein authentifizierter Prüfer erreichen kann. Alles andere ist eine Vorschau einer anderen Seite.
Veröffentlichung hinzufügen
Verknüpfe Entwurf-, Prüf- und Produktionszustände mit dem Workflow, den dein CMS bereits hat, und notiere in deiner Anwendung, wer was genehmigt hat.
Der kleinste Editor, der mit einem Content API kommuniziert. Zwei Endpunkte, eine autosave-Richtlinie und die zwei Aufrufe, die jeweils eine Darstellung bieten.
-thumbnail.jpg&w=3840&q=70)
npm install grapesjsimport grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
const editor = grapesjs.init({
container: '#editor',
height: '100vh',
// Load and save the project through your CMS API. Both endpoints are
// yours: GrapesJS only decides when to call them.
storageManager: {
type: 'remote',
autosave: true,
stepsBeforeSave: 10,
options: {
remote: {
urlLoad: '/api/cms/pages/home',
urlStore: '/api/cms/pages/home',
// Send the session the CMS already issued — never a CMS admin token
// that reached the browser.
fetchOptions: (opts) => ({ ...opts, credentials: 'include' }),
},
},
},
});
// The two representations, whenever you need them.
const project = editor.getProjectData(); // re-openable source
const output = { html: editor.getHtml(), css: editor.getCss() };Schicke die Sitzung mit, die dein CMS ohnehin ausgestellt hat. Ein CMS-Admin-Token, das den Browser erreicht, ist ein CMS-Admin-Token, das deine Besucher haben.
GrapesJS ist egal, ob das andere Ende REST, GraphQL oder etwas von deinem Team ist. Ein Speicheradapter ist eine Last- und eine Speicherfunktion, und alles darunter ist eine Entscheidung, die du darin triffst.
Was der Adapter abdecken muss
Holen Sie das gespeicherte Dokument auf einer Seite ab und geben Sie es beim Start an den Editor.
Schreib es zurück, idealerweise als Aktualisierung eines Entwurfs statt des veröffentlichten Eintrags.
Spare bei einer Änderungszahl oder einem Timer und sorge dafür, dass der Endpunkt häufig aufgerufen wird.
Laden Sie über Ihre Medienpipeline hoch und geben Sie die URL zurück, die der Asset Manager anzeigen sollte.
Zeigen Sie den Entwurf Ihrem Frontend hinter einem Token und niemandem sonst.
Ein separater, autorisierter Endpunkt. Nie derselbe Anruf wie ein Speichermodus.
// A storage adapter is just two functions, so GraphQL needs no extra plugin.
editor.Storage.add('cms', {
async load() {
const res = await gql(`query Page($id: ID!) { page(id: $id) { project } }`);
return res.page.project;
},
async store(data) {
await gql(`mutation Save($id: ID!, $project: JSON!) {
updatePage(id: $id, data: { project: $project }) { id }
}`, { project: data });
},
});Kein GraphQL-Adapterpaket ist auf GJS.Market veröffentlicht – der obige Ausschnitt zeigt die gesamte Integration, weshalb keine benötigt wird.
Zwei Funktionen sind der gesamte Vertrag zwischen einem visuellen Editor und einer Content-API.
Die Liste, die ein Team zwischen einem funktionierenden Prototyp und etwas durcharbeitet, das Kunden berühren. Nichts hier ist exotisch; alles wird mindestens einmal übersprungen.
Ein visueller Editor ist ein Schreibpfad in Ihre Inhaltsinfrastruktur, also erbt er jede Regel, die dieser Pfad bereits hatte – und fügt Datei-Uploads sowie beliebige Markups auf die Oberfläche hinzu.
Jedes Laden, Speichern, Hochladen und Veröffentlichen wird mit der Sitzung für diese spezielle Seite auf dem Server abgeglichen.
Umfang nach Tenant in der Datenbankabfrage selbst. Ein nach dem Lesen angewendeter Filter ist keine Isolation.
Der Editor verwendet die Sitzung, die dein CMS ausgegeben hat. Kein Management- oder Admin-Token gehört in den Browsercode.
Überprüfe Typ, Größe und Zielperson serverseitig und bereitstelle Benutzermedien von einem separaten Ursprung aus, wo möglich.
Redakteure können eigenen Code einfügen. Entscheiden Sie bewusst, wer es darf, und bereinigen Sie, was den Besuchern angezeigt wird.
Ein separater Endpunkt mit eigener Berechtigungsprüfung, daher ist das Bearbeiten nicht dasselbe wie das Veröffentlichen.
Verlassen Sie sich niemals nur auf clientseitige Berechtigungen. Das Verstecken eines Panels ist eine Entscheidung der Benutzeroberfläche, keine Sicherheitskontrolle.
Die Editor-Laufzeit ist ein Entwicklerwerkzeug und gehört ausschließlich zum Bearbeiten. Fast jedes Leistungsproblem in dieser Architektur entsteht dadurch, dass es in die Seiten einfließt, die Besucher laden.
Importiere es über die Bearbeitungsroute. Nichts an einer besucherorientierten Seite benötigt das Bearbeitungspaket.
Eine Medienbibliothek wächst unbegrenzt. Paginieren und durchsuchen Sie sie serverseitig, anstatt sie komplett zu laden.
Jedes Plugin registriert Komponenten, Befehle und Panels beim Start. Ungenutzte Plugins kosten bei jeder Öffnung Zeit.
Veröffentlichte Ausgaben sollten Markup und Stile von deinem Frontend gerendert werden, ohne dass Editor-Code ausgeliefert wird.
Der Delivery-API kann schwer zwischengespeichert werden; der entwurf, der hinter der Vorschau gelesen wird, kann das meist nicht. Behandle sie getrennt.
Hier werden keine Zeitangaben genannt, da für diese Seite keine gemessen wurden. Missen Sie Ihren eigenen Editor mit Ihrem eigenen Block-Set – die Blockbibliothek und die Asset-Anzahl dominieren die Zahlen.
Fünf wiederkehrende Muster. Sie stellen unterschiedliche Fragen an dieselbe Architektur, und zu jedem gibt es hier eine Seite, die seine eigenen beantwortet.
Visuelle Bearbeitung zu einem Produkt hinzuzufügen, das bereits Kunden, Konten und Abrechnungen hat.
SaaS-Seiten-BuilderWir bieten Kunden ein besseres Bearbeitungserlebnis zusätzlich zu einem bestehenden Inhalt, API.
White-Label-BuilderIch baue eine individuelle Bearbeitungsumgebung pro Client, auf dem CMS, das dieser Client bereits läuft.
ImplementierungsdiensteMarketer können Seiten ohne Entwickler innerhalb einer kontrollierten Blockbibliothek erstellen.
Landingpage-BuilderKontrollierte Veröffentlichungs-Workflows zu erstellen, bei denen wer was genehmigt hat, verantwortlich sein muss.
Eingebettete EditorenDienstleistungen
Brauchst du Hilfe, GrapesJS an Strapi, Contentful, Sanity, Directus, Payload oder ein eigenes CMS anzubinden? Wir helfen bei Editor-Integration, eigenen Komponenten, Speicher, Plugins und den Produktionsabläufen drumherum.
Behalte dein bestehendes CMS, dein Inhaltsmodell und deine Frontend-Architektur. Füge GrapesJS als visuelle Bearbeitungsebene hinzu und erweitere es dann mit GJS.Market-Plugins, sobald dein Produkt wächst.
Erzählen Sie uns von CMS, dem Content-Modell und den Seiten, die Ihr Team erstellen muss, und erhalten Sie eine strukturierte Einrichtung zurück.
Leg losSpeicher, Blöcke, Vorlagen, Assets, Formulare, SEO, Export und Veröffentlichen – die Sprossen, die du nicht schreiben musst.
Plugins durchsuchenIntegration, individuelle Komponenten, Speicheradapter und der Produktionsablauf darum herum.
Holen Sie sich ImplementierungshilfeDein CMS. Dein Frontend. Dein Editor.