Ein Content-Manager meldet sich im Admin-Panel an, sucht eine Seite unter 50 anderen heraus, öffnet den Editor, korrigiert eine Überschrift, speichert, kehrt zur Website zurück und aktualisiert den Tab. Sechs Klicks für eine Bearbeitung. Für Grav CMS gibt es eine einfache Lösung: Das Plugin Editable with ContentTools bettet einen WYSIWYG-Editor direkt auf der Website-Seite ein. Sie öffnen die Seite, klicken auf „Bearbeiten", korrigieren den Text und speichern ihn zurück in eine Markdown-Datei, ohne das Admin-Panel aufzurufen.

Das Plugin wurde seit 2022 nicht mehr aktualisiert (der Autor hat den Support offiziell eingestellt), läuft aber stabil unter Grav 1.7 und deckt das Basisszenario der Bearbeitung einfacher Markdown-Seiten ohne dynamische Logik ab. Die Installation dauert fünf Minuten, und danach wird die Textbearbeitung im Frontend deutlich einfacher.

Nachfolgend eine vollständige Anleitung von der Installation bis zu den Zugriffsrechten, mit einer Aufschlüsselung der Einschränkungen und einer Alternative (Fred).

💡 Kurzüberblick:

• Installieren Sie das Plugin via GPM oder als Zip-Archiv und kopieren Sie die Konfiguration.
• Richten Sie Git-Sync ein, um Änderungen in ein Repository zu übertragen (optional).
• Markieren Sie bearbeitbare Bereiche mit dem editable-Shortcode unter Verwendung eindeutiger Namen.
• Gewähren Sie Frontend-Benutzern die site.editable-Berechtigungen.
• Führen Sie Admin- und Frontend-Sitzungen über session.split: false zusammen.
• Beachten Sie die Einschränkung: nur reines Markdown, kein Twig oder dynamischer Inhalt.

Installation: via GPM oder manuell

Das Plugin wird über den Grav Package Manager installiert, die Standardmethode für jedes Add-on in Grav:

1
bin/gpm install editable-contenttools

Führen Sie den Befehl aus dem Stammverzeichnis der Website aus (dort, wo sich bin/ befindet). GPM lädt die neueste Version herunter und entpackt sie nach /user/plugins/editable-contenttools.

Alternativ können Sie manuell installieren: Laden Sie das Zip-Archiv von GitHub herunter, entpacken Sie es nach /user/plugins/ und benennen Sie den Ordner in editable-contenttools um (ohne den Suffix -master). Die Struktur sollte so aussehen: /user/plugins/editable-contenttools/editable-contenttools.php.

Kopieren Sie die Konfiguration an einen sicheren Ort

Achten Sie darauf, die Konfigurationsdatei nach der Installation in das Benutzerverzeichnis zu kopieren:

1
cp user/plugins/editable-contenttools/editable-contenttools.yaml user/config/plugins/editable-contenttools.yaml

Dieser Schritt ist wichtig: Verbleiben die Einstellungen im Plugin-Ordner, werden sie bei einem Update via GPM zurückgesetzt. Ein alternativer Ansatz ist die Installation über das Grav-Admin-Panel (Plugins → Hinzufügen); in diesem Fall legt das System die Konfiguration automatisch in user/config/plugins/ an, und ein manuelles Kopieren entfällt.

Konfiguration: drei Konfigurationsoptionen

Die Datei editable-contenttools.yaml enthält drei Parameter:

1
enabled: true
2
git-sync: false
3
git-sync-mode: foreground

enabled aktiviert das Plugin. Ohne enabled: true erscheint der Editor nicht im Frontend, selbst wenn Berechtigungen erteilt wurden. Der Standardwert ist true.

git-sync löst nach jedem Speichern eine Synchronisation mit einem Git-Repository aus. Dies funktioniert nur, wenn das Git Sync-Plugin installiert ist. Wenn Ihre Website in Git lebt und Sie jede Änderung in der Historie festhalten möchten, setzen Sie dies auf true. Andernfalls belassen Sie es bei false.

