Zum Hauptinhalt springen
How Can We Help?
< All Topics

Eine Staging-Umgebung ist die beste Versicherung gegen kaputte Live-Websites. Direkt in Produktion zu arbeiten, ist der häufigste Grund für kaputte Websites. Ein sauberer Workflow trennt Entwicklung, Test und Live-Betrieb.

Die drei Umgebungen

  • Local: Entwicklung auf dem eigenen Rechner (z. B. DDEV, Lando, wp-env, LocalWP).
  • Staging: Möglichst identisch mit Produktion (gleiche PHP-Version, gleicher Webserver, gleiche Plugins), aber von Suchmaschinen und Öffentlichkeit abgeschirmt.
  • Production: Wird nur über den definierten Workflow verändert.

Mit WP_ENVIRONMENT_TYPE kennt jede Umgebung ihren Typ.

Staging richtig absichern

  • HTTP Basic Auth oder IP-Whitelist vor die ganze Staging-Site.
  • blog_public auf 0 und zusätzlich X-Robots-Tag: noindex.
  • Ausgehende Mails abfangen (z. B. Mailpit oder ein MU-Plugin, das pre_wp_mail filtert).
  • Zahlungs-Gateways in den Testmodus, Webhooks und Cronjobs zu Drittsystemen deaktivieren.
  • Personendaten anonymisieren, wenn Produktionsdaten kopiert werden (nDSG/DSGVO).

Code vs. Inhalte

Grundregel: Code fliesst nach oben (Local → Staging → Production), Inhalte fliessen nach unten (Production → Staging → Local). Wer Datenbanken nach oben kopiert, überschreibt Bestellungen, Kommentare und Formulareinträge.

Git-basiertes Deployment

Ins Repository gehören das eigene Theme, eigene Plugins, MU-Plugins und Konfiguration, nicht Uploads, Caches oder Secrets. Fremd-Plugins lassen sich per Composer über WPackagist verwalten:

{
  "repositories": [ { "type": "composer", "url": "https://wpackagist.org" } ],
  "require": {
    "wpackagist-plugin/query-monitor": "^3.16",
    "wpackagist-theme/twentytwentyfive": "*"
  },
  "extra": { "installer-paths": {
    "wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
    "wp-content/themes/{$name}/": ["type:wordpress-theme"]
  } }
}

Projekt-Boilerplates wie Bedrock strukturieren das Ganze mit .env-Dateien und getrenntem Webroot.

Atomare Deployments

Statt Dateien auf dem Live-Server zu überschreiben, wird jede Version in ein eigenes Release-Verzeichnis ausgeliefert und per Symlink aktiviert:

releases/2026-11-10_2140/
releases/2026-11-03_1015/
current -> releases/2026-11-10_2140
shared/uploads, shared/.env

Ein Rollback ist dann nur ein Symlink-Wechsel. Tools: Deployer (PHP), GitHub Actions/GitLab CI mit rsync, oder die Deploy-Funktion des Hosters.

Datenbank zwischen Umgebungen

wp @prod db export - | wp @staging db import -
wp @staging search-replace 'https://example.ch' 'https://staging.example.ch' --all-tables --precise

Kombination mit DISALLOW_FILE_MODS

Wenn alles über Git/Composer läuft, kann in Produktion DISALLOW_FILE_MODS gesetzt werden. Damit sind Plugin-Installationen über das Backend – und damit ein beliebter Angriffsweg nach Admin-Übernahme – blockiert.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: