En innholdsansvarlig logger inn i administrasjonspanelet, finner en side blant 50 andre, åpner redigeringsverktøyet, retter en overskrift, lagrer, går tilbake til nettstedet og oppdaterer fanen. Seks klikk for én redigering. For Grav CMS finnes det en enkel løsning: utvidelsen Editable with ContentTools bygger inn en WYSIWYG-redigerer direkte på nettsiden. Du åpner siden, klikker «rediger», retter teksten og lagrer den tilbake til en Markdown-fil uten å gå inn i administrasjonspanelet.

Utvidelsen har ikke blitt oppdatert siden 2022 (forfatteren har offisielt avsluttet støtten), men den kjører stabilt på Grav 1.7 og dekker grunnscenarioet med redigering av enkle Markdown-sider uten dynamisk logikk. Installasjonen tar fem minutter, og etter det blir tekstredigering på frontend mye enklere.

Nedenfor følger en komplett guide fra installasjon til tilgangsrettigheter, med en gjennomgang av begrensninger og et alternativ (Fred).

💡 Hurtigoversikt:

• Installer utvidelsen via GPM eller et zip-arkiv og kopier konfigurasjonen.
• Sett opp git-sync for å committe endringer til et repository (valgfritt).
• Merk redigerbare områder med editable shortcode ved hjelp av unike navn.
• Gi site.editable-rettigheter til frontend-brukere.
• Slå sammen admin- og frontend-økter via session.split: false.
• Vær oppmerksom på begrensningen: kun ren Markdown, ingen Twig eller dynamisk innhold.

Installasjon: via GPM eller manuelt

Utvidelsen installeres gjennom Grav Package Manager, standardmetoden for alle tillegg i Grav:

1
bin/gpm install editable-contenttools

Kjør kommandoen fra nettstedets rotmappe (der bin/ ligger). GPM laster ned siste versjon og pakker den ut til /user/plugins/editable-contenttools.

Alternativt kan du installere manuelt: last ned zip-arkivet fra GitHub, pakk det ut til /user/plugins/, og gi mappen navnet editable-contenttools (uten endelsen -master). Strukturen skal se slik ut: /user/plugins/editable-contenttools/editable-contenttools.php.

Kopier konfigurasjonen til et trygt sted

Etter installasjon må du kopiere konfigurasjonsfilen til brukerkatalogen:

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

Dette steget er viktig: hvis innstillingene forblir i utvidelsesmappen, blir de tilbakestilt når du oppdaterer via GPM. En alternativ tilnærming er å installere gjennom Grav Admin-panelet (Utvidelser → Legg til), og da oppretter systemet automatisk konfigurasjonen i user/config/plugins/, og manuell kopiering er ikke nødvendig.

Konfigurasjon: tre konfigurasjonsvalg

Filen editable-contenttools.yaml inneholder tre parametere:

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

enabled aktiverer utvidelsen. Uten enabled: true vil ikke redigeringsverktøyet vises på frontend, selv om rettigheter er gitt. Standardverdien er true.

git-sync utløser synkronisering med et Git-repository etter hver lagring. Det fungerer bare når utvidelsen Git Sync er installert. Hvis nettstedet ditt lever i Git og du ønsker å registrere hver endring i historikken, sett denne til true. Ellers lar du den stå som false.

git-sync-mode bestemmer om systemet skal vente på at synkroniseringen fullføres før kontrollen returneres til brukeren. foreground betyr at «Lagre»-knappen låses opp først etter at commit og push er ferdig. background jobber asynkront, men enkelte Linux-servere kan ha problemer med bakgrunnsprosesser. For de fleste scenarioer er foreground tilstrekkelig.

Merking av redigerbare områder: shortcoden [editable]

Utvidelsen gjør ikke hele siden redigerbar automatisk. Du definerer hvilke blokker som kan redigeres ved hjelp av shortcoden [editable]:

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

En side kan inneholde et vilkårlig antall slike områder. Hvert område må ha et unikt navn, ellers vil ikke ContentTools vite hvor endringer skal lagres.

Navn-parameteren: obligatorisk unikhet

Som standard tildeler utvidelsen navn automatisk (region-0, region-1 og så videre), men det er bedre å spesifisere meningsfulle navn manuelt:

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

Ved første lagring via frontend legger plugin-en automatisk til en name-parameter i shortcoden hvis den mangler. I praksis er det enklere å angi navn med en gang under oppmerking, siden dette forenkler feilsøking (du kan se hvilken blokk du redigerer i nettleserens utviklerverktøy).

