Uppdatering av Grav och plugins

Rutinen steg för steg: före, i ordning, prov mellan stegen, driftsättning och att backa.

Grav och plugins uppdateras aldrig i drift. De uppdateras lokalt, på en egen gren, provas och driftsätts som vilken ändring som helst.

  • Kvartalsvis, samlat.
  • Säkerhetsuppdateringar direkt, särskilt för login, api och form. Samma rutin, men bara för det som behöver uppdateras.
  • Admin installerar och uppdaterar ingenting när spärren är på. Knapparna Install, Update, Update All, Upgrade Grav och Direct Install i Admin svarar då med ett fel som hänvisar hit, också för en super-admin. Admin visar ändå vilka uppdateringar som finns. Spärren slås på i Admin2 på grundsajten → Plugins → Subsites → No installs or updates through Admin. Den är av från början.

Alla kommandon körs från webbroten, utom bin/setup och bin/smoke, som körs från repots rot.

Före

  1. Röktesterna är gröna på den version som körs nu: bin/smoke. Ett test som redan är rött gör det omöjligt att se vad uppdateringen bröt.
  2. En egen gren, till exempel uppdatering-2026-q4.
  3. En tagg på det som körs i drift, till exempel git tag fore-uppdatering-2026-q4. Det är punkten att backa till.
  4. En säkerhetskopia av det i user/ som inte ligger i git: kontona (user/accounts/), user/data/ och innehållet om det inte ligger i git (sidan Säkerhetskopiering).

Grav och Gravs plugin ligger inte i repot. Repots fil versions.lock säger vilka versioner som gäller, och bin/setup hämtar dem.

  1. Se vad som finns att uppdatera: php bin/gpm version grav api login form email admin2 och övriga plugins. Raden säger upgradable eller updatable och vilken version.

Ett steg i taget, i ordning

Uppdatera i den här ordningen, så att det syns vad som bröt. Pluginen kommer före Grav-kärnan. Ett plugin kommer efter dem det beror på.

  1. form, sedan email. email beror på form.
  2. login. Det beror på form och email.
  3. api och admin2, som ett steg: först api, direkt efter admin2, sedan röktesterna. Admin2 är byggt mot en viss version av api. Med bara det ena uppdaterat kan proven i webbläsaren falla av sig själva efter en stund.
  4. Övriga plugins: flex-objects, shortcode-core, github-markdown-alerts, tntsearch, error, problems.
  5. Grav-kärnan.

Temat och pluginen subsites, mail-auth och mcp hör till installationen och uppdateras inte med gpm update. De följer med repot, eller med nya paket på en installation byggd med paket (sidan Installation).

För varje steg:

  1. Läs changelogen mot listorna över vad installationen använder:

    • temat: DEPENDENCIES.md i temamappen;
    • pluginen subsites, mail-auth och mcp: avsnittet Dependencies on Grav and other plugins i deras README.md.

    En rad i changelogen som rör något i listorna provas särskilt.

  2. Ändra versionen i versions.lock, och uppdatera DEPENDENCIES.md i temamappen.
  3. Hämta den: bin/setup. Skriptet tömmer också cachen.
  4. Kör röktesterna: bin/smoke.
  5. Checka in steget för sig, med versionerna i meddelandet, till exempel "Uppdatera email 5.2.1 → 5.3.1". Ett steg per commit gör att ett enskilt steg kan backas.

Faller ett test: läs vad som väntades, jämför med changelogen och rätta eller backa steget innan nästa.

Ett större steg (till exempel 2.1.x → 2.2.x)

Ett byte av den andra siffran i Grav-kärnans version kan ändra mer. Utöver stegen ovan:

  1. Läs hela changelogen, inte bara rader som liknar listorna.
  2. Jämför serverkonfigurationen. Ändrar uppgraderingen filerna i webserver-configs/, jämförs ändringen med installationens egen nginx-regel. Rör den skyddet av user/, provas att konfig, konton och data i varje sajt svarar 403.
  3. Lasttestet före och efter, med samma scenarier, när lasttestet finns. Svarstiderna jämförs.
  4. Den manuella checklistan (tests/CHECKLIST.md) gås igenom efter sista steget.

Driftsätta

  1. Grenen slås ihop när alla steg är gröna.
  2. Driftsättningen är som vilken ändring som helst. På en server byggd med paket uppdateras Grav och Gravs plugin i samma versioner som i versions.lock.
  3. Varje driftsättning slutar med php bin/grav cache på servern. Det gäller också en vanlig ändring utan uppdatering.
  4. Öppna hälsokontrollen efteråt (sidan Hälsokontroll).

Backa

  • Ett steg: git revert <commit> för steget, sedan bin/setup.
  • Allt: återställ till taggen, till exempel med git revert --no-edit fore-uppdatering-2026-q4..HEAD, och kör bin/setup. git diff fore-uppdatering-2026-q4 ska då inte visa något.
  • Data: ändrade en uppdatering konton eller user/data/, läggs säkerhetskopian tillbaka.
  • Kör röktesterna efteråt. De ska ge samma resultat som före uppdateringen.
© 2026 Groovy Docs