Staging-Umgebungen

Jede WordPress-Installation bei Kinsta kann ihre eigene kostenlose WordPress-Staging-Umgebung haben, die völlig getrennt von der Live-Produktionsseite ist. Das ist ideal, um neue WordPress-Versionen, Plugins, Code und allgemeine Entwicklungsarbeit zu testen. Erstelle in wenigen Minuten eine Entwicklungsseite und teile sie mit deinem Team.

Wenn du weitere Staging-Umgebungen hinzufügen möchtest, eine Staging-Umgebung brauchst, die deiner Live-Umgebung ähnlicher ist, oder ressourcenintensive Tests oder Entwicklungen durchführen musst, solltest du dir unser Add-on Premium Staging-Umgebung ansehen.

Standard vs. Premium Staging

Du kannst bis zu 5 Premium Staging-Umgebungen hinzufügen, die mehr Ressourcen und Funktionen als Standard-Umgebungen enthalten. Die folgende Tabelle zeigt die Unterschiede zwischen unserem Standard- und Premium-Staging:

	Premium	Standard
PHP-Arbeiter	Wie in deiner Live-Umgebung	1
CPU	12	1
RAM	8 GB	8 GB
CDN	Ja	Nein
Edge Caching	Ja kann aktiviert werden	Nein

Erfahre mehr über unser Premium Staging Environment Add-on.

WordPress Standard- oder Premium-Staging-Umgebung erstellen

Wir haben die Erstellung einer WordPress-Staging-Site so einfach wie möglich gemacht. In MyKinsta klickst du in der linken Navigation auf WordPress-Websites. Dort siehst du eine Liste deiner Websites/Installationen. Wähle die Website aus, für die du eine Staging-Umgebung erstellen möchtest, klicke auf das Feld Springen zu oder Suchen und wähle Neue Umgebung erstellen.

Wähle im Pop-up-Fenster Neue Umgebung erstellen die Option Standard- oder Premium-Umgebung und klicke auf Weiter.

Als nächstes wirst du aufgefordert, die Art der Umgebung auszuwählen, die du erstellen möchtest. Es gibt drei Optionen.

1. Vorhandene Umgebung klonen: Mit dieser Option kannst du eine bestehende Umgebung (live oder eine Premium-Staging-Umgebung) in die neue Staging-Umgebung klonen.
2. Neues WordPress installieren: Mit dieser Option installierst du eine voll funktionsfähige leere WordPress-Website, die du sofort nutzen kannst.
3. Leere Umgebung (ohne WordPress): Bei dieser Option wird die gesamte Software installiert, die für den Betrieb einer WordPress-Website erforderlich ist (Webserver, PHP, MySQL usw.), aber WordPress selbst wird nicht installiert. Dies ist eine gute Option für Nutzer, die mit Duplicator zu Kinsta migrieren oder eine Bedrock/Trellis-Installation mit einer benutzerdefinierten Dateistruktur einrichten.

Option Eins – Klonen einer bestehenden Umgebung

Mit der Option Eine bestehende Umgebung klonen kannst du eine beliebige bestehende Umgebung (Live- oder Premium Staging-Umgebung) in die neue Staging-Umgebung klonen.

• Umgebungsname: Gib einen Namen für die Staging-Umgebung ein; dieser muss zwischen 3 und 12 Zeichen lang sein.
• Zu klonende Umgebung: Wähle eine bestehende Umgebung aus, die in die neue Staging-Umgebung geklont werden soll.

Option Zwei – Neues WordPress installieren

Die Option Neues WordPress installieren enthält mehrere Felder, mit denen du deine Website anpassen kannst. Hier erfährst du, was du über jedes Feld wissen musst.

• Umgebungsname: Gib einen Namen für die Staging-Umgebung ein; dieser muss zwischen 3 und 12 Zeichen lang sein.
• WordPress-Site-Titel: Hier kannst du den Titel für deine WordPress-Website festlegen. Abhängig von deinem Theme ist er für die Besucher der Website im Browser-Tab und an anderen Stellen sichtbar. Du kannst den Seitentitel in den WordPress-Einstellungen nach der Erstellung der Website ändern.
• WordPress-Admin-Benutzername: Damit meldest du dich bei deiner WordPress-Installation an. Später kannst du weitere Benutzer hinzufügen. Wir empfehlen dir, als Benutzernamen etwas anderes als admin zu wählen, um maximale Sicherheit zu gewährleisten.
• WordPress-Admin-Passwort: Mit diesem Passwort meldest du dich bei deiner Installation an. Wir erzwingen automatisch starke Passwörter, um die Benutzer zu schützen.Wenn du ein neues Passwort möchtest , kannst du dieOption Neues Passwort generieren (Symbol „Neu laden“) verwenden. Hier erfährst du, wie du dein WordPress-Passwort später ändern kannst.
• WordPress Admin-E-Mail: WordPress verwendet die Admin-E-Mail-Adresse, um wichtige Benachrichtigungen zu versenden.
• Wähle eine Sprache aus: Wähle die Sprache aus, die du in WordPress verwenden möchtest. Du musst deine Inhalte nicht in der gleichen Sprache schreiben wie deine WordPress-Oberfläche. Du kannst also ruhig deine Muttersprache wählen, auch wenn du deine Inhalte auf Englisch schreibst.
• WordPress Multisite installieren: Markiere dieses Feld, wenn du eine WordPress-Multisite-Installation erstellen möchtest. Wenn du diese Option gewählt hast, kannst du zwischen einer Subdomain- und einer Unterverzeichnis-Installation wählen .
• WooCommerce installieren: Wenn du eine E-Commerce-Website erstellst, ist WooCommerce das beliebteste E-Commerce-Plugin auf dem Markt. Aktiviere dieses Kästchen, um es automatisch zu installieren.
• Yoast SEO installieren: Yoast SEO ist das beliebteste SEO-Plugin für WordPress mit über 3 Millionen Installationen und einer Bewertung von 5 von 5 Sternen. Aktiviere dieses Kontrollkästchen, um es automatisch zu installieren.
• Installiere Easy Digital Downloads: Wenn du eine Website zum Verkauf digitaler Produkte erstellst, ist Easy Digital Downloads eine komplette eCommerce-Lösung für den Verkauf digitaler Produkte. Aktiviere dieses Kästchen, um es automatisch zu installieren.