Etter at du har merket opp og lagret siden, besøk nettstedet som en bruker med site.editable-rettigheten, klikk på blyantikonet til venstre og rediger tekst som i et vanlig tekstredigeringsprogram. Hold inne Shift i omtrent tre sekunder for å utheve alle redigerbare områder.

Du kan prøve det på plugin-ens demoside (lagring er deaktivert, Grav 1.7.46).

Tilgangsrettigheter: frontend og backend

For at en bruker skal se blyantikonet, trenger de redigeringstillatelser. Reglene er forskjellige for frontend-brukere (innholdsforvaltere) og backend-brukere (administratorer).

Frontend-brukere

En bruker må kunne logge inn via Grav Login-plugin-en eller Private Grav. Legg deretter til følgende i kontofilen (user/accounts/username.yaml):

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

Uten site.editable-rettigheten vil ikke blyantikonet vises, selv om brukeren er logget inn og har andre rettigheter.

Backend-brukere (administratorer)

Som standard holder Grav admin- og frontend-økter atskilt. For å tillate at en administrator redigerer sider direkte på nettstedet (uten å gå inn i adminpanelet), sett følgende i system.yaml (eller via adminpanelet Konfigurasjon → System):

1
session:
2
  split: false

Dette slår sammen økter: innlogging i adminpanelet vil automatisk gi tilgang til frontend-redigeringsverktøyet. Administratoren vil også trenge admin.super- eller admin.pages-rettigheten i kontofilen sin.

Hvis ikonet ikke vises etter innlogging, sjekk admininnstillingene for mellomlagring:

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

Parameteren cache: false deaktiverer mellomlagring for admin og kan løse problemet med det usynlige ikonet.

Begrensninger: hva plugin-en ikke kan gjøre

Plugin-en fungerer utelukkende med ren Markdown. Dette er en arkitektonisk begrensning, ikke en feil: ContentTools redigerer HTML i nettleseren, og plugin-en konverterer HTML tilbake til Markdown. I denne prosessen vil all dynamisk oppmerking bli ødelagt. Ikke rediger innhold via ContentTools hvis det:

• settes sammen av Twig-maler (for eksempel modulære sider: underordnede blokker settes inn av den overordnede dynamisk, og plugin-en kan ikke se kilden deres);
• injiseres av andre plugin-er (Page Inject og lignende plugin-er setter inn innhold fra andre sider, noe som er en enveisprosess);
• endres via JavaScript i nettleseren (glidere, trekkspillmenyer og andre interaktive elementer vil bli konvertert til statisk HTML);
• inneholder spesialtagger for Grav Markdown (bilder med ?lightbox- og ?resize-parametere vil bli skadet under HTML → Markdown-konvertering, ettersom prosesseringsparametere vil forsvinne).

Sikkerhetsreglene er enkle:

• Hold bilder og komplekse shortcoder utenfor redigerbare områder.
• Hold områdene små: antallet er ubegrenset, og 10 små blokker er bedre enn én stor blokk med risiko.
• Test på en kopi av innlegget eller i et testmiljø før du gir tilgang til redaktører.
• Hvis du oppdager forskjeller i Markdown-formatering mellom versjonen med blyantikonet og versjonen uten, flytt det fragmentet utenfor [editable].

Alternativ: Fred-utvidelsen

Hvis funksjonaliteten til Editable med ContentTools ikke er nok, ta en titt på Fred, en nyere frontend-editor for Grav som også er basert på ContentTools. Viktige forskjeller:

• Bildeopplasting via en dialog (med rotering og enkel bildebehandling).
• Auto-innpakning av innhold gjennom onPageProcessed-hendelsen, noe som krever mindre manuell shortcode-markering.
• Aktiv utvikling: forfatteren aksepterer issues på GitHub og fortsetter å legge til funksjoner.

Installasjon ved å klone repositoriet til /user/plugins/fred:

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

Rettigheter settes på lignende måte: site.editor: true i brukerkontofilen (merk: site.editor, ikke site.editable).

Både Editable med ContentTools og Fred løser det samme problemet: de gir innholdsforvaltere et verktøy for raske redigeringer uten å gå inn i administrasjonspanelet. Den første passer hvis du trenger et enkelt, utprøvd verktøy for Markdown-sider uten eksperimenter. Den andre fungerer hvis du ønsker mer automatisering og er forberedt på potensielle barnesykdommer ved aktiv utvikling.