git-sync-mode legt fest, ob auf den Abschluss der Synchronisation gewartet wird, bevor die Kontrolle an den Benutzer zurückgegeben wird. foreground bedeutet, dass die Schaltfläche „Speichern" erst nach Abschluss von Commit und Push entsperrt wird. background arbeitet asynchron, allerdings kann es auf manchen Linux-Servern zu Problemen mit Hintergrundprozessen kommen. Für die meisten Szenarien ist foreground ausreichend.

Bearbeitbare Bereiche markieren: der [editable]-Shortcode

Das Plugin macht nicht automatisch die gesamte Seite bearbeitbar. Sie legen fest, welche Blöcke bearbeitet werden können, indem Sie den [editable]-Shortcode verwenden:

1
[editable]
2
## Section heading
3
 
4
Text that can be edited from the frontend.
5
[/editable]

Eine Seite kann beliebig viele solcher Bereiche enthalten. Jeder Bereich muss einen eindeutigen Namen haben; andernfalls weiß ContentTools nicht, wohin Änderungen gespeichert werden sollen.

Der Name-Parameter: obligatorische Eindeutigkeit

Standardmäßig vergibt das Plugin automatisch Namen (region-0, region-1 usw.), aber es ist besser, aussagekräftige Namen manuell zu vergeben:

1
[editable name="hero-block"]
2
## Main heading
3
 
4
Text that can be edited.
5
[/editable]

Beim ersten Speichern über das Frontend fügt das Plugin automatisch einen name-Parameter zum Shortcode hinzu, falls dieser fehlt. In der Praxis ist es einfacher, die Namen bereits beim Markup direkt anzugeben, da dies die Fehlersuche vereinfacht (Sie können in den Entwicklertools des Browsers sehen, welchen Block Sie gerade bearbeiten).

Nachdem Sie die Seite mit Markup versehen und gespeichert haben, besuchen Sie die Website als Benutzer mit der Berechtigung site.editable, klicken Sie auf das Stiftsymbol links und bearbeiten Sie den Text wie in einem normalen Texteditor. Halten Sie die Umschalttaste etwa drei Sekunden lang gedrückt, um alle bearbeitbaren Bereiche hervorzuheben.

Sie können es auf der Plugin-Demoseite ausprobieren (Speichern deaktiviert, Grav 1.7.46).

Zugriffsrechte: Frontend und Backend

Damit ein Benutzer das Stiftsymbol sieht, benötigt er Bearbeitungsrechte. Die Regeln unterscheiden sich für Frontend-Benutzer (Content-Manager) und Backend-Benutzer (Administratoren).

Frontend-Benutzer

Ein Benutzer muss sich über das Grav Login-Plugin oder Private Grav anmelden können. Fügen Sie dann Folgendes zur Kontodatei (user/accounts/username.yaml) hinzu:

1
access:
2
  site:
3
    login: 'true'
4
    editable: 'true'

Ohne die Berechtigung site.editable erscheint das Stiftsymbol nicht, selbst wenn der Benutzer angemeldet ist und andere Rechte besitzt.

Backend-Benutzer (Administratoren)

Standardmäßig trennt Grav Admin- und Frontend-Sitzungen. Damit ein Administrator Seiten direkt auf der Website bearbeiten kann (ohne das Admin-Panel aufzurufen), nehmen Sie folgende Einstellung in system.yaml vor (oder über das Admin-Panel Konfiguration → System):

1
session:
2
  split: false

Dadurch werden die Sitzungen zusammengeführt: Die Anmeldung im Admin-Panel gewährt automatisch Zugriff auf den Frontend-Editor. Der Administrator benötigt zudem die Berechtigung admin.super oder admin.pages in seiner Kontodatei.

Wenn das Symbol nach der Anmeldung nicht erscheint, überprüfen Sie die Admin-Einstellungen für das Caching:

1
admin:
2
  super: 'true'
3
  login: 'true'
4
  cache: 'false'

Der Parameter cache: false deaktiviert das Caching für den Admin und kann das Problem mit dem unsichtbaren Symbol beheben.

Einschränkungen: Was das Plugin nicht kann

