Testumgebung verknüpfen

Eigentlich ist WordPress so konzipiert, dass du eine Instanz auf dem Webserver deines Webhosters installierst und dort direkt anfängst, Beiträge und Seiten zu schreiben und veröffentlichen. Eine Entwicklungsumgebung mit Staging und Deployment ist eigentlich nicht vorgesehen. Um die Webseiten nur einem eingeschränkten Kreis zugänglich zu machen kannst du Plugins wie Password Protected oder Registered Users Only nutzen. Die meisten Websites für Klein- und Mittelständige Unternehmen, bei denen nichts entwickelt werden muss, setze ich so direkt auf dem Server des Kunden auf.

In Einsteigerkursen empfehle ich gerne, erst einmal in einem lokalen Webserver (z.B. Bitnami mit WordPress-Installer) mit WordPress zu spielen und auszureizen, was ohne Plugins und Themes möglich ist, dann populäre Plugins auszuprobieren und sich so heranzutasten, was den eigenen Wünschen und Vorstellungen entspricht und mit vertretbarem Aufwand realisierbar ist. Ich weiß aber, dass sich gerade Einsteiger schwer tun, ihre fertige Website zu übertragen (wobei wir nicht von einer laufenen Synchronisation sprechen, sondern einer einmaligen Übertragung). Mir persönlich fällt das mit dem Backup-Plugin UpdraftPlus WP Backup am leichtesten. Einige Nutzer verwenden lieber Duplicator, mit dem sich ebenfalls bequem WordPress-Websites klonen lassen (sofern der Zielserver keine einschränkenden Serverkonfigurationen hat).

Grundsätzlich kannst du eine Übertragung von Entwicklungs- auf den Zielserver und von dort aus wieder auf den Entwicklungsserver auch manuell vornehmen, in dem du jeweils das Verzeichnis wp-content per FTP oder SSH (bzw. rsnyc) überträgst, die Datenbank exportierst und wieder importierst und bei Bedarf mit dem Plugin Better Search Replace oder über das Kommandozeilentool WP-CLI die URL in der Datenbank ersetzt. Das lässt sich mit Skripten sehr weit automatisieren.
(Wenn du in der wp-config.php auf dem lokalen Server die Konstanten

define('WP_SITEURL, 'http://localhost'); 
define('WP_HOME', 'http://localhost');

setzt, kannst du die Datenbank sogar importieren, ohne sie weiter anzupassen, da die Konstanten die Datenbankeinträge überschreiben.)

In Agenturen, in denen vielleicht auch meherere Entwickler an der gleichen Website arbeiten, reicht das so nicht aus. Hier wird eher eine einheitliche Arbeitsumgebung geschaffen, z.B. in Form von Docker-Containern (vereinfach gesagt einer virtualisierten Arbeitsumgebung, die nach einem individuellen Skript aus Bausteinen zusammengesetzt wird). Die Ergebnisse werden dann über eine Versionskontrolle (meistens Git, seltener SVN) auf einen gemeinsam zugänglichen Server (Github, Bitbucket, ein lokaler Gitea-Server) gepusht und können dort auch vom Zielserver über Cron-Jobs automatisiert abgerufen werden. Hört sich alles ein wenig komplizierter an, ist es auch und deshalb wahrscheinlich für kleinere Jobs etwas übers Ziel hinausgeschossen.

Puh, alles etwas viel … also nochmal zusammenfassend die Möglichkeiten:

1. gar nicht, sondern direkt auf dem Zielserver arbeiten
2. lokal die Website aufsetzen und per Backup/Restore auf dem Zielserver wiederherstellen
3. manuell (bzw. mit Skripten) die Webseiten über SFTP bzw. SSH übertragen
4. gemeinsame Arbeitsumgebungen schaffen, Arbeit per Versionskontrolle (Git) auf einem zentralen Staging-Server sammeln und dann auf den Zielserver übertragen. Dadurch wird eine Zusammenarbeit ermöglicht, was aber mit mehr Aufwand verbunden ist.

Wenn dich wirklich interessiert, wie du mit Staging-Servern arbeiten kannst, findest du auf WordPress.tv interessante Vorträge: https://wordpress.tv/tag/staging-environment/ Den deutschen Kurzvortrag von Christoph findest du auch dort: Christoph Daum: Lightning Talk – Friends will be friends – Dev, Staging und Live als Team

Hallo,
in der Regel führe ich Änderungen in unserer lokalen Entwicklungsumgebung (Laragon) durch. Nachdem ich die Änderungen ausgiebig getestet habe, übertrage ich die entsprechend geänderten Dateien und Scripte ggfs. noch mal auf eine Testumgebung auf dem Server. Da wird dann auch noch mal getestet und danach erfolgt die Übertragung auf die produktive Seite.
Zusätzlich werden sämtliche Dateien und Scripte (insbesondere von Child Themes, Plugins) auf github übertragen und dokumentiert. Damit habe ich dann eine vernünftige Versionierung und kann immer nachsehen, was ich da genau geändert habe.
Insbesondere die lokale Entwicklungsumgebung ist Gold wert. Gerade habe ich auf meiner Entwicklungsumgebung z. B. zusätzlich PHP 8 installiert, um zu sehen, welche Themes und/oder Plugins Probleme machen. Da kann man im Voraus schon sehen, was passieren könnte (und noch lange nicht jedes Plugin läuft unter PHP 8). Wenn auf einer lokalen Entwicklungsumgebung was schief läuft, ist das kein Problem, weil ich notfalls bei irreparablen Schäden die WordPress-Instanz lokal einfach wieder relativ flott neu aufsetze.
Viele Grüße
Hans-Gerd