Jede WordPress-Installation bei Kinsta kann über eine eigene Staging-Umgebung verfügen, die sich vollständig von deiner Live-Produktionsstätte unterscheidet. Dies ist ideal, um neue WordPress-Versionen, Plugins, Code und allgemeine Entwicklungsarbeiten zu testen. Erstelle in wenigen Minuten eine Entwickler-Seite und teile sie mit deinem Team.

Erstelle eine WordPress-Staging-Umgebung

Das Erstellen einer Staging-Seite ist denkbar einfach. Klicke einfach in der linken Navigation auf “Sites (Seiten)”. Du siehst eine Liste deiner Seiten / Installationen. Klicke auf das, zu dem du einen Staging-Bereich hinzufügen möchtest. Klicke oben rechts im Dropdown-Menü auf “Staging” und dann auf die Schaltfläche “Create a Staging Environment (Staging-Umgebung erstellen)”.

Staging-Umgebung

Staging-Umgebung

Die URL-Struktur für jeden Staging-Bereich sieht folgendermaßen aus: https://staging-sitename.kinsta.cloud. Wenn du SSL auf deiner Live-Site aktiviert hast, wird SSL auch auf deiner Staging-Seite aktiviert.

Unser ates Format war https://staging-sitename.kinsta.com. Wenn du eine ältere Staging-Seite hast, wird dieses Format möglicherweise weiterhin verwendet.

Bitte warte 10-15 Minuten, bis das Staging erstellt wurde und sich DNS verbreitet. Du erhältst dann ein separates Control Panel mit deinen Verbindungsinformationen, DNS, Backups, Tools und Plugins für deine Staging-Umgebung. Du kannst phpMyAdmin direkt im Dashboard starten. Die URL-Struktur für den phpMyAdmin-Staging-Bereich sieht folgendermaßen aus: https://mysqleditor-staging-sitename.kinsta.cloud.

WordPress Staging-Seite

WordPress Staging-Seite

Staging-Umgebung löschen und aktualisieren

Du kannst deine Staging-Seite dann ganz einfach entfernen, indem du im Dashboard auf „Delete Staging Environment (Staging-Umgebung löschen)“ klickst. Wenn du eine Staging-Seite löschst, werden alle ihre Daten, einschließlich der Databases und Dateien, vollständig entfernt. Um diese Umgebung zu löschen, gib den Seiten-Namen ein, gefolgt von einem Bindestrich und dem Wort „Staging“ (SITENAME-staging) im Feld darunter, und klicke dann auf die Schaltfläche „Delete This Environment (Diese Umgebung löschen)“.

Um deine Staging-Umgebung zu aktualisieren, löschst du sie einfach und erstellst eine neue. Diese enthält dann die neueste Version deiner Produktionsdatabase und die zu testenden Dateien. Oder du kannst von deiner Produktionsseite auf Staging ein Backup wiederherstellen.

Lösche WordPress Staging-Seite

Lösche WordPress Staging-Seite

Staging zu Live

Wenn du deine Staging-Seite Live haben möchtest, kannst du die Funktion push staging to live verwenden.

Stelle WordPress Backup auf Staging wieder her

Du kannst deine WordPress-Seite auch einfach aus einem Backup wiederherstellen und direkt in deine Staging-Umgebung übertragen. Schau dir an, wie du ein WordPress-Backup in Staging wiederherstellen kannst.

Hinweis: Wenn Sie eine Live-Sicherung auf Staging zurücksetzen, bleiben alle Staging-Sicherungen erhalten.

Starte die Staging-Umgebung neu

Wenn deine Staging-Umgebung aus irgendeinem Grund angehalten wird, wird möglicherweise der folgende Fehler angezeigt: 501 not implemented.

501 Not Implemented Fehler

501 Not Implemented Fehler

Auf der Registerkarte Info deiner Website siehst du die Option „Staging-Umgebung starten“.

Starte Staging-Umgebung

Starte Staging-Umgebung

Wichtige Hinweise bezüglich Staging

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

1. Caching auf Staging-Seiten ist deaktiviert.

Aufgrund der Tatsache, dass Staging-Umgebungen für Entwicklungszwecke, zum Debuggen und Testen vorgesehen sind, ist das Caching deaktiviert. Wenn du versuchst, Website-Geschwindigkeitstests durchzuführen, werden überdurchschnittliche Ladezeiten angezeigt, da die Seiten nicht aus dem Cache bereitgestellt werden.

2. Staging-Umgebung Referenzen

Da es sich bei der Staging-Umgebung lediglich um eine Kopie deiner Produktionsseite handelt, sind deine WordPress-Administratoranmeldeinformationen sowohl für deine Live-Seite als auch für deine Staging-Seite identisch. Es sei denn, du änderst sie nachträglich.