Das Plugin arbeitet ausschließlich mit reinem Markdown. Dies ist eine architekturbedingte Einschränkung, kein Fehler: ContentTools bearbeitet HTML im Browser, und das Plugin konvertiert HTML zurück in Markdown. Dabei wird jegliches dynamisches Markup beschädigt. Bearbeiten Sie Inhalte nicht über ContentTools, wenn sie:

• durch Twig-Templates zusammengesetzt werden (z. B. modulare Seiten: Kindblöcke werden dynamisch vom übergeordneten Element eingefügt, und das Plugin kann deren Quelle nicht sehen);
• von anderen Plugins eingefügt werden (Page Inject und ähnliche Plugins fügen Inhalte aus anderen Seiten ein, was ein einseitiger Prozess ist);
• sich per JavaScript im Browser verändern (Slider, Akkordeons und andere interaktive Elemente werden in statisches HTML konvertiert);
• Grav-Markdown-Spezialtags enthalten (Bilder mit den Parametern ?lightbox und ?resize werden bei der HTML-zu-Markdown-Konvertierung beschädigt, da Verarbeitungsparameter verloren gehen).

Die Sicherheitsregeln sind einfach:

• Halten Sie Bilder und komplexe Shortcodes außerhalb bearbeitbarer Bereiche.
• Halten Sie Bereiche klein: Die Anzahl ist unbegrenzt, und 10 kleine Blöcke sind besser als ein großer Block mit Risiken.
• Testen Sie auf einer Kopie des Beitrags oder in einer Staging-Umgebung, bevor Sie Redakteuren Zugriff gewähren.
• Wenn Sie Unterschiede in der Markdown-Formatierung zwischen der Version mit Stiftsymbol und der Version ohne feststellen, verschieben Sie dieses Fragment aus dem [editable]-Bereich heraus.

Alternative: das Fred-Plugin

Wenn die Funktionalität von Editable with ContentTools nicht ausreicht, werfen Sie einen Blick auf Fred, einen neueren Frontend-Editor für Grav, der ebenfalls auf ContentTools basiert. Wesentliche Unterschiede:

• Bild-Upload über einen Dialog (mit Rotation und grundlegender Bearbeitung).
• Automatisches Umhüllen von Inhalten durch das onPageProcessed-Ereignis, wodurch weniger manuelles Shortcode-Markup erforderlich ist.
• Aktive Entwicklung: Der Autor nimmt Issues auf GitHub entgegen und fügt kontinuierlich Funktionen hinzu.

Installation durch Klonen des Repositorys nach /user/plugins/fred:

1
cd user/plugins
2
git clone https://github.com/BugHunter2k/grav-plugin-fred.git fred

Die Berechtigungen werden ähnlich gesetzt: site.editor: true in der Benutzerkontodatei (beachten Sie: site.editor, nicht site.editable).

Sowohl Editable with ContentTools als auch Fred lösen dasselbe Problem: Sie geben Content-Managern ein Werkzeug für schnelle Bearbeitungen an die Hand, ohne das Admin-Panel aufrufen zu müssen. Ersteres eignet sich, wenn Sie ein einfaches, bewährtes Werkzeug für Markdown-Seiten ohne Experimente benötigen. Letzteres funktioniert, wenn Sie mehr Automatisierung wünschen und auf die potenziellen Ecken und Kanten einer aktiven Entwicklung vorbereitet sind.

Video: So funktioniert ContentTools

Eine zweiminütige Demonstration der Bearbeitung einer Grav-Seite im Browser: Der Autor zeigt, wie bearbeitbare Bereiche hervorgehoben, Änderungen vorgenommen und Inhalte zurück in Markdown gespeichert werden. Eine gute Möglichkeit, das Plugin vor der Installation in Aktion zu sehen.

⁉️🤔 Häufig gestellte Fragen

Warum erscheint das Stiftsymbol nach der Installation nicht?

Prüfen Sie vier Dinge. Erstens: enabled: true in der Plugin-Konfiguration (user/config/plugins/editable-contenttools.yaml). Zweitens: Der Benutzer muss die Berechtigung site.editable in seiner Kontodatei haben. Drittens: Für Backend-Benutzer muss session.split in der system.yaml auf false stehen. Viertens: Leeren Sie den Grav-Cache: bin/grav clear-cache. Meist liegt das Problem entweder an den Berechtigungen oder an geteilten Sessions.

