WordPress
Staging verwenden: Zum Production-Umfeld pushen und aus dem Production-Umfeld pullen
Once a staging copy exists, two operations keep it useful: pushing your tested changes up to the live site, and resetting staging back to a fresh copy of production. This guide covers both…
Sobald eine Staging-Kopie vorhanden ist, halten zwei Operationen sie nützlich: das Hochfahren deiner getesteten Änderungen auf die Live-Site und das Zurücksetzen von Staging auf eine frische Kopie der Produktion. Dieser Leitfaden behandelt beide Richtungen im Detail, die Bestätigungen, die deine Live-Site schützen, und die Fälle, in denen das Hochfahren einer Datenbank Daten zerstören würde.
Wenn du noch keine Staging-Umgebung erstellt hast, beginne mit Using Staging Environments. Dieser Artikel setzt ab dem Punkt an, an dem Staging vorhanden ist.
Die zwei Richtungen
| Vorgang | Was wird überschrieben | Verwendung |
|---|---|---|
| Zu Produktion hochfahren | Deine Live-Site | Änderungen auf Staging sind getestet und bereit für die Live-Schaltung |
| Von Produktion zurücksetzen | Deine Staging-Site | Du möchtest eine saubere Kopie der aktuellen Live-Site zum Arbeiten |
Beide befinden sich auf demselben Bildschirm: Websites, dann deine Website, dann Environments, dann Staging.

