KLXM Studio – Startseite
Kontakt aufnehmen

Updates & Upgrades

Neue Version, ohne Bauchweh.

Code wird ersetzt, Inhalte bleiben, wo sie sind. Schema-Änderungen sind immer additiv – deshalb funktioniert auch ein Rollback auf das vorherige Release.

Ablauf

Was bei jedem Update passiert.

  1. Sichern

    Websites, Medien-PoolGemeinsame Mediathek für mehrere Websites einer Installation: Bilder und Dateien liegen einmal vor und lassen sich auf allen beteiligten Websites verwenden. und geteilte Tabellen.

  2. Code ersetzen

    app, vendor, resources, public/assets, bin, KitIn KLXM Studio das Paket aus Gestaltung und Bausteinen einer Website: Layout, Farben, Schriften und die passenden Blöcke. Ein Kit lässt sich anpassen oder wechseln, die Inhalte bleiben..

  3. Migrieren

    Datenbanken auf den Stand des Codes bringen.

  4. Prüfen

    health für alle Websites – erst dann live.

Empfohlen

Mit dem Deploy-Skript.

Baut, lädt in einen neuen Release-Ordner, sichert, migriert, prüft – und schaltet erst um, wenn alles grün ist. Einrichtung einmalig nach deploy/README.md.

  1. Ziel einmal beschreiben

    Aus example.env kopieren: SSH-Ziel, Basisordner, Adresse für den Rauchtest. Die Datei gehört nicht ins Repository.

    deploy/targets/production.env
    SSH_TARGET="kunde@server.example.de"
    BASE="/var/www/vhosts/kunde.de"
    URL="https://www.kunde.de"
  2. Zuerst auf Staging

    StagingTestumgebung, die der Live-Website gleicht. Neue Funktionen und Inhalte lassen sich dort prüfen, bevor sie online gehen – Suchmaschinen bleiben ausgesperrt.de.wikipedia.org (öffnet in neuem Tab) ist eine eigene Installation mit Kopie der Live-Inhalte (noindex, E-Mails umgeleitet).

    deploy.sh
    deploy/sync-content.sh default     # Live-Inhalte nach Staging
    deploy/deploy.sh staging
  3. Dann live

    Vorher automatisch Sicherung aller Websites, Pools und geteilten Tabellen; danach migrate, extensions:publish und health.

    deploy.sh
    deploy/deploy.sh production
  4. Zurück, falls nötig

    Aktiviert das vorherige Release – nur ein Symlink, die Datenbank bleibt.

    --rollback
    deploy/deploy.sh production --rollback

Für GitHub Actions liegt eine TemplateVorlage für wiederkehrende Seiten oder Dokumente: Aufbau und Gestaltung stehen fest, die Inhalte werden eingesetzt. bei: deploy/github-actions/deploy.yml.example (Push auf main → Staging, Produktion mit Freigabe).

Ohne Releases

Per Upload.

Für Installationen, in die der Code direkt hochgeladen wird.

  1. Sichern

    SSH
    php bin/console site:backup --all
    php bin/console pool:backup --all
    php bin/console shared:backup --all
  2. Code ersetzen

    app/, vendor/, resources/, public/assets/, bin/, lang/ und die Kits überschreiben. config/, storage/ und die Medienordner bleiben unangetastet.

  3. Migrieren und Dateien veröffentlichen

    Website-Datenbanken migrieren sonst beim nächsten Aufruf selbst – geteilte, Netzwerk- und Support-Datenbanken nur hierüber.

    SSH
    php bin/console migrate --all
    php bin/console extensions:publish
    php bin/console cache:clear --all
  4. Prüfen

    health
    php bin/console health --all

Upgrades

Kits und Erweiterungen.

Passen meine Kits und Erweiterungen zur neuen Version?

Jedes Kit und jede Erweiterung nennt die nötige Mindestversion (requires). Inkompatible zeigen health und die Systeminfo; php bin/console kit:check --all meldet veraltete Überschreibungen.

Kontakt

Sprechen Sie mit KLXM Crossmedia.

Installation, Umzug oder Betrieb für Ihr Projekt – wir helfen gern. Wir antworten persönlich.

KLXM Crossmedia GmbH
Am Schürmannshütt 40g
47441 Moers
Deutschland