Kann ich modulare Seiten bearbeiten?

Nein. Modulare Seiten werden aus Unterseiten über Twig-Templates zusammengesetzt, was ein einseitiger Prozess ist: Das Plugin kann das Ergebnis nicht wieder in seine Bestandteile „zerlegen". Im Frontend sehen Sie das fertige HTML, aber die Quelle (separate Markdown-Dateien der Kindmodule) befindet sich in anderen Ordnern, und das Plugin weiß nicht, wohin es Änderungen speichern soll. Verwenden Sie für modulare Seiten die Standard-Admin-Oberfläche von Grav.

Was passiert, wenn ich ein Bild innerhalb von [editable] belasse?

Spezielle Grav-Markdown-Tags für Bilder (mit den Parametern ?lightbox, ?resize, ?cropResize) werden bei der HTML-zu-Markdown-Konvertierung beschädigt. Das Bild selbst bleibt an Ort und Stelle (der <img>-Tag wird zu regulärem Markdown ![](url) konvertiert), aber die Verarbeitungsparameter gehen verloren. Fazit: Halten Sie Bilder mit Parametern immer außerhalb des bearbeitbaren Bereichs. Wenn ein Bild einfach ist (ohne Parameter), können Sie es technisch gesehen drin lassen, aber in der Praxis ist es sicherer, alle Medien außerhalb von [editable] zu platzieren.

Das Plugin wurde vom Autor aufgegeben. Ist die Nutzung sicher?

Der Autor hat das Ende der Unterstützung 2022 offiziell angekündigt, und der letzte Commit datiert vom August 2024 (ein Kompatibilitätsupdate für Grav 1.7). Das Plugin läuft stabil unter Grav 1.7 und beeinträchtigt keine sicherheitskritischen Komponenten: Es arbeitet nur mit Markdown-Inhalten und hat keinen Zugriff auf Serveroperationen. Wenn Sie einen Umstieg auf Grav 2.0 planen, sollten Sie Fred in Betracht ziehen oder auf eine offizielle Frontend-Editing-Lösung warten (neue Ansätze auf Basis von TinyMCE und Prosemirror werden im Forum diskutiert).

Was ist der Unterschied zwischen Editable with SimpleMDE und der ContentTools-Version?

Editable with SimpleMDE verwendet denselben Ansatz (Frontend-Editing), stellt aber anstelle eines visuellen Editors den SimpleMDE-Markdown-Editor mit Live-Vorschau bereit. Das eignet sich für diejenigen, die Markup lieber von Hand schreiben und das Ergebnis rechts neben dem Editor sehen möchten, statt im WYSIWYG-Modus. Beide Plugins stammen vom selben Autor (bleutzinn) und wurden beide seit 2022 nicht mehr weiterentwickelt.

Lohnt sich die Installation eines Frontend-Editors für Grav im Jahr 2026

Wenn Ihre Seite auf Grav 1.7 läuft, aus einfachen Markdown-Seiten besteht und die Content-Manager es leid sind, für ein paar Bearbeitungen das Admin-Panel aufzurufen, installieren Sie Editable with ContentTools. Fünf Minuten für die Installation, minimale Konfiguration, und die Bearbeitung wird zu einer Ein-Klick-Operation. Seite öffnen, auf den Stift klicken, Text korrigieren, speichern. Kein Suchen in Seitenlisten, kein Wechseln zwischen Tabs.

Für neue Projekte oder wenn Sie einen Umstieg auf Grav 2.0 planen (eine Veröffentlichung wird 2026 erwartet, ein genaues Datum gibt es jedoch nicht), ziehen Sie Fred in Betracht: Es wird aktiver entwickelt und erhält mit höherer Wahrscheinlichkeit Kompatibilität mit der zweiten Version des CMS. In jedem Fall spart Frontend-Editing Dutzende Klicks und Minuten Zeit bei jeder Bearbeitung, was sich besonders bei Seiten mit häufigen Inhaltsaktualisierungen bemerkbar macht. Testen Sie es in einer Testumgebung und entscheiden Sie, wie sehr dieser Ansatz Ihren Arbeitsablauf beschleunigt.