Die Karte oben auf diesem Bildschirm zeigt deine Staging-Domain, ihren Status, wie lange die letzte Synchronisierung von der Produktion her ist, und wann sie zuletzt hochgefahren wurde. WP Admin meldet dich direkt im Dashboard der Staging-Site an, und Visit site öffnet das Staging-Frontend.
Eine Staging-Kopie, die eine Woche oder länger nicht synchronisiert wurde, wird auf dieser Karte in Bernstein gekennzeichnet. Alte Staging-Umgebungen sind schlimmer als gar keine: du endest damit, gegen eine Site zu testen, die nicht mehr der Live-Site ähnelt. Setze zurück, bevor du eine neue Arbeit beginnst, nicht danach.
Hochfahren von Staging zur Produktion
Dies ersetzt einen Teil oder die gesamte Live-Site durch das, was sich auf Staging befindet.
- Öffne Environments, dann Staging.
- Scrolle zu Push Staging to Production.
- Wähle mit den Kontrollkästchen, was hochgefahren werden soll: Files, Database oder beides.
- Falls du Database angehakt hast, lasse Rewrite URLs angehakt. Dies führt eine Suche und Ersetzung über alle Tabellen durch, damit der Staging-Hostname als Teil des Hochfahrens durch deinen Produktions-Hostname ersetzt wird.
- Häkle I understand this modifies my live production site an.
- Gib deine Produktions-Domain in das Bestätigungsfeld genau wie angezeigt ein.
- Klicke auf Push to Production.
Der Button bleibt deaktiviert, bis sowohl das Kontrollkästchen angehakt als auch die Domain stimmt, sodass ein unbeabsichtigter Klick ein Hochfahren nicht starten kann.
Ein Hochfahren überschreibt, es mergt nicht. Alles, das sich auf der Produktion seit dem letzten Zurücksetzen geändert hat, wird durch das ersetzt, das sich auf Staging befindet. Das umfasst neue Posts, neue Kundenkonten, neue Formulareinträge und neue Bestellungen.
Ein vollständiges Backup der Produktion wird automatisch vor dem Schreiben erstellt, und falls das Hochfahren auf halbem Weg fehlschlägt, wird die Produktion auf dieses Backup zurückgesetzt. Kleine Sites sind normalerweise in deutlich unter einer Minute fertig; eine große Datenbank oder eine Medienbibliothek mit mehreren Gigabyte dauert länger.
Auswahl von Dateien, Datenbank oder beides
Dies ist die wichtigste Entscheidung, und die Antwort ist normalerweise nicht "beides".
Nur Dateien. Der sichere Standard für eine Site, die etwas von Besuchern erfasst. Theme-Edits, Plugin-Updates, Template-Änderungen und benutzerdefinierter Code befinden sich alle in Dateien. Das Hochfahren nur von Dateien lässt jeden Post, jeden Kommentar, jede Bestellung und jeden Benutzer auf der Produktion unverändert.
Nur Datenbank. Für Inhalts- oder Einstellungsänderungen auf Staging, auf einer Site, wo niemand die Produktion direkt bearbeitet. In der Praxis selten.
Beides. Richtig für einen Redesign oder ein Rebuild, wo Staging die neue Site und Produktion wird wholesale ersetzt. Kündige es an, mache es außerhalb der Geschäftszeiten, und bestätige, dass du ein aktuelles Backup hast.
Das Hochfahren der Datenbank zu einem Live-Store löscht Bestellungen. WooCommerce speichert Bestellungen, Kunden, Abonnements, Gutscheine und Lagerbestände in der Datenbank, daher verschwinden alle Bestellungen, die seit dem letzten Zurücksetzen aus der Produktion aufgegeben wurden, sobald das Hochfahren abgeschlossen ist. Es gibt keine teilweise Wiederherstellung. Fahre in einem Store nur Dateien hoch, und nehme Änderungen auf Datenbankebene direkt auf der Produktion vor. Siehe Setting Up WooCommerce.
Die gleiche Falle gilt, weniger dramatisch, für jede Site mit Kommentaren, Formulareinreichungen, Mitgliedschaftsanmeldungen oder einer in WordPress gespeicherten Mailing-Liste.
Zurücksetzen von Staging aus der Produktion
Dies ist die sichere Richtung: Sie überschreibt Staging mit der aktuellen Live-Site und berührt Produktion niemals.
- Öffne Environments, dann Staging.
- Finde Reset from Production.
- Häkle Files, Database oder beides an.
- Klicke auf Reset from Production.
Mache dies, wenn:
- Die Produktion vorangegangen ist, mit neuen Posts, neuen Bestellungen oder Inhaltsedits.
- Du eine neue Arbeit beginnst und eine realistische Basis möchtest.
- Staging ist so weit abgewichen, dass ein Testergebnis dort nichts bedeutet.
Alles auf Staging, das nicht hochgefahren wurde, geht verloren. Falls es Arbeit auf Staging gibt, die du noch möchtest, fahre sie zuerst hoch, oder kopiere die geänderten Dateien über Files, dann File Manager heraus, bevor du zurückgesetzt wirst.
Wie URL-Umschreibung funktioniert
WordPress speichert seine eigene Adresse in der Datenbank, in den Zeilen siteurl und home der options-Tabelle, und absolute URLs landen auch in Post-Inhalten, Meta-Werten, Widget-Einstellungen und Theme-Optionen.
Deine Staging-Site läuft unter staging. gefolgt von deiner Domain, daher verweisen all diese Werte auf den Staging-Hostname, während du dort arbeitest. Rewrite URLs beim Hochfahren führt eine ordnungsgemäße Suche und Ersetzung über alle Tabellen durch, verarbeitet serialisierte Plugin-Einstellungen korrekt und tauscht den Staging-Hostname gegen deinen Produktions-Hostname aus.
Lasse ihn angehakt, es sei denn, du hast einen spezifischen Grund, dies nicht zu tun. Falls du nur Dateien hochfährst oder eine abweichende Staging-URL bestehen bleibt, repariere es mit Running a Search and Replace.
Ein Workflow, der standhält
- Setze von der Produktion zurück, damit Staging der Live-Site entspricht.
- Erstelle ein Backup der Produktion, bevor du beginnst, damit du einen Wiederherstellungspunkt unabhängig vom Hochfahren hast: Taking a Backup.
- Führe die Arbeit auf Staging durch. Plugin- und Theme-Updates, neuer Code, Layout-Änderungen.
- Teste auf der Staging-Domain. Lade die Seiten, die du geändert hast, und die Seiten, die du nicht geändert hast. Führe in einem Store eine Test-Bestellung von Anfang bis Ende durch.
- Fahre nur Dateien hoch, es sei denn, du hast bewusst entschieden, dass die Datenbank auch gehen muss.
- Überprüfe die Produktion sofort. Startseite, eine tiefe Seite, der Checkout und das Admin-Dashboard.
- Setze Staging von der Produktion aus zurück, sobald du zufrieden bist, damit die nächste Runde sauber beginnt.
Staging wird vollständig von deiner Produktions-Site aus verwaltet. Es wird nicht als separater Eintrag in der Websites-Liste angezeigt, daher befinden sich alle Steuerelemente dafür, einschließlich des Löschens, auf dieser einen Registerkarte.
Löschen von Staging
Die Karte Delete Staging am unteren Rand desselben Bildschirms entfernt die Staging-Kopie. Die Produktion ist nicht betroffen. Lösche sie, wenn ein Projekt abgeschlossen ist: Staging zählt zum Speicher deines Plans, und eine veraltete Kopie ist eher eine Verbindlichkeit als ein Vermögenswert.
Troubleshooting
Die Schaltfläche "Push to Production" wird nicht aktiviert. Beide Bedingungen müssen erfüllt sein: das Bestätigungskästchen angehakt und die Produktions-Domain genau eingegeben, ohne https:// und ohne nachfolgende Schrägstrich.
Das Hochfahren ist beendet, aber die Site zeigt immer noch alten Inhalt. Zwischenspeicherung. Spüle von WordPress, dann Quick Actions, dann Flush Cache, leere das CDN aus Performance, dann Kapsule CDN, und lade in einem privaten Fenster neu.
Staging-URLs werden auf der Live-Site nach einem Hochfahren angezeigt. Die Datenbank wurde ohne angehaktes Rewrite URLs hochgefahren. Führe eine Suche und Ersetzung vom Staging-Hostname zu deinem Produktions-Domain aus: Running a Search and Replace.
Ich habe die Datenbank hochgefahren und Bestellungen verloren. Stelle das automatische Backup vor dem Hochfahren sofort wieder her, bevor weitere Bestellungen in der überschriebenen Datenbank ankommen: Restoring From a Backup.
Staging zeigt einen Fehler nach einem Zurücksetzen an. Ein Plugin, das die Produktions-Domain hartcodiert, ist normalerweise die Ursache. Melde dich mit WP Admin auf der Staging-Karte an und deaktiviere dort Plugins, bis der Fehler behoben ist, dann repariere oder ersetze das offending Plugin auf der Produktion.