Video: slik fungerer ContentTools

En to minutters demonstrasjon av redigering av en Grav-side i nettleseren: forfatteren viser hvordan redigerbare områder utheves, endringer gjøres og innhold lagres tilbake til Markdown. En god måte å se utvidelsen i aksjon før installasjon.

⁉️🤔 Ofte stilte spørsmål

Hvorfor vises ikke blyantikonet etter installasjon?

Sjekk fire ting. For det første, enabled: true i utvidelseskonfigurasjonen (user/config/plugins/editable-contenttools.yaml). For det andre må brukeren ha site.editable-rettigheten i kontofilen sin. For det tredje, for backend-brukere må session.split være false i system.yaml. For det fjerde, tøm Grav-mellomlageret: bin/grav clear-cache. Vanligvis er problemet enten rettigheter eller delte sesjoner.

Kan jeg redigere modulære sider?

Nei. Modulære sider settes sammen av undersider via Twig-maler, som er en enveisprosess: utvidelsen kan ikke «demontere» resultatet tilbake til deler. På frontenden ser du den ferdige HTML-en, men kilden (separate Markdown-filer for barnemoduler) ligger i andre mapper, og utvidelsen vet ikke hvor den skal lagre endringer. For modulære sider, bruk standard administrasjonsgrensesnitt for Grav.

Hva skjer hvis jeg lar et bilde ligge inni [editable]?

Gravs spesialtagger for bilder i Markdown (med parametrene ?lightbox, ?resize, ?cropResize) vil bli ødelagt under konvertering fra HTML til Markdown. Selve bildet forblir på plass (<img>-taggen konverteres til vanlig Markdown ![](url)), men behandlingsparametrene vil forsvinne. Konklusjon: hold alltid bilder med parametere utenfor det redigerbare området. Hvis et bilde er enkelt (uten parametere), kan du teknisk sett la det ligge inni, men i praksis er det tryggere å flytte alle mediefiler utenfor [editable].

Utvidelsen er forlatt av forfatteren. Er den trygg å bruke?

Forfatteren kunngjorde offisielt slutten på støtte i 2022, og siste commit er datert august 2024 (en kompatibilitetsoppdatering for Grav 1.7). Utvidelsen er stabil på Grav 1.7 og påvirker ikke sikkerhetskritiske komponenter: den jobber kun med Markdown-innhold og har ingen tilgang til serveroperasjoner. Hvis du planlegger en overgang til Grav 2.0, bør du vurdere å se på Fred eller vente på en offisiell løsning for frontend-redigering (nye tilnærminger basert på TinyMCE og Prosemirror blir diskutert på forumet).

Hva er forskjellen mellom Editable med SimpleMDE og ContentTools-versjonen?

Editable med SimpleMDE bruker samme tilnærming (frontend-redigering), men i stedet for en visuell editor tilbyr den SimpleMDE Markdown-editor med live forhåndsvisning. Den passer for dem som foretrekker å skrive markering for hånd og ønsker å se resultatet til høyre for editoren i stedet for i WYSIWYG-modus. Begge utvidelsene er fra samme forfatter (bleutzinn) og begge har vært forlatt siden 2022.

Er det verdt å installere en frontend-editor for Grav i 2026

Hvis nettstedet ditt kjører på Grav 1.7, består av enkle Markdown-sider, og innholdsforvalterne er lei av å gå inn i administrasjonspanelet for et par redigeringer, installer Editable med ContentTools. Fem minutter for installasjon, minimal konfigurasjon, og redigering blir en ettklikksoperasjon. Åpne siden, klikk på blyanten, fiks teksten, lagre. Ingen leting gjennom sidelister, ingen bytting av faner.

For nye prosjekter eller når du planlegger en overgang til Grav 2.0 (en lansering er ventet i 2026, men det finnes ingen eksakt dato), vurder Fred: den er mer aktivt utviklet og har større sannsynlighet for å få kompatibilitet med den andre versjonen av CMS-et. Uansett sparer frontend-redigering dusinvis av klikk og minutter med tid på hver redigering, noe som er spesielt merkbart på nettsteder med hyppige innholdsoppdateringer. Prøv det i et testmiljø og avgjør hvor mye denne tilnærmingen setter fart på arbeidsflyten din.