Option Drei – Leere Umgebung (ohne WordPress)

Die Option Leere Umgebung ist für Nutzer/innen hilfreich, die eine leere Umgebung für die Duplicator-Migration oder für benutzerdefinierte Bedrock/Trellis-Installationstests benötigen.

• Umgebungsname: Gib einen Namen für die Staging-Umgebung ein; dieser muss zwischen 3 und 12 Zeichen lang sein.

Erstellen der Staging-Umgebung

Wenn du bereit bist, klicke auf Weiter. Wenn du eine Premium-Staging-Umgebung erstellst, bestätige das wiederkehrende Abonnement und klicke auf Premium-Umgebung erstellen.

Zugriff auf deine Staging-Umgebung

Das Erstellen der neuen Umgebung kann ein paar Minuten dauern. Wenn sie fertig ist, klickst du auf das Feld Springen zu oder Suchen und wählst die Umgebung aus.

Du kannst die Staging-Umgebung auch über die Liste der WordPress-Websites aufrufen.

Jede Umgebung hat einen farblich gekennzeichneten Kreis: grün für Live, schwarz für Standard Staging und orange für Premium Staging. Du hast dann ein separates Bedienfeld mit Verbindungsinformationen, DNS, Backups, Tools und Plugins für deine Staging-Umgebung.

Um deine Staging-Site schnell zu besuchen, gehst du auf die Registerkarte Domains in deiner Staging-Umgebung und klickst auf den Link URL öffnen. Du kannst auch schnell zum WordPress-Admin deiner Staging-Site gelangen, indem du auf den Link WordPress-Admin öffnen klickst.

URL-Struktur und Domain

Die Standard-URL-Struktur deiner Staging-Umgebung folgt diesem Format:

• Standard: https://stg-sitename-environmentname.kinsta.cloud
• Premium: https://env-sitename-environmentname.kinsta.cloud

Wenn du eine ältere Staging-Site hast, sieht deine URL vielleicht so aus:

• https://staging-sitename-environmentname.kinsta.cloud
• https://staging-sitename.kinsta.cloud
• https://staging-sitename.kinsta.com

Du kannst auch eine benutzerdefinierte Domain zu deiner Staging-Site hinzufügen, wenn du eine benutzerdefinierte Domain verwenden möchtest.

Zusätzliche Hinweise

Wenn du SSL auf deiner Live-Site aktiviert hast und die Website in die Staging-Site klonst, wird SSL auch auf deiner Staging-Site aktiviert.

Du kannst phpMyAdmin direkt aus MyKinsta heraus starten. Klicke auf der Registerkarte Info auf den Link phpMyAdmin öffnen. Die URL-Struktur für phpMyAdmin Staging folgt diesem Format:

https://mysqleditor-stg-sitename-environmentname.kinsta.cloud

Aktualisiere die Staging-Umgebung

Wenn du nach der Erstellung der Staging-Umgebung Änderungen an deiner Live-Site vornimmst und diese Änderungen in der Staging-Umgebung widerspiegeln möchtest, kannst du die Staging-Umgebung mit einem selektiven Push aktualisieren. Auf diese Weise musst du die Staging-Umgebung nicht löschen und neu erstellen, was Zeit spart und alle Staging-Backups beibehält.

Push-Umgebung in die Live- oder Staging-Umgebung

Du kannst deine WordPress-Staging-Umgebung auf deine Live-Umgebung übertragen, wenn du mit den vorgenommenen Änderungen zufrieden bist und sie auf deine Live-Site übertragen möchtest.

Du kannst auch deine Live-Umgebung in deine Staging-Umgebung verschieben. Dies ist nützlich, um die Staging-Umgebung zu aktualisieren und die Änderungen in der Live-Umgebung zu übernehmen.

Mit der Funktion Selektiver Push kannst du genau festlegen, was du pushen willst. Im Einzelnen kannst du:

• nur deine Dateien,
• nur deine Datenbank,
• bestimmte Dateien und Ordner,
• bestimmte Datenbanktabellen,
• alles pushen.

Das Verschieben von Umgebungen ist mit wenigen Klicks erledigt, aber lies bitte die folgenden Hinweise, bevor du fortfährst. Sie enthalten wichtige Informationen über den Prozess.

Wichtige Hinweise

• Wir empfehlen, die Push-Umgebungsfunktion mit Bedacht zu nutzen, vor allem, wenn du von Staging auf Live umstellst. Beginne den Prozess zu Zeiten mit geringem Datenverkehr und halte einen Entwickler bereit, falls Probleme auftreten. Wenn du die Unterstützung eines Entwicklers brauchst (aber keinen hast), kannst du ihn an verschiedenen Stellen anheuern.
• Wir erstellen automatisch ein Backup, damit du bei Bedarf ein Rollback durchführen kannst. Hinweis: Wenn es sich bei deiner Live-Site um eine E-Commerce- oder eine andere dynamische und sich schnell verändernde Site handelt, können Daten zwischen dem Push und der Wiederherstellung des Backups verloren gehen.
• Umgebungseinstellungen (Weiterleitungen, Geolocation, PHP- und Nginx-Konfiguration usw.) werden in den Push einbezogen (auch wenn nur Dateien oder Datenbanken ausgewählt sind) und überschreiben die Umgebungseinstellungen vollständig.
• Sobald der Push von der Staging- zur Live-Umgebung abgeschlossen ist, solltest du den Cache deines Themes oder deiner Plugins löschen, den Cache deines Browsers leeren und deine Website testen, um sicherzustellen, dass sie wie erwartet funktioniert.
• Wenn du beim Pushen deiner Datenbank die Option Suchen & Ersetzen aktivieren möchtest, wird die Domain automatisch durch die Domain der Umgebung ersetzt, in die du pushst.
• Wenn du Alle Dateien und Ordner auswählst, werden alle Dateien gepusht, einschließlich Plugins, Themes und Dateien in wp-content/uploads.
• Alle fest kodierten URLs in deinem Theme- oder Plugin-Code müssen auf die URL der Umgebung aktualisiert werden.
• Wenn der Passwortschutz (.htpasswd) in der Umgebung, aus der du pushst, aktiv ist, wird er nicht auf die Umgebung angewendet, in die du pushst. Du musst ihn nach dem Push in der Umgebung aktivieren.
• Wenn du WooCommerce verwendest, unterscheidet MyKinsta nicht zwischen neuen und älteren Kundenbestellungen, wenn du einen Push von der Staging- zur Live-Umgebung durchführst. Wenn du einen Push auf die Live-Site initiierst, kopiert MyKinsta alle Dateien und Ordner deiner Staging-Site genau so auf die Live-Site, wie sie ist, und überschreibt dabei Dateien und die Datenbank. Um dies zu umgehen, kannst du entweder:
  • Die Staging-Site mit einem selektiven Push auf die Live-Site schieben, dabei nur Dateien, damit deine Datenbank nicht überschrieben wird.
  • Datenbank-Tabellen selektiv pushen und die benötigten WooCommerce-Tabellen ausschließen.
  • Die Datenbankdateien von Live nach Staging schieben, bevor du Staging nach Live pusht, um sicherzustellen, dass du die aktuellsten Daten hast.

  Informationen darüber, was in den einzelnen WooCommerce-Datenbanktabellen enthalten ist, findest du in der WooCommerce-Datenbankbeschreibung. Du solltest diese Aufgabe mit deinem Webentwickler besprechen. Wenn du noch keinen hast oder dir nicht sicher bist, schau dir unseren Artikel darüber an, wie du einen WordPress-Entwickler anheuerst.

• Wenn du die Staging-Umgebung in die Live-Umgebung überführst, überprüfe die Staging-Site und behebe alle Fehler, bevor du in die Live-Umgebung pusht.
• Staging-Umgebungen sind nur für die Entwicklung und für Tests gedacht. Sie sind nicht dafür gedacht, als Live-Produktionsseiten verwendet zu werden, und es kann sein, dass einige Dinge nicht wie erwartet funktionieren. Kinsta ist nicht dafür verantwortlich, wenn du versuchst, eine Staging-Umgebung für eine Live-Site zu verwenden.
• Das Pushen einer Umgebung hat keine Auswirkungen auf die Umgebung, von der aus du pushst, und sie bleibt von den anderen Umgebungen getrennt. Nachdem du eine Staging-Site auf die Live-Site gepusht hast, kannst du mit der Entwicklung und dem Testen von Änderungen in der Staging-Umgebung fortfahren, ohne dass sich dies auf deine Live-Site auswirkt, bis du die Änderungen erneut auf die Live-Site pushst.
• Der Push von der Staging-Umgebung auf die Live-Umgebung hat keine Auswirkungen auf das CDN von Kinsta, wenn es auf deiner Live-Site läuft, aber wir empfehlen, den CDN-Cache nach dem Push zu löschen (WordPress Websites > seitenname > Caching > CDN > CDN-Cache löschen).
• Beim Push von der Staging- auf die Live-Site ist Vorsicht geboten, wenn deine Website ein Multisite-Netzwerk ist. Je nachdem, wie die Multisite eingerichtet ist, kann das Pushen der Datenbank funktionieren oder nicht. Wenn du den selektiven Push verwendest und alle Datenbanktabellen oder alle Datenbanktabellen und alle Dateien und Ordner pushst, wird der gesamte Datenbankinhalt live geschaltet und wirkt sich auf alle Seiten (die Hauptseite und die Unterseiten) in deinem Multisite-Netzwerk aus.
• Wenn du ein nicht standardmäßiges WordPress-Setup verwendest, wie z. B. Bedrock oder Trellis, kann Kinsta die Variable DB_PASSWORD möglicherweise nicht finden und ist daher nicht in der Lage, das Datenbankpasswort zu aktualisieren, wenn du die Staging-Umgebung live schaltest. In diesem Fall musst du, wenn du die Umgebung live schaltest, die Datei, in der du DB_PASSWORD definierst, manuell mit dem neuen Datenbankpasswort aktualisieren, das du in MyKinsta festgelegt hast.

Push einer Umgebung mit einem selektiven Push

Befolge die folgenden Schritte, um deine Umgebung in eine andere Umgebung zu verschieben. Mit dem Workflow für den selektiven Push kannst du auswählen, was du pushen willst.

1. Wähle deine Umgebung aus

Melde dich bei MyKinsta an, klicke auf WordPress Websites und dann auf die Umgebung, von der du pushen möchtest. Wenn du eine Premium-Staging-Umgebung hinzugefügt hast, kannst du aus mehr als einer Umgebung auswählen.

2. Umgebung pushen

Klicke in der Umgebung auf Push-Umgebung und wähle im Dropdown-Menü Push zur Umgebung aus.

3. Wähle aus, welche Dateien und Datenbanktabellen gepusht werden sollen

Wähle in dem Pop-up/Modal Push to environment, das erscheint, eine der folgenden Optionen:

• Dateien > Alle Dateien und Verzeichnisse: Verschiebt alle Dateien und Ordner in die ausgewählte Umgebung.
• Dateien > Bestimmte Dateien und Ordner: Wähle genau aus, welche Dateien und Ordner du in die gewählte Umgebung verschieben möchtest. Du kannst den Textbereich verwenden, um einen bestimmten Pfad/Ordner/Datei zu definieren. Weitere Informationen darüber, wofür die einzelnen Dateien in WordPress verwendet werden, findest du in unserem umfassenden Leitfaden über WordPress-Dateien und ihre Verwendung.
• Datenbank > Alle Datenbanktabellen: Pusht alle Datenbanktabellen in die ausgewählte Umgebung.
• Datenbank > Bestimmte Datenbanktabellen: Wähle genau aus, welche Datenbanktabellen du in die gewählte Umgebung pushen möchtest. Weitere Informationen über die WordPress-Datenbank findest du in A Beginner’s Guide to WordPress Database: Was sie ist und wie man auf sie zugreift.

Gib den Namen der Website zur Bestätigung ein und klicke auf Push to environment.

Dabei sind einige Dinge zu beachten:

• Die Zeit, die der Prozess benötigt, hängt von der Größe deiner Website ab.
• MyKinsta wird dich benachrichtigen, wenn der Vorgang abgeschlossen ist.
• Wenn du deine Website vom Staging in den Live-Betrieb überführst, wird sie in den letzten Phasen des Prozesses ein paar Sekunden lang nicht erreichbar sein.
• Die Umgebungseinstellungen (Weiterleitungen, Geolocation, PHP- und Nginx-Konfiguration usw.) werden in den Push-Vorgang einbezogen (auch wenn nur Dateien oder Datenbanken ausgewählt sind) und überschreiben die Einstellungen der Umgebung vollständig.

Anwendungsfälle und Beispiel-Workflows

Nachfolgend findest du einige Beispiele dafür, wann du nur Dateien, nur die Datenbank oder beides pushen möchtest.

Nur alle Dateien und Verzeichnisse pushen

• Änderungen, die direkt an den Theme-Dateien (einschließlich HTML, CSS oder PHP) vorgenommen werden und keine Daten in der Datenbank speichern.
• Das Hochladen einer Datei, die nicht in die WordPress-Mediathek aufgenommen werden muss.
• Wenn du ein benutzerdefiniertes Plugin auf deiner Seite hast und Änderungen an den Dateien vornimmst, die sich nicht auf die Datenbank auswirken (keine Daten in der Datenbank speichern oder verändern).

Bestimmte Dateien und Verzeichnisse pushen

• Wenn du Änderungen an einem einzelnen Theme vornimmst, kannst du den spezifischen Ordner für das Theme im Ordner themes pushen.
• Wenn du eine neue Version eines Plugins im Staging testest, kannst du den entsprechenden Ordner für das Plugin im Ordner plugins pushen.
• Du kannst Änderungen an bestimmten Einstellungen oder Konfigurationsdateien live schalten, indem du im Textbereich den Pfad/Ordner/die Datei angibst, die du schalten willst.

Nur Datenbank pushen

Hinweis: Alle Änderungen an der Datenbank der Live-Site, die seit der Erstellung der Staging-Site vorgenommen wurden, gehen verloren, z. B. Kommentare, neue Inhalte, Einkäufe auf E-Commerce-Sites, Anmeldungen auf Mitgliedersites und Forenbeiträge.

• Das Erstellen oder Bearbeiten eines neuen Beitrags oder einer Seite, die keine hochgeladenen Medien (Bilder, Videos oder andere hochgeladene Dateien) enthält.
• Layout-Änderungen an einer Seite oder einem Beitrag, die mit einem Builder-Plugin vorgenommen wurden.
• Das Ändern des Website-Titels oder der Tagline.

Verschieben bestimmter Datenbanktabellen

• Wenn du ein benutzerdefiniertes WordPress-Plugin oder -Theme in der Staging-Umgebung testest, das eine Aktualisierung bestimmter Datenbanktabellen in deiner Live-Umgebung erfordert.
• Wenn du bestimmte Datentabellen umorganisierst oder Probleme mit den Tabellen in deiner Staging-Umgebung behebst und nur die neuen Tabellen in die Live-Umgebung übertragen möchtest.
• Wenn du benutzerbezogene Daten oder Benutzerrollen in der Staging-Umgebung änderst und nur die Tabellen der Benutzerdatenbank in die Live-Umgebung übertragen möchtest.

Alles pushen

Hinweis: Alle Änderungen an der Datenbank der Live-Site, die seit der Erstellung der Staging-Site vorgenommen wurden, gehen verloren, z. B. Kommentare, neue Inhalte, Einkäufe auf E-Commerce-Websites, Anmeldungen auf Mitgliedersites und Forenbeiträge.

• Das Erstellen neuer Inhalte, die hochgeladene Medien enthalten (Bilder, Videos oder andere hochgeladene Dateien).
• Änderungen an deinem Theme, die du im Customizer und in den Theme-Dateien vorgenommen hast.
• Installieren und Testen eines neuen Plugins oder einer aktualisierten Version eines Plugins.

Staging-Umgebung löschen und aktualisieren

Wenn du deine Staging-Site entfernen musst, gehe zu WordPress Websites und wähle die Staging-Umgebung aus, die du entfernen möchtest. Scrolle zum unteren Ende der Seite und klicke auf Umgebung löschen.

Bestätige in dem erscheinenden Pop-up-Fenster, dass du weißt, was gelöscht wird, gib den Namen der Website gefolgt von einem Bindestrich und dem Umgebungsnamen (SITENAME-ENVIRONMENTNAME) in das Feld ein und klicke dann auf Umgebung löschen.

Um deine Staging-Umgebung zu aktualisieren, löschst du sie, erstellst eine neue und wählst Option 1 – Klonen einer bestehenden Umgebung. Diese neu geklonte Staging-Umgebung enthält die neueste Version deiner Produktionsdatenbank und Dateien für Tests.

Alternativ kannst du auch ein Backup deiner Produktionsumgebung in der Staging-Umgebung wiederherstellen. Der Vorteil dieser Methode ist, dass eine hinzugefügte benutzerdefinierte Domain nicht gelöscht wird und du sie nicht bei jeder Aktualisierung der Staging-Umgebung erneut hinzufügen musst.

Ein WordPress-Backup in Staging wiederherstellen

Du kannst deine WordPress-Website von einem Backup direkt in deiner Staging-Umgebung wiederherstellen. Hier erfährst du, wie du ein WordPress-Backup in der Staging-Umgebung wiederherstellst. Hinweis: Alle Staging-Backups bleiben intakt, wenn du ein Live-Backup in Staging wiederherstellst.

Staging-Umgebung neu starten

In bestimmten Situationen kann es vorkommen, dass wir eine Staging-Umgebung im Rahmen einer Server-Fehlerbehebung anhalten. Wenn du feststellst, dass deine Staging-Umgebung gestoppt wurde und du beim Besuch deiner Website einen 501 nicht implementiert, einen 502 Fehler oder einen 521 Fehler siehst, kannst du die Staging-Umgebung in MyKinsta neu starten, indem du auf die Info-Seite deiner Website gehst und auf Staging-Umgebung starten klickst.

Wenn du deine Staging-Umgebung nicht neu starten kannst oder die Schaltfläche in MyKinsta nicht siehst, öffne bitte einen neuen Chat mit unserem Support-Team, um weitere Unterstützung zu erhalten.

Eine Staging-Umgebung entfernen

Wenn du mit dem Testen oder Entwickeln fertig bist, kannst du die Staging-Umgebung entfernen. Wenn du ein Premium-Staging-Umgebungs-Add-on verwendest, wird dir nur die Zeit in Rechnung gestellt, in der es aktiv ist; wenn du die Premium-Staging-Umgebung löschst, wird das Add-on deaktiviert und die weitere Abrechnung gestoppt.

Klicke in MyKinsta auf WordPress Websites und wähle die Umgebung aus, die du entfernen möchtest.

Scrolle zum Ende der Seite und klicke auf Umgebung löschen.

Bestätige in dem erscheinenden Pop-up-Fenster, dass du weißt, was gelöscht wird, gib den Site-Namen gefolgt von einem Bindestrich und den Umgebungsnamen (SITENAME-ENVIRONMENTNAME) in das vorgesehene Feld ein und klicke dann auf Umgebung löschen.

Wenn du eine Premium-Staging-Umgebung verwendest, wird das Add-on-Abonnement automatisch unter Unternehmen > Mein Plan in MyKinsta entfernt, sobald die Staging-Umgebung gelöscht wurde.

Wichtige Hinweise

Wenn du die Staging-Umgebung verwendest, gibt es einige wichtige Dinge zu beachten.

1. Seiten-Cache-Einstellungen für Staging-Websites

Da Staging-Umgebungen für Entwicklungszwecke, Fehlersuche und Tests gedacht sind, sind das Full-Page-Caching und der OPcache von Kinsta standardmäßig deaktiviert. Wenn du Geschwindigkeitstests für deine Website durchführst, wirst du überdurchschnittlich lange Ladezeiten feststellen, da die Seiten nicht aus dem Cache geladen werden. Wenn du das Caching auf einer Staging-Site in der Staging-Umgebung aktivieren möchtest, klicke auf Caching > Server-Caching > Aktivieren. Wenn die Zwischenspeicherung auf einer Staging-Site aktiviert ist, wird die Option Cache löschen aktiviert, mit der du den Cache leeren kannst. Wenn du eine Premium Staging-Umgebung hast, kannst du auch CDN und Edge Caching aktivieren.

2. Anmeldeinformationen für die Staging-Umgebung

Wenn die Staging-Umgebung ein Klon deiner Produktionsite ist, sind deine WordPress-Administrator-Anmeldedaten für deine Live- und deine Staging-Site identisch, es sei denn, du änderst sie nach der Erstellung deiner Staging-Umgebung.

3. SEO

Standardmäßig ist die Indizierung für Staging-Sites deaktiviert, damit sie die SEO deiner Live-/Produktionssite nicht beeinträchtigen. Dies wird durch eine Kombination aus einer WordPress-Einstellung und einem HTTP-Header erreicht, den wir automatisch hinzufügen.

Du kannst die WordPress-Einstellung sehen, indem du im WordPress-Dashboard deiner Staging-Site zu Einstellungen > Lesen gehst. Die Option, die Suchmaschinen von der Indizierung der Seite abzuhalten, ist neben der Sichtbarkeit für Suchmaschinen aktiviert.

Die temporären URLs von Kinsta und die Staging-URLs haben außerdem den HTTP-Header X-Robots-Tag: noindex, nofollow, nosnippet, noarchive, der die Indizierung der temporären URLs durch Suchmaschinen ausschließt. Diese Header können nicht aus den temporären Kinsta-URLs oder Staging-URLs entfernt werden. Wenn du diese Header von der Staging-Site entfernen möchtest, musst du ihr eine benutzerdefinierte Domain hinzufügen.

4. Plugins

Wenn du Social Scheduling Plugins wie CoSchedule oder Social Networks Auto Poster verwendest, solltest du diese Plugins auf deiner Staging-Site deaktivieren. Andernfalls könnte es passieren, dass sie anfangen, über deine Staging-URL in sozialen Netzwerken zu teilen, die dann etwa so aussieht: https://stg-sitename-environmentname.kinsta.cloud. Das könnte dann deine Analysen verfälschen.

Einige Plugins, wie z. B. das Jetpack-Plugin, werden auf Kinsta-Staging-Umgebungen automatisch im Staging-Modus ausgeführt. Du wirst eine Meldung sehen: „Du lässt Jetpack auf einem Staging-Server laufen.“ Im Staging-Modus verhält sich deine Staging-Site in fast jeder Hinsicht wie deine Produktionssite, außer dass keine Daten an WordPress.com weitergeleitet werden und du die Staging-Site nicht abschalten kannst (um zu verhindern, dass es zu Problemen mit deiner Produktionssite kommt).

Plugins, die über einen Domainnamen lizenziert werden, benötigen möglicherweise eine benutzerdefinierte Domain (statt einer Kinsta Staging-Subdomain), um ordnungsgemäß zu funktionieren. Hinweis: Wenn du einen benutzerdefinierten Domainnamen zu deiner Staging-Site hinzugefügt hast, musst du eventuell die Einstellungen zur Verwaltung deiner Plugin-Lizenz aktualisieren oder den Support deines Plugins kontaktieren.

5. Notiere dir deine Login-URL

Wenn du deine Website in die Staging-Site klonst und ein WordPress-Plugin verwendest, das deine Standard-Login-URL ändert, wird der benutzerdefinierte Teil der URL auf die Staging-Site kopiert. Beispiel: http://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin

6. Staging sollte nur für Entwicklung/Tests verwendet werden

Die Standard-Staging-Umgebung verfügt nur über 2 PHP-Worker, hat keine Option, das CDN von Kinsta zu aktivieren, und kann nach 24 Stunden Inaktivität in den Ruhezustand übergehen. Daher sollte sie nur für die Entwicklung und für Tests verwendet werden. Staging-Umgebungen (Standard und Premium) sind nicht für den Einsatz in der Produktion gedacht, und es kann sein, dass einige Dinge nicht richtig funktionieren. Kinsta ist nicht dafür verantwortlich, wenn du versuchst, eine Staging-Umgebung für eine Live-Site zu verwenden.

7. Vom Gesamtplan ausgeschlossener Speicherplatz

Um dir so viel Speicherplatz wie möglich zur Verfügung zu stellen, werden Staging-Sites bei der Berechnung deines gesamten Speicherplatzbedarfs nicht berücksichtigt. Nur Live-Sites werden auf deinen Speicherplatzverbrauch angerechnet.

8. Cron-Jobs

Server-Cron-Jobs aus der Live-Umgebung sind in der Staging-Umgebung nicht aktiv (auch nicht, wenn du deine Live-Site in die Staging-Umgebung klonst), sodass die Cron-Jobs der Live-Site in der Staging-Umgebung nicht ausgelöst werden. Wenn du außerdem die Crontab in der Staging-Umgebung änderst und die Staging-Umgebung in die Live-Umgebung verschiebst, wird die Crontab der Live-Umgebung überschrieben.

9. Multisite

Wenn du ein WordPress-Multisite-Netzwerk betreibst, kann es sein, dass es mit unserer Staging-Umgebung nicht funktioniert, je nachdem, wie deine Multisite eingerichtet ist.

• Wenn es sich um eine Multisite mit Unterverzeichnissen handelt (example.com, example.com/subsite1, example.com/subsite2), funktioniert sie problemlos mit unserer Staging-Umgebung.
• Wenn es sich um eine Subdomain-Multisite handelt (beispiel.com, unterseite1.beispiel.com, unterseite2.beispiel.com), funktioniert sie problemlos, vorausgesetzt, die Unterseiten benötigen kein HTTPS.
  • Wenn es sich um eine Subdomain-Multisite handelt, die HTTPS benötigt, musst du eine benutzerdefinierte Domain mit einem Wildcard-SSL-Zertifikat zu deiner Staging-Site hinzufügen, damit die Subdomains durch ein SSL-Zertifikat abgedeckt werden können. Der Grund dafür ist, dass das SSL-Zertifikat, das für die Standard-URL der Staging-Site bereitgestellt wird, nur die Subdomain der Staging-Site abdecken kann (z. B. stg-seitenname-umgebungsname.kinsta.cloud), so dass jede weitere Subdomain-Ebene (z. B. subsite.stg-seitenname-umgebungsname.kinsta.cloud) nicht abgedeckt werden kann.
• Wenn es sich um eine Multisite mit Domänenzuordnung handelt (d.h. verschiedene Unterseiten werden auf völlig unterschiedlichen Domänen geladen, z.B. example.com, example1.com, example2.com), wird es ohne umfangreiche manuelle Einstellungen nicht funktionieren.
  • Option 1: Deaktiviere die Domänenzuordnung und gehe zurück zur standardmäßigen Einrichtung von Unterverzeichnissen/Subdomänen. Suche und ersetze manuell in der Datenbank.
  • Option 2: Richte Staging-Subdomains für jede Live-Domain ein, füge sie alle zur Staging-Site hinzu und führe manuell ein Suchen und Ersetzen in der Datenbank durch.

