Eigentlich ist WordPress so gedacht, dass es installiert und mit Themes und Plugins an die eigenen Wünsche angepasst wird und dann direkt auf dem Webserver Inhalte erstellt und veröffentlicht werden.
Wenn du ein größeres Projekt entwickeln möchtest, kannst du das auch in einer Entwicklungsumgebung (lokaler Webserver, eigener Server) machen und die fertige Installation dann übertragen. Dabei müssen die Website- und WordPress-Adresse und die absoluten URLs für Links und Mediendateien angepasst werden. Dazu gibt es inzwischen diverse Tools, z.B. Duplicator, WP Migrate DB oder das Skript von Interconnectit. (Du kannst übrigens nicht direkt in der SQL-Datei mit einem Editor die alten durch die neuen URLs ersetzen, weil die URLs teilweise als serialisierte Daten vorliegen, d.h. es sind mehrere Daten in einem Datenfeld, getrennt durch eine Zahl, die die Länge der jeweiligen Zeichnketten angibt. Änderst du die URL und die Länge der Zeichenkette stimmt nicht mehr, gerät das Datenfeld durcheinander. Die o.g. Tools berücksichtigen das aber.)
Wenn der Umzug einmal abgeschlossen ist, finden alle weiteren Änderungen (Updates von Theme, Plugins, WordPress selbst, neue Beiträge oder Seiten) direkt in der Website. Jedesmal erneut die Website zu übertragen ist in den meisten Fällen zu umständlich.
Ich habe auch schon Entwicklungsumgebungen gesehen, bei denen WordPress, Themes und Plugins, aber auch die Datenbankinhalte in einem GitHub Repository liegen. Auf der lokalen Entwicklungsumgebung wird ein neuer Branch angelegt, Änderungen getestet und mit dem Hauptstamm zusammengeführt (merge), dann zum Repository hochgeladen (push). Auf dem Zielserver läuft ein Cronjob, der regelmäßig Änderungen mit „pull“ aus dem Repository übernimmt. Dabei wird natürlich darauf geachtet, dass keine vertraulichen Informationen im Repository landen.
Hört sich schon kniffeliger an, ist auch nicht für den normalen Anwender bzw. die normale Website gedacht. Es gibt aber WordPress-Installationen, bei denen Fehler schnell teuer werden können, etwa wenn bei einem Webshop etwas schief läuft. Da ist ein ausgiebiger Test in der Entwicklungsumgebung auch z.B. bei Updates zwingend erforderlich.
Du wirst selber am besten abschätzen können, welcher Aufwand gerechtfertigt ist.
Sooo ist das also. Ich hatte gedacht, es wäre ähnlich wie z.B. bei einem Webdesign-Programm, z.B. Dreamweaver. Man läd die Seiten, die man lokal geändert hat, hoch und fertig. Man hat alle Dateien geschützt (auch gegen Hackversuch) auf dem Rechner, falls beim upload etwas schief geht und/oder die Online-Version zerschossen ist, löscht man den Murks und läd neu hoch. Im Prinzip besser. Ist ja auch nicht unriskant, wenn von mehreren Seiten aus (Theme, plugins, WP, Seitenbetreiber…) was an der live-Version geändert wird und man dann unter Strom steht bei der eiligen Fehlersuche und Reparier-Versuchen. Aber ich will WP nauf keinen Fall schlecht machen…
Aber ginge es nicht trotzdem so, wie ich mir das naiv vorgestellt habe? Also wäre folgender Ablauf denkbar:
Erster Schritt: Ich poste meine news lokal (es ist keine Blogger-Seite, wo andere posten können), inklusive Mediendateien.
Zweiter Schritt: Ich lade die dadurch geänderte Datenbank hoch (vorherige auf dem Server befindliche vorher gelöscht) sowie die Mediendateien.
Dritter Schritt: Mit einem guten Suchen+Ersetzen-Plugin ändere ich dann die localhost-Adressen, die ja mithochgeladen wurden, in die tatsächlichen Domain-Adressen um. (Diesen Schritt könnte man eventuell auch vor dem upload auf dem localserver erledigen?)
Fertig ist der Lack.
Ginge das?
„… es wäre ähnlich wie z.B. bei einem Webdesign-Programm, z.B. Dreamweaver. Man läd die Seiten, die man lokal geändert hat, hoch und fertig.“
Dann hättest du wieder ein ziemlich statisches System. Der Sinn ist ja gerade, flexibel und flink neue Webseiten zu erstellen, nachdem die Vorarbeiten (Installation, Einrichtung Theme und Plugins) einmal abgeschlossen sind.
Ist ja auch nicht unriskant, wenn von mehreren Seiten aus (Theme, plugins, WP, Seitenbetreiber…) was an der live-Version geändert wird und man dann unter Strom steht bei der eiligen Fehlersuche und Reparier-Versuchen.
Deshalb testest du alles, was programmiert wird (und damit fehleranfälliger ist) auf einer Entwicklungsumgebung und schaust dir deine Seiten und Beiträge erst einmal in einer Vorschau an.
Aber ginge es nicht trotzdem so, wie ich mir das naiv vorgestellt habe?
Doch, klar, ist aber die Frage welchen Aufwand du jedesmal treiben möchtest.
Während du die Datenbank hochlädst und anpasst, ist dein Server nicht erreichbar. In der Zeit hat ein anderer Anwender schon fünfzig Mal den Button „Veröffentlichen“ gedrückt und sich anderen Aufgaben gewidmet.
