Relaunch Strategie

Da ich mit einer großen Website betraut wurde, muss(!) der Relauch möglichst reibungslos ablaufen. Genauer geht es dabei um

• Erstellung eines Child-Themes
• Zahlreiche Einstellungen in Wordpress (Menüs, Permalinks uvm)
• Abschalten und Neuinstallieren von Plugins
• Ersetzen von (zu großen) Bilddateien
• ...

Zum testen werde ich einen Klon der Website auf einer Subdomain installieren. Und während ich die neue Website erstelle, werden auf der alten weiter Inhalte veröffentlicht. Möglicherweise auch Nutzerprofile geändert, gelöscht oder neu angelegt und irgendwelche Plugins mit Daten gefüttert.

Meine Frage ist jetzt: Wie bringe ich am Ende beide Seiten zusammen?

1. Spät in der Nacht alle Dateien im Webspace austauschen.

2. Beim Webhoster das Basisverzeichnis der Domain auf dasjenige, in welchem die Testumgebung läuft, ändern (um das Basisverzeichnis in Plesk ändern zu können muss ich jedoch erst Wordpress deinstallieren).

In beiden Fällen frage ich mich, wie ich mit der Datenbank vorgehen soll. Hier wurden ja in der Zwischenzeit beide Seiten editiert.

Kennt jemand ein gutes Tutorial? Nichts, was ich bisher zum WP-Relaunch gelesen habe, berücksichtigt, dass während der Entwicklungszeit auch auf der alten Seite weiter gearbeitet wird.

Grazie, Merci, Thanks und recht herzlichen Dank an alle!

Hallo b3317133,

das klingt vernünftig. Vor allem weil es relativ sicher sein sollte. Dass Wordpress aus Plesk heraus installiert wurde (von meinem Vorgänger) hat mir auch erstmal Sorgen gemacht. Habe aber gerade entdeckt, dass Plesk da ein paar ziemlich nützliche Funktionen bietet. Nämlich Klonen, Synchronisieren und Wiederherstellen einer Wordpress Instanz. Der werden zB auch gleich Tabellenpräfixe angepasst uvm (vgl). Ich denke ich werde es so machen:

• Klon erstellen (mit Plesk)
• Bearbeitungen am Klon dokumentieren
• Kurz vor dem Relaunch via Plesk synchronisieren mit Klon als Ziel(!) und Originalseite als Quelle(!) (dabei werden aber nur neu erstellte Dateien synchr. - vor allem Bilder)
• Beim Relaunch (nachts) alle Dateien synchronisieren mit Klon als Quelle und Original als Ziel (diesmal geänderte Dateien auf Ziel ersetzen und auf Quelle fehlende löschen)
• Die zu synchronisierenden Tabellen manuell auswählen

Den Zwischenschritt mit dem 2. Klon würde ich mir sparen, weil alles, was im 1. Klon funktioniert im Original ja auch funktionieren sollte (bleibt natürlich ein Restrisiko wegen inzwischen evtl upgedateten Plugins). Außerdem macht es mir immernoch Kopfschmerzen, dass ich Wordpress erst im laufenden Betrieb deinstallieren muss, bevor ich die Domain umschalten kann.

Zitat von r23

Ich würde auch einem Anfänger ein Server-Staging fehlen.

[size=18]Server-Staging für Einsteiger
https://t3n.de/news/server-staging-wordpress-597583/[/SIZE]

Wenn ich den verlinkten Artikel richtig verstanden habe, macht die dort vorgestellte Staging-Lösung nur Sinn, wenn man mit min 3 Instanzen arbeitet. Bei mir ist "Entwickeln" und "Präsentieren beim Kunden" dieselbe WP-Installation (auf demselben Server, wie die Live-Version).

Zitat von b3317133

Alleine schon dieser eine Punkt ist bzgl. Plesk ein "no-go" bzw. nicht nachvollziehbar für mich, ob das wirklich so der Fall ist:

Ja, keine Chance! Wenn Wordpress über Plesk installiert wurde kann das Basisverzeichnis nicht mehr geändert werden.

Zitat von b3317133

Das über Plesk zu machen, halte ich für sehr ambitioniert. Viel Erfolg.

Was genau spricht gegen Plesk? Google mal "wordpress staging guide". Es wird regelmäßig empfohlen, die Staging-Lösung des Hosters zu nutzen. Die Vorteile sind zB

• kein runter- und hochladen nötig
• Datenbank und Subdomain wird automatisch erstellt
• kein editieren der wp-config.php nötig (glaube ich zumindest)
• Wiederherstellungspunkt wird automatisch erstellt
• statt FTP-Client, Editor, phpMyAdmin, Wordpress und Webhosting Panel dürfte nur eine einzige Oberfläche nötig sein

Zitat von b3317133

Die von mir beschriebene Variante zielt darauf ab, dass man jederzeit einen Rollback zum Original machen kann, ... weil das Original unangetastet bleibt.

Der Restore-Point erfüllt denselben Zweck.

Ich finde auch das Mapping der Domains irgendwie eleganter. Aber da das bei mir ohnehin nicht geht, werde ich wohl der Plesk-Klon-Methode mal eine Chance geben.

@b3317133
Nein! Genau das spricht FÜR Plesk. Zumindest in meiner Situation (wenn Wordpress nicht manuell installiert wurde). Wie schon gesagt, kann ich nämlich das Basisverzeichis nicht ändern, was wiederum heißt, ich kann deine Methode so nicht umsetzen.

Eine weitere Idee, um bei Problemen weiter dieses Forum bemühen zu können, wäre:

• Klon erstellen (Duplicator)
• Entwickeln und Testen
• Wordpress via Plesk deinstallieren, um dann die Domain auf ein anderes Basisverzeichnis umschalten zu können

Zitat von r23

Nur auf einer Maschine entwicklen ist unpraktisch und widerspricht dem gelebten Open Source Workflow bei uns.

Auch wenn's nicht ganz der Kern dieses Threads ist - gib mir mal Nachhilfe. Warum unpraktisch? Warum entgegen dem Open Source Workflow?

Zitat von r23

Plesk verwendet und [size=24]empfiehlt [size=14]WordPress Toolkit[/SIZE][/SIZE]

[size=24][size=14][/SIZE][/SIZE]
[size=24][size=14]Das Toolkit läuft ja bei mir. Ich seh da jetzt immernoch kein Argument dagegen...[/SIZE][/SIZE]

Zitat von b3317133

Wenn man alle Dateien in einen neuen Ordner kopiert, die Datenbank in eine neue Datenbank kopiert, dann den Plesk-WordPress-kram löscht, die Domain auf den neuen Ornder setzte und die Datei wp-config.php dort auf die neue Datenbank anpasst, wäre man diese Plesk-Probleme los.

Wenn man denn wollen würde. Wie gesagt, viel Erfolg. Bin hier raus.

Kein Problem. Danke b3317133!

Kann mir dann jemand anderes sagen, um welche "Probleme" es hier überhaupt geht? Datenbank und Dateien mit einem Klick zu synchronisieren klingt für mich immernoch viel einfacher. Die Prozedur mit Duplicator und Search & Replace habe ich selbst schon durch und so ganz ohne ist das auch nicht. Zumindest wenn man es nicht regelmäßig macht und sich immer wieder einlesen muss.