10. E-Mail

In Staging-Umgebungen ist der E-Mail-Versand (Transaktions-E-Mails) standardmäßig aktiviert. Wenn du auf der Staging-Site eine Bestellung aufgibst, erhältst du entsprechende E-Mails von der Staging-Site. Wenn du nicht möchtest, dass Transaktions-E-Mails von deiner Staging-Umgebung versendet werden, kannst du ein Plugin wie Disable Emails verwenden, um den Versand von E-Mails zu unterbinden.

FAQ

Was ist Prorating?

Wenn wir einen Dienst wie das Premium Staging Environment Add-on anteilig berechnen, bedeutet das, dass du die Kosten auf der Grundlage der Dauer der Nutzung des Dienstes in diesem monatlichen Abrechnungszeitraum tragen musst.

Beispiel für Proration

Du willst eine neue Funktion auf deiner Website einführen und sie mit der vollen Leistung deines Tarifs testen. Du erstellst eine Premium Staging-Umgebung, fügst die neue Funktion hinzu und testest sie 1 Stunde lang. Alles sieht gut aus, also überträgst du die Änderung auf deine Live-Umgebung und löschst die Premium-Staging-Umgebung.

• 1 Monat Premium Staging-Umgebung kostet $20.
• Ausgehend von einem Monat mit 30 Tagen hat dieser Abrechnungszyklus insgesamt 720 Stunden.
  30 * 24 = 720
• Jede Stunde der Nutzung kostet 0,03 $.
  $20 / 720 = $0.03
• Deine nächste Rechnung enthält die 0,03 $ für die 1 Stunde, die eine Premium Staging-Umgebung zu deinem Plan hinzugefügt wurde.

Beispiel für die Aufteilung

Du kaufst eine Premium Staging-Umgebung in der Mitte deines monatlichen Abrechnungszyklus und nutzt sie bis zum Ende des Zyklus. Dir wird ein halber Monat der Nutzung berechnet (ca. $10, anteilig).

Kann ich den Namen einer Staging-Umgebung ändern?

Ja. Wechsle zu der Umgebung, die du umbenennen möchtest, und klicke auf das Bearbeitungssymbol (Bleistift) im Feld Umgebungsname.

Gib den neuen Namen ein und klicke auf Umgebung umbenennen.

Dies ändert den Namen der Umgebung, der in der Umgebungsauswahl angezeigt wird, hat aber keine Auswirkungen auf die kinsta.cloud-Domäne, die bei der ursprünglichen Erstellung der Umgebung erstellt wurde.

Kann ich ein Backup in einer Staging-Umgebung wiederherstellen?

Ja, aber du musst zuerst eine Standard- oder Premium-Staging-Umgebung erstellen. In der Vergangenheit war es möglich, bei der Wiederherstellung eines Backups automatisch eine Staging-Umgebung zu erstellen. Mit der Einführung von Premium-Staging-Umgebungen musst du die Staging-Umgebung erst erstellen, bevor du ein Backup wiederherstellen kannst.

Du kannst auch Änderungen von deiner Live-Site auf deine Staging-Site übertragen. Wenn du nur bestimmte Dateien oder Datenbanktabellen aktualisieren möchtest, kannst du einen selektiven Push durchführen.

Wer hat Zugriff auf Premium Staging-Umgebungen?

Website-Entwickler und Website-Administratoren haben Zugriff auf erstellte Premium-Staging-Umgebungen, können aber keine Premium-Staging-Umgebung erstellen oder löschen. Nur ein Unternehmenseigentümer oder Unternehmensadministrator kann eine Premium-Staging-Umgebung erstellen oder löschen.

Beansprucht Staging meinen Speicherplatz?

Nein. Um dir so viel Platz wie möglich zu geben, werden Staging-Sites bei der Berechnung deines gesamten Speicherplatzbedarfs nicht berücksichtigt. Nur Live-Sites werden auf dein Speicherplatzlimit angerechnet.

Wenn ich ein Plugin in der Staging-Umgebung teste und nur die Dateien in die Live-Umgebung übertrage, werden dann die entsprechenden Datenbanktabellen für das Plugin erstellt?

Wenn du ein Plugin auf deiner Staging-Site installierst, das noch nie auf der Live-Site installiert wurde, werden beim Übertragen der Dateien von der Staging- auf die Live-Site keine Datenbanktabellen für das Plugin erstellt.

Das bedeutet auch, dass alle Einstellungen, die du im Plugin vorgenommen hast, nicht in die Live-Site übertragen werden (es sei denn, die Einstellungen sind in einer Datei außerhalb der Datenbank gespeichert, z. B. in einer JSON-Datei).

Je nachdem, wie das Plugin programmiert ist, kann es sein, dass das Aktivieren (und ggf. Deaktivieren) des Plugins auf der Live-Site die Datenbankstruktur erstellt.

Wenn ich nur die Dateien auf die Live-Site übertrage, bedeutet das, dass die alte Datenbank (im Staging) die Live-Datenbank nicht überschreibt und nur die Dateien überschrieben werden?

Ja, wenn nur die Dateien übertragen werden, bedeutet das, dass die Datenbank auf der Live-Site unverändert bleibt und nur die Dateien auf der Live-Site überschrieben werden.

Heißt das, dass ich auf meiner Staging-Site an Designänderungen arbeiten und diese auf die Live-Site übertragen kann, ohne neue Abonnenten oder Kunden auf meiner Live-Site zu verlieren?

