Hi, hier ist Niels von 7BizWorks mit einer neuen Podcast-Folge. Heute: Clone und Staging.
Eine Staging-Seite ist eine Entwicklungsebene deiner Live- oder sagen wir Production-Seite. Im besten Falle hast du hier eine 1-zu-1-Kopie mit dem aktuellen Stand deiner Production-Seite. Das ist hervorragend zum Testen von neuen Einstellungen oder neuen Funktionen, bevor diese überhaupt deine Production-Seite erreichen. Das ist sehr praktisch, weil du dadurch Fehler auf deiner Live-Seite reduzieren kannst. Im besten Falle testest du nicht eine neue Funktion auf deiner Live-Seite, wo eventuell schon echte Kunden unterwegs sind, echte User sich durch deine Kurse arbeiten, und du nimmst dann eine Änderung vor, und für die ist auf einmal alles anders oder funktioniert sogar nicht.
Aber was macht Staging so besonders? Die Staging-Seite ist mit deiner Production-Seite direkt verknüpft, also direkt verbunden, und du kannst deine Files und die Datenbank pushen von deiner Staging-Seite zu deiner Production-Seite und natürlich auch umgekehrt. Der normale Verlauf wäre, dass du auf deiner Staging-Seite die gesamte Entwicklung durchführst, und wenn du dann fertig bist mit dieser Testumgebung, alles funktioniert und alles perfekt eingestellt ist, dann pusht du diese gesamten Daten, also alle Plugin-Files, alle Einstellungen von WordPress, das gesamte Design und die dazugehörigen Datenbanken zu deiner Live-Seite.
Aber hier können drei reale Probleme entstehen. Denn mit einem Push von deiner Staging-Seite auf deine Live-Seite könntest du wichtige Daten überspielen. Und ich gebe dir hier drei Beispiele.
Erstens: Newsletter-Anmeldungen, die bereits auf deiner Live-Seite existieren. Also dort hast du 100 User, die sich schon für deinen Newsletter angemeldet haben und aktiv dabei sind, erhalten von dir regelmäßig E-Mails. Wenn du jetzt Änderungen auf der Staging-Seite durchführst, inklusive der Datenbank, wo auch diese 100 User liegen, dann sind diese 100 User auf beiden Seiten, auf deiner Production-Seite und auf deiner Staging-Seite. Und jetzt arbeitest du weiter an deiner Staging-Seite, an deiner Entwicklungsebene, bringst neue Plugins rein, machst neue Einstellungen, und während du arbeitest, sagen wir mal für drei Tage, hast du fünf neue Anmeldungen auf deiner Live-Seite. Und deine Staging-Seite weiß davon nichts. Die kennt diese neuen Anmeldungen nicht. Wenn du jetzt von deiner Staging-Seite wieder zurückpusht auf deine Live-Seite, dann werden dort auf der Live-Seite die neuen Anmeldungen gelöscht. Das heißt, sie gehen einfach verloren, weil sie von der Staging-Datenbank überschrieben werden.
Jetzt stell dir das mal vor mit Kaufvorgängen. Also Kunden, die bereits bezahlt haben, aber die Datenbank auf der Staging-Seite kennt die gar nicht. Die weiß nicht, welche Zugriffe die haben, oder im schlimmsten Falle nicht mal, dass überhaupt ein Zahlungsvorgang stattgefunden hat, und du kannst das überhaupt nicht mehr zuweisen in deinem System, weil auch auf der Live-Seite weißt du nicht mehr, wer was gekauft hat. Die User haben keinen Zugriff mehr, und du kannst deine Zahlungsvorgänge nicht mehr korrekt zuordnen.
Ein anderes Beispiel wären Plugin-Lizenzen. Und das ist eine reale Gefahr, denn diese Lizenzen werden meistens in der Datenbank gespeichert. Auch hier pusht du zum Beispiel deine aktuelle Live-Seite zur Staging-Seite, fügst ein neues Plugin hinzu und aktivierst eine neue Lizenz. Davon weiß erstmal deine Live-Seite nichts. Jetzt spielst du wieder die Daten zurück, und hier kann es zu Konflikten kommen, weil die Lizenz nicht weiß, gehöre ich jetzt zur Live-Seite oder zur Staging-Seite. Man kann dann manuell die Lizenzen wieder austauschen, aber der Aufwand kann nervig und zeitintensiv sein.
Ein drittes Beispiel wäre Automation, denn auf deiner Live-Seite hast du eventuell schon Automationen laufen, und jetzt pusht du von der Live-Seite zur Staging-Seite, und die Automation weiß natürlich nicht, dass es noch eine Live-Seite gibt. Dann laufen diese Automationen ebenfalls auf der Staging-Ebene durch, weil das eine 1-zu-1-Kopie deiner Seite ist. Das heißt, du hättest dann eine doppelte Ausführung. Deine E-Mail-User würden dann doppelte E-Mails bekommen, das kann natürlich zu Verwirrung führen, oder du erhältst Problemmeldungen, warum du dauernd doppelte E-Mails verschickst, oder dein gesamtes E-Mail-Kontingent wird dadurch doppelt belastet. Im schlimmsten Fall landen dann deine E-Mails im Spam, weil User sagen, ich kriege doppelte E-Mails von dir. Es ist eher unwahrscheinlich, dass deine E-Mails dann als Spam eingestuft werden, aber es ist nicht gänzlich auszuschließen.
Also muss man mit Staging-Umgebungen sehr vorsichtig umgehen, damit hier keine Daten gelöscht werden oder doppelte Daten für Automationsvorgänge genutzt werden.
Aber es gibt zwei Alternativen, wie du eine Staging-Seite oder eine Entwicklungsebene nutzen kannst.
Die erste Variante ist, dass du eine Staging-Umgebung nutzt, aber immer nur von der Live-Seite zur Staging-Seite pushst. Das schließt erstmal eine Komplikation auf der Production-Seite aus. Wenn du keine Daten von Staging nach Live schickst, dann kannst du keine Daten löschen, überspielen oder irgendwelche Automationen durcheinanderbringen. Allerdings hast du hier immer noch das Problem, dass du auf der Staging-Ebene diese doppelten Automationen auslösen könntest. Hier musst du also immer noch aufpassen, und die Staging-Ebene muss so eingerichtet sein, dass sie diese Daten auch vernünftig empfängt. Entweder musst du das im Vorfeld einrichten, oder über bestimmte Server-Tools, die dir dein Hoster anbietet, oder du weißt genau, wie du selbst eine Staging-Ebene erstellst, sodass diese Verbindung wirklich 1-zu-1 zu deiner Live-Seite ist.
Es gibt auch Plugins, die das anbieten, dass du aus deiner Live-Seite eine Staging-Ebene entwickelst, die dann auf deinem Webspace installiert wird. Allerdings kann das auch zu Problemen führen, denn wenn deine Testumgebung im selben Installationsordner auf deinem Webspace liegt, dann hast du quasi zwei Seiten auf deinem Server, und wenn du dann ein Backup machst oder es zu Problemen kommt, kann es sein, dass du beide Seiten beeinträchtigst. Im schlimmsten Fall löst du einen Fehler auf deiner Staging-Umgebung aus, weil du etwas testen möchtest, und das beeinflusst dann auch deine Live-Seite. Also ist auch das mit großer Vorsicht anzugehen.
Die sicherste Alternative für eine Entwicklungsebene ist eine Klon-Seite, also eine 1-zu-1-Kopie, die du einmal von deiner Live-Seite exportierst und auf eine frische WordPress-Installation importierst. Der Nachteil ist, dass du einen manuellen Export vornimmst und auch manuell importierst. Es kann zeitaufwendiger sein, du drückst nicht nur einen Knopf und die Daten werden rüberkopiert, sondern musst erst exportieren, die Daten im Zweifel runterladen, dann wieder auf die neue Seite hochladen, auf die Entwicklungsebene, und dort wieder installieren.
Wenn du hierfür bestimmte Tools nutzt, es gibt zum Beispiel das Backup-Tool WP-Vivid, dort kannst du genau definieren, was du exportieren möchtest, und bei der Import-Einstellung, was du ganz konkret wieder importieren möchtest. Du kannst zum Beispiel Plugins ausschließen oder bestimmte Datenbanken, die du gar nicht erst auf die Entwicklungsebene raufspielen möchtest. Das ist alles manuell einstellbar, etwas aufwendiger, aber definitiv sicherer, sodass du auf der Staging- und auf der Production-Seite keine Probleme auslöst, die sich gegenseitig beeinflussen. Es ist quasi eine sichere, manuelle Staging-Umgebung.
Ich habe für mich alle Möglichkeiten getestet, und da ich selbst einen Self-Management-Server nutze, gab es für mich die Möglichkeit, mit dem Management-Tool eine Staging-Umgebung quasi bei der Installation festzulegen. Ich habe das getestet, aber für mich war das auch noch nicht so optimal, denn auch da gab es immer noch Komplikationen, dass es eben nicht nur ein Knopfdruck ist und alles funktioniert, sondern man musste noch viele extra Einstellungen vornehmen und trotzdem immer aufpassen.
Für einen Webentwickler oder Webdesigner, der 10, 20 Seiten bedient, entwickelt und am Laufen hält, ist eine Staging-Umgebung sicherlich die beste Variante und die beste Lösung, weil der einmal klickt und die Daten dort hat, wo er sie haben möchte, und dann schnell weiterarbeiten kann. Für uns als Kurs-Admin, für unsere eigene Seite, ist eine Staging-Seite eher zu komplex und übertrieben, nach meiner Ansicht.
Ich für meinen Teil benötige meine Live-Seite und dazu zwei Entwicklungsebenen. Die zweite Entwicklungsebene habe ich offline, aber auch nur, weil ich auf dieser Ebene meine Plugins weiterentwickle. Würde ich keine Plugins entwickeln, hätte ich diese Ebene auch nicht, sondern nur eine Live-Seite und eine Test-Seite, beide online.
Für mich ist nach wie vor die einfachste Variante, mit dem Plugin WP-Vivid einen Export von der Live-Seite zu machen und diesen dann auf meine Entwicklungsebenen manuell zu importieren. Dann kann ich ohne Sorge, dass die Live-Seite beeinträchtigt wird, meine Plugins entwickeln und auf der Online-Entwicklungsebene wirklich noch einen Live-Test machen, bevor ich meine Live-Seite aktualisiere. Dennoch kann hier hin und wieder mal etwas mit Plugin-Lizenzen aufkommen, sodass eine Seite sagt: Moment, ich gehöre doch eigentlich zur Live-Seite, bitte aktualisiere deine Plugin-Lizenz auf deiner Entwicklungsebene. Dann macht man das einfach manuell. Aber es ist immer noch gut, dass ich mich nicht darum kümmern muss, welche Datenbankgeschichten möglicherweise überspielt werden. Diesen Fehler kann ich komplett ausschließen. Allerdings muss ich immer noch aufpassen, was Automation angeht. Also Newsletter-Geschichten, die automatisiert laufen, oder bestimmte Vorgänge, wenn ein User einen bestimmten Abschnitt im Kursverlauf abgeschlossen hat und dann automatisch eine E-Mail versendet wird — das schalte ich auf jeden Fall ab.
Ich möchte dir jetzt noch einen kurzen Einblick geben, wie ich das gesamte System für mich aufgebaut habe, als ich mit 7BizWorks gestartet bin. Ich habe auf einer lokalen Umgebung, mit einem Tool namens LocalWP — damit kannst du auf deinem Computer eine Serverumgebung simulieren und dann lokal WordPress nutzen — meinen gesamten Grundstein aufgebaut. WordPress installiert, die Plugins, die ich nutze, und dann die grundlegende Gestaltung, wie die Webseite aussehen soll und welche Funktionen bestehen können. Auch auf dieser Ebene, wie schon erwähnt, entwickle ich meine eigenen Plugins weiter.
Ab dem Zeitpunkt, wo ich wusste, so soll der Grundaufbau aussehen, habe ich diese lokale Webseite komplett nochmal frisch auf der kommenden Live-Seite neu aufgebaut. Ohne die ganzen komplexen Tools, ohne Kursautomation, ohne Newsletter — das kommt alles erst später — sondern wirklich diesen kompletten Grundstein manuell 1-zu-1 nachgebaut. Kein Import, kein Export. So kann ich für mich sicherstellen, dass die Live-Seite frisch läuft, ohne irgendwelche Altdaten oder Testdaten, sondern komplett neu aufgesetzt.
Und wenn die Live-Seite dann steht, folgt ein 1-zu-1-Export von der Live-Seite, und ich erstelle eine neue Entwicklungsebene online. Dort erfolgt dann der Import dieses frischen Grundaufbaus. Ab diesem Zeitpunkt habe ich also drei Seiten: eine Live-Seite, eine Online-Seite als Entwicklungsebene und eine lokale Entwicklungsebene. Und ab diesem Zeitpunkt ist der weitere Entwicklungsschritt immer derselbe: Ich teste erst auf der lokalen Ebene, baue das dann auf der Online-Entwicklungsebene nach, und wenn ich weiß, das funktioniert auch online alles super, baue ich es einmal auf der Live-Seite. Und wenn die Live-Seite sich weiterentwickelt, mit mehr Content und mehr Daten, dann kann ich dort immer einen manuellen Export machen und diesen auf die Online-Entwicklungsebene importieren, und habe dort dann immer wieder den aktuellen Stand, wo ich neue Sachen online testen kann.
Ja, das ist sehr viel manuell und wenig Ein-Klick-Lösung, aber so kann ich total entspannt und sicher sein, dass alles frisch auf der Live-Seite liegt und nicht durch einen ungewünschten Push oder überschriebene Daten auf der heiligen Live-Seite beeinträchtigt wird. Und wie schon erwähnt, gibt es nur noch einen Teil, auf den ich wirklich achten muss, und das ist die Automation vom E-Mail-Versand. Also stelle ich sicher, dass ich beim Export mein SMTP-Plugin, das für den Versand der E-Mails zuständig ist, gar nicht erst exportiere oder importiere. Im Zweifel könnte man es auch mit importieren und als ersten Schritt beim Besuch der Seite sofort dieses Plugin deaktivieren, sodass kein doppelter E-Mail-Versand entsteht. Welche Automationen dann im Hintergrund ablaufen auf der Entwicklungsseite, ob online oder lokal, ist völlig egal, solange keine E-Mails rausgehen oder Zahlungsvorgänge unterbrochen werden. In diesem Fall auch nochmal der Hinweis: Wenn du Automationen laufen hast, die über ein Shop-System laufen, musst du natürlich auch darauf achten, dass dort nicht irgendwelche Webhooks geschickt werden, die eventuell einen Zahlungsvorgang canceln, den du auf der Entwicklungsebene auslöst. Hier einfach einen Cut machen — für die Entwicklung ist das für mich der entscheidende Punkt, dass dort nichts abläuft, was von der Live-Seite abhängig ist.
Und wenn du mir bis hierhin gefolgt bist, dann fragst du dich eventuell: Brauche ich das denn alles überhaupt für meine Kursplattform? Was ich dir empfehlen kann: Wenn du einem Fahrplan folgst, zum Beispiel aus einem Kurs wie dem, den ich mit 7BizWorks aufbaue, oder du besuchst einen anderen Online-Kurs, wie man etwas erstellt, dann hat derjenige hoffentlich schon ganz viel Vorarbeit geleistet und gibt dir ein System an die Hand, das funktioniert. Dann benötigst du eventuell nicht mal eine Testseite, sondern kannst das 1-zu-1 nachbauen und erstmal testen, bevor du in Betrieb gehst, und bist dann auf einer relativ sicheren Seite. Wenn du wenig Erfahrung hast, dann ist eine Online- oder auch Offline-Entwicklungsebene nicht verkehrt, alleine für den Grundaufbau, um dich damit vertraut zu machen, dass du dort alle Fehler machen kannst, die später auf einer Live-Seite nicht mehr mithängen. Also, dass du keine Testdaten oder falschen Einstellungen mit übernimmst auf die Live-Seite.
Weißt du also schon ein bisschen mehr über WordPress, Plugins und Einstellungen, dann bau deine Webseite auf deiner richtigen Live-Domain auf, versteckt, im Maintenance-Mode, und dann heißt es testen, testen, testen. Auch wenn du einem Fahrplan folgst, aber vor allem, wenn du davon abweichst. Und das ist völlig legitim — nicht alles, was ich dir erzähle oder was andere dir aus deren Erfahrung vorschlagen, passt vielleicht für dich. Deswegen ist WordPress so schön, weil wir alle flexibel arbeiten können und hier und da doch etwas anderes nutzen oder eine andere Einstellung vornehmen können. Aber dann ist es umso wichtiger, dass du ganz strukturiert durchtestest, wie und ob das wirklich so funktioniert, wie du das möchtest.
Und bist du dann später im laufenden Betrieb und möchtest deine Kursplattform anpassen, eine neue Funktion hinzufügen — nehmen wir als Beispiel mal einen Podcast, den du auf deiner Kursplattform mithosten möchtest — dann ist das schon eine größere Umbauaktion, und dann ist es wirklich sinnvoll, einen Export deiner Live-Seite zu machen und eine neue Entwicklungsebene zu erstellen. Dort lädst du dann deine aktuelle Live-Seite hoch und kannst in Ruhe dein Podcast-Hosting testen, bevor es wirklich auf die Live-Seite geht. Und nach wie vor meine Empfehlung: Teste alles auf der Entwicklungsebene, probiere aus, wie du das System eventuell crashen kannst, was du auf gar keinen Fall dann auf der Live-Seite machen darfst. Und dann baust du das 1-zu-1 nach, die funktionalen Einstellungen natürlich. So kannst du alles ausprobieren, was du willst, ohne dass deine Live-Seite davon beeinträchtigt wird.
Und kommst du doch dahin, dass du sagst, ich möchte eine richtig reguläre Staging-Umgebung haben, die mit einem Klick Daten von der einen Seite zur anderen pusht, dann informiere dich vorab ganz genau. Erstmal bei deinem Hosting-Anbieter, wenn du nicht selbst deinen Server managst, sondern bei einem Web-Hosting-Anbieter bist: Schau nach, ob die dir ein Tool anbieten, mit dem du eine Staging-Umgebung installieren kannst, die dann mit deiner Live-Seite verknüpft ist. Aber denke daran: Push niemals von der Staging-Umgebung zur Live-Seite. Niemals. Dann bist du hundertprozentig sicher, dass keine Live-Daten überschrieben werden.
Meine letzte Empfehlung für heute: Mach nichts ohne ein sicheres Backup. Backups sind eins der wichtigsten Dinge, die du mit einplanen solltest, aber das würde den Themenrahmen für heute sprengen — das ist ein Thema für eine andere Folge.
Also: Staging-Umgebung oder 1-zu-1-Klon. Ich bevorzuge den 1-zu-1-Klon, manuelles Exportieren, manuelles Importieren, mit der Entscheidung, was überhaupt auf die Entwicklungsebene rauf soll, womit ich testen will, und immer aufpassen auf Automation und Plugin-Lizenzen, dass diese vernünftig angelegt sind oder gegebenenfalls einmal manuell eingestellt bzw. die Automation deaktiviert wird.
Ich hoffe, ich konnte dir das Thema jetzt etwas näherbringen und dir vielleicht etwas Druck nehmen, sodass du dir sagen kannst: Ey super, ich kann das erstmal offline oder online auf einer Testumgebung alles testen, ohne dass ich meine spätere Live-Seite mit Testdaten, falschen Einstellungen oder Plugins zumülle, die ich vielleicht testen möchte, aber später merke, brauche ich gar nicht. Und wenn man sie dann löscht, bleiben eventuell noch Daten hängen — je mehr Plugins man installiert und testet, desto mehr Daten bleiben in der Datenbank hängen, die man eventuell selbst erst manuell löschen müsste, bevor die Webseite wirklich aufgeräumt ist. Und das erspart man sich einfach, indem man eine Testumgebung hat und erst später auf der Live-Seite wirklich die Sachen einstellt und installiert, für die man sich hundertprozentig entschieden hat, weil man merkt: Super, die funktionieren, die harmonieren zusammen, und das bleibt der Live-Seite vorbehalten.