Haben Sie mit Ausfallzeiten und WordPress-Problemen zu kämpfen? Kinsta ist die Hosting-Lösung, die Ihnen Zeit spart! Sieh dir unsere Features an

3. SEO

Bei Staging-Seiten ist die Indizierung standardmäßig deaktiviert, damit die SEO auf deiner Live-Produktions-Seite nicht beeinträchtigt wird. Unter „Reading (Lesen)“ in den Einstellungen des WordPress-Dashboards deines Stagings wird die Sichtbarkeit der Suchmaschine überprüft. Diese Einstellung fügt den folgenden HTTP-Header zu deiner WordPress-Seite hinzu. x-robots-tag:noindex, nofollow, nosnippet, noarchive

Indizierung auf Staging-Seiten ist deaktiviert.

Indizierung auf Staging-Seiten ist deaktiviert.

Kinsta-URLs temporäre URLs verfügen außerdem über eine roboterbeschränkende robots.txt. Dies bedeutet, dass die URLs staging-sitename.kinsta.com von den Suchmaschinen nicht indiziert werden.

4. Plugins

Wenn du Social Scheduling-Plugins wie CoSchedule oder Social Networks Auto Poster verwendest, wird empfohlen, diese Plugins auf deiner Staging-Seite zu deaktivieren. Andernfalls werden sie möglicherweise über deine Staging-URL für soziale Netzwerke freigegeben: https://staging-sitename.kinsta.cloud. Dies könnte dann deine Analysen verzerren.

Das Jetpack-Plugin wird in Kinsta-Staging-Umgebungen automatisch im Staging-Modus ausgeführt. Du siehst eine Benachrichtigung: „Du führst Jetpack auf einem Staging-Server aus.“ Im Staging-Modus verhält sich deine Staging-Seite in nahezu jeder Hinsicht wie deine Produktionsseite, außer dass keine Daten an WordPress.com übergeben werden und du die Staging-Seite nicht trennen kannst (um ein Problem zu vermeiden, das zu Problemen mit deiner Produktionsseite führen würde).

5. Notiere dir deine Login-URL

Wenn du ein WordPress-Plugin verwendest, das deine Standard-Login-URL ändert, wird diese auf die Staging-Seite kopiert. Beispiel: http://staging-sitename.kinsta.cloud/yourcustomlogin

6. Staging sollte nur für Entwicklungs- / Testzwecke verwendet werden

Die Staging-Umgebung sollte nur zum Entwickeln und Testen verwendet werden. Sie sind nicht für die Verwendung als Live-Produktionsseiten vorgesehen, und es wird Dinge geben, die nicht richtig funktionieren. Kinsta ist nicht verantwortlich, wenn du versuchst, Staging für eine Live-Seite zu verwenden.

7. Vom Gesamtplan ausgeschlossener Speicherplatz

Um dir so viel Speicherplatz wie möglich zur Verfügung zu stellen, werden Staging-Seiten bei der Berechnung deines gesamten Speicherplatzes von der Berichterstellung ausgeschlossen. Nur Live-Seiten werden für deine Speicherplatznutzung berücksichtigt.

8. Multisite

Je nachdem, wie deine Multisite eingerichtet ist, funktioniert sie möglicherweise nicht mit unserer Staging-Umgebung.

  • Wenn es sich um ein Unterverzeichnis mit Multisite handelt (example.com, example.com/subsite1, example.com/subsite2), funktioniert es problemlos mit unserer Staging-Umgebung.
  • Wenn es sich um eine Subdomain-Multisite handelt(example.com, subsite1.example.com, subsite2.example.com), funktioniert es einwandfrei, sofern für die Subwebsites kein HTTPS erforderlich ist. Wenn für die Subwebsites HTTPS erforderlich ist, musst du SSL-Fehler beim Staging umgehen, um auf die Subwebsites zuzugreifen. Dies hat keinerlei Auswirkungen auf die Funktionalität.
  • Wenn es sich um eine domainzugeordnete Multisite handelt (lädt verschiedene Subwebsites in völlig verschiedenen Domänen, d. H. example.com, example1.com, example2.com), funktioniert es nicht ohne signifikante manuelle Einrichtung.
  • Option 1: Deaktiviere die Domainzuordnung, und kehre zur Standardeinstellung für das Subverzeichnis / die Subdomain zurück. Führe eine Suche durch und ersetze sie manuell in der Database.
  • Option 2: Richte für jede Live-Domain Staging-Subdomains ein, füge alle diese zur Staging-Seite hinzu und führe eine Suche und Ersatz in der Database manuell durch.
7
Mal geteilt