Ja, solange du nur Dateien änderst (keine Änderungen im WordPress-Dashboard – einschließlich Plugin-, Theme- oder Customizer-Einstellungen), kannst du diese Änderungen sicher auf die Live-Site übertragen, ohne die Datenbank zu überschreiben. Wenn du die Änderungen live schaltest, wähle Dateien aus und stelle sicher, dass Datenbank nicht ausgewählt ist.

Kann ich WooCommerce-Bestellungen oder -Daten ausschließen oder synchronisieren, wenn ich sie von Staging auf Live übertrage?

Ja, wenn du Staging mit einem selektiven Push in den Live-Betrieb überführst, kannst du nur Dateien übertragen, damit deine Datenbank nicht überschrieben wird, oder du kannst selektiv Datenbanktabellen übertragen und die benötigten WooCommerce-Tabellen ausschließen. Informationen darüber, was die einzelnen WooCommerce-Datenbanktabellen enthalten, findest du in der WooCommerce-Datenbankbeschreibung. Wenn du dir nicht sicher bist, welche Tabellen du pushen sollst, empfehlen wir dir, mit einem Entwickler zusammenzuarbeiten.

Kann ich bei einer Multisite nur eine Website von Staging auf Live umstellen?

Ja, wenn du Staging mit einem selektiven Push in den Live-Betrieb überführst, kannst du wählen, ob du nur die Datenbanktabellen für eine der Unterseiten übertragen willst. Welche Datenbanktabellen in WordPress enthalten sind, erfährst du in WordPress-Datenbank für Einsteiger: Was sie ist und wie man auf sie zugreift. Die Ordner „Plugins“ und „Themes“ werden von allen Websites gemeinsam genutzt, aber der Ordner „Uploads“ kann nach Websites getrennt werden. Du kannst also wählen, ob du nur die Uploads für die gewünschte Subsite pushen willst. Wenn du dir nicht sicher bist, welche Tabellen oder Dateien du pushen sollst, empfehlen wir dir, mit einem Entwickler zusammenzuarbeiten.

Kann ich mit selektivem Push die PHP-Version meiner Website ändern?

Ja, du kannst die Staging-Umgebung nutzen, um eine neue PHP-Version zu testen und in deine Live-Umgebung zu pushen, aber der Vorgang ist nicht notwendig um deine PHP-Version zu aktualisieren. Hier ist ein kurzer Überblick darüber, wie du die PHP-Version ändern kannst, ohne von Staging auf Live zu pushen:

1. Erstelle eine Staging-Site.
2. Gehe zur Staging-Site und ändere die PHP-Version auf der Staging-Site.
3. Wenn alles in Ordnung ist und auf der Staging-Site wie erwartet funktioniert (teste es unbedingt gründlich), ändere die PHP-Version auf der Live-Site.

Ich habe CSS-Änderungen im WordPress-Dashboard vorgenommen und Dateien gepusht. Warum sehe ich meine Änderungen nicht, auch wenn ich den Cache gelöscht habe?

Je nach Art der vorgenommenen Änderungen und dem Ort, an dem diese Informationen gespeichert sind, musst du die Datenbank pushen oder die Änderungen manuell auf der Live-Site vornehmen. Wenn du zum Beispiel CSS in einem Block oder Widget im WordPress-Dashboard hinzugefügt oder bearbeitet hast, wird das wahrscheinlich in der Datenbank gespeichert.

Wenn du etwas im WordPress-Dashboard änderst, werden diese Informationen normalerweise in der Datenbank gespeichert, mit Ausnahme der Änderungen, die du mit dem Theme-Editor (Aussehen > Theme-Editor) vornimmst.

Hinweis: Alle Änderungen an der Datenbank der Live-Site, die seit der Erstellung der Staging-Site vorgenommen wurden, gehen verloren, z. B. Kommentare, neue Inhalte, Einkäufe auf E-Commerce-Seiten, Anmeldungen auf Mitgliederseiten und Forenbeiträge. In diesem Fall empfehlen wir, die gleichen Änderungen manuell auf der Live-Site vorzunehmen, anstatt die Datenbank zu pushen.

Wie funktioniert der selektive Push bei einem Multisite-Netzwerk?

Wenn du mit Selective Push nur die Dateien pushst, funktioniert das unabhängig von der Art des Multisite-Netzwerks. Wenn du nur die Datenbank oder die Datenbank und die Dateien pushst, kann es sein, dass es nicht funktioniert, je nachdem, wie deine Multisite eingerichtet ist:

• Wenn es sich um eine Multisite mit Unterverzeichnissen handelt (example.com, example.com/subsite1, example.com/subsite2), funktioniert Push-to-Live wie erwartet.
• Wenn es sich um eine Subdomain-Multisite handelt (beispiel.com, unterseite1.beispiel.com, unterseite2.beispiel.com), funktioniert es problemlos, vorausgesetzt, die Unterseiten benötigen kein HTTPS.
• Wenn es sich um eine domänenübergreifende Multisite handelt (d. h. verschiedene Unterseiten werden auf völlig unterschiedliche Domänen geladen, z. B. example.com, example1.com, example2.com), wird es ohne umfangreiche manuelle Einstellungen nicht funktionieren.
  • Option 1: Deaktiviere die Domänenzuordnung und gehe zurück zur standardmäßigen Einrichtung von Unterverzeichnissen/Subdomänen. Suche und ersetze manuell in der Datenbank.
  • Option 2: Richte Staging-Subdomains für jede Live-Domain ein, füge sie alle zur Staging-Site hinzu und führe manuelles Suchen und Ersetzen in der Datenbank durch, um jede Domain zu aktualisieren, nachdem du die Staging-Site auf die Live-Site übertragen hast.