Auto-Update von Peacock-Komponenten

WordPress hat seinen eingebauten Plugin-Updater — du klickst „Update" im Admin und alles ist neu. Peacock hat fünf Komponenten, die unterschiedliche Update-Pfade haben. Hier steht, welcher Pfad welchen Komponenten trifft, und wann du etwas tun musst.

TL;DR

Komponent	Update-Pfad	Du musst…
embed.js (Drop-in-Script)	Auto via CDN-URL	Nichts — die unversionierte URL holt automatisch die neueste Version. Außer du nutzt SRI (siehe unten).
peacock-admin.js (Per-Site-Admin)	Auto via CDN-URL	Nichts — same as embed.js.
@peacock/sdk-js + @peacock/sdk-astro	npm	pnpm update @peacock/sdk-js @peacock/sdk-astro + redeploy.
WordPress-Plugin peacock-cms	wp.org-Plugin-Channel	WP-Admin → Plugins → "Update available" klicken (Standard-WordPress-Workflow).
@peacock/cli (Framework-Installer)	npm	pnpm dlx @peacock/cli@latest <command> benutzt immer die neueste.
Self-hosted Peacock-Backend (Docker)	docker pull	docker compose pull && docker compose up -d — danach docker exec peacock-api php artisan migrate für DB-Schema-Updates.

Was aktualisiert sich automatisch?

embed.js und peacock-admin.js (auto)

Diese beiden Scripts werden über stabile URLs ausgeliefert:

• https://peacock-cms.webhoch.com/embed.js
• https://peacock-cms.webhoch.com/peacock-admin.js

Der Inhalt hinter der URL kann sich ändern, der Pfad bleibt gleich. Jeder Page-Reload deiner Site holt die jeweils neueste Version vom Peacock-CDN. Das ist die WordPress-Logik — der Plugin- Code selbst lebt nicht in deinem Hosting, sondern auf dem Peacock- CDN.

Cache-Control: beide Scripts haben einen kurzen Browser-Cache (max-age=60), damit ein Hotfix nicht 24 Stunden braucht, bis er alle Besucher erreicht.

Selbstmeldung der Version (/v1/version-Endpunkt)

Wenn embed.js lädt, ruft es im Hintergrund einmal den /v1/version-Endpoint deiner konfigurierten Peacock-Instanz an und vergleicht die installierte Version mit latest. Bei einer neueren Version emittiert es eine Browser-Konsolenwarnung (kein UI-Bruch, nur Information für Entwickler:innen):

[peacock-embed] You are running version 0.1.0 — newer version 0.2.0
is available. See https://peacock-cms.webhoch.com/CHANGELOG.html

Da embed.js die unversionierte URL ist und auto-updatet, ist diese Warnung nur dann relevant, wenn du SRI verwendest oder eine versionierte URL pinnst (siehe nächster Abschnitt).

Was aktualisiert sich NICHT automatisch?

Wenn du SRI nutzt

<script src="https://peacock-cms.webhoch.com/embed-v0.1.0.js"
        integrity="sha384-..."
        crossorigin="anonymous"
        data-peacock-api="..."
        data-peacock-space="..."
        defer></script>

Diese versionierte URL bleibt für immer auf v0.1.0. Damit der Browser dir vertraut, muss SRI immer match. Wenn eine neue Version kommt, musst du:

1. Neue SRI-Hash + Version aus /v1/version auslesen
2. Beide Werte einmal im Snippet austauschen
3. Deploy

Trade-off: SRI gibt dir Supply-Chain-Sicherheit (kein kompromittierter Origin-Server kann dir bösen Code unterjubeln), kostet dich aber pro Update einen manuellen Bump. Daumenregel: SRI für SEO-kritische Hauptseiten, unversionierte URL für interne Tools und Marketing-Banner.

npm-Pakete (@peacock/sdk-*, @peacock/cli)

Standard-npm-Workflow:

pnpm update @peacock/sdk-js @peacock/sdk-astro
# oder ein gezielter Pin:
pnpm add @peacock/sdk-js@0.2.0

Renovate / Dependabot fangen die Aktualisierungen ein und schicken einen PR. Wir nutzen Standard-Semver: MAJOR.MINOR.PATCH mit strenger Backwards-Compatibility-Garantie innerhalb einer MAJOR.

WordPress-Plugin

Sobald peacock-cms auf wordpress.org/plugins/peacock-cms/ veröffentlicht ist (zum Zeitpunkt dieses Dokuments: Review in progress), läuft der Standard-WP-Plugin-Update-Workflow:

• WordPress-Admin → Dashboard → Updates → „Update available"
• WP-CLI: wp plugin update peacock-cms

Bei einer Plugin-Aktualisierung läuft der peacock_cms_on_activate- Hook erneut. Bestehende Settings bleiben erhalten — das ist ausdrücklich getestet.

Self-hosted Peacock-Backend

Wenn du Peacock selbst hostest (Docker-Image ghcr.io/webhoch-com/peacock-api), läuft das wie bei jedem Container:

# Auf dem Server, im Peacock-Stack-Verzeichnis
docker compose pull
docker compose up -d
docker exec peacock-api php artisan migrate --force
docker exec peacock-api php artisan octane:reload

Wichtig: zwischen MAJOR-Versionen kann es DB-Migrationen geben, die nicht-reversibel sind. Lies vor jedem MAJOR-Update das CHANGELOG.

Wir empfehlen, einen automatischen peacock-update.sh-Script im Server-Cron zu installieren (Beispiel im Self-Host-Guide). So wirst du nie eine Sicherheits-Patch verpassen.

Wie checkst du deine Version?

Im Browser

console.log(window.peacockEmbed?.version);  // "0.1.0"
console.log(window.peacockAdmin?.version);  // "0.1.0"

Über curl

curl -sS https://peacock-cms.webhoch.com/v1/version | jq

Liefert die kanonische Antwort:

{
  "peacock": { "version": "0.1.0", "channel": "pre-alpha", "released_at": "2026-05-25" },
  "components": {
    "embed_js": { "latest": "0.1.0", "url": "...", "integrity": "..." },
    "sdk_js": { "latest": "0.1.0", "channel": "npm:@peacock/sdk-js" },
    "wordpress_plugin": { "latest": "0.1.0", "channel": "wp.org:peacock-cms" }
  }
}

Im WP-Plugin

echo PEACOCK_CMS_VERSION;  // "0.1.0"

Wann erscheinen welche Versionen?

Komponent	Cadence
Backend (Docker) + Admin + API	Continuous deploy ab Commit auf main
embed.js + peacock-admin.js	Continuous ab Commit (CDN-deploy ist Teil des main-Deployments)
@peacock/sdk-* auf npm	Bei merge eines Conventional-Commit-feat: oder fix:-PRs
@peacock/cli auf npm	Wenn ein neuer Framework-Installer landet
WordPress-Plugin	Manueller Push zum wp.org-SVN-Trunk + Tagging (siehe packages/wordpress-plugin/RELEASE.md)

Deprecation-Pfad

Wenn ein Endpunkt sich verändert oder ein altes Verhalten wegfällt, liefert /v1/version zusätzlich ein deprecations-Array:

{
  "deprecations": [
    {
      "feature": "embed.js automatic update warning via console.warn",
      "since": "0.1.0",
      "removal_in": "1.0.0",
      "replacement": "Subscribe to /v1/version polling in your own infra"
    }
  ]
}

So weißt du mindestens eine MAJOR-Version vorher, was wegfällt und was an die Stelle tritt. Backwards-Compatibility ist innerhalb einer MAJOR garantiert.