lokale Installation mehrerer WP-Seiten

Wie du WordPress lokal auf dem eigenen Computer installieren kannst, habe ich vor kurzem in einem etwas ausführlicheren Blogbeitrag geschrieben. Der Beitrag erhält auch einen kurzen Hinweis auf das Plugin Duplicator, mit dem du recht komfortabel die fertiggestellte Website zum öffentlich zugänglichen Webserver umziehen kannst.

Im Prinzip ist auch ein Umzug mit phpMyAdmin und Übertragung aller WordPress-Dateien per FTP möglich, allerdings müssen dann Website-URL und WordPress-URL auf dem Ziel-Server angepasst werden (am einfachsten durch Hinzufügen von define( 'RELOCATE', true ); in die wp-config.php, anschließend meldest du dich über wp-login.php im Backend an und korrigierst dann die Website-URL und WordPress-URL unter Einstellungen > Allgemein. Um auch die für Mediendateien und Links verwendeten URLs zu korrigieren, kannst du dann ein Plugin wie Better Search Replace nutzen). Allerdings ist die automatisierte Variante mit Duplicator etwas bequemer.

Was die Installation mehrerer WordPress-Instanzen auf dem lokalen Webserver angeht, liegst du schon richtig: zweiten WordPress-Ordner und zweite MySQL-Datenbank einrichten und dann kann die Installation losgehen. (Einfacher geht’s übrigens mit MAMP Pro, weil du dann statt einer URL http://localhost/wordpress2/ auch eine eigene Domain http://firma-mueller.dev aufsetzen kannst.)

Das ist ein wenig durcheinander. 🙂

Zum einen stehen in der wp-config.php die Zugangsdaten zur Datenbank. Während bei MAMP der selbst gewählte Namen der Datenbank und der Benutzername „root“ mit dem Passwort „root“ eingegeben wird, müssen die Werte bei einem Umzug auf den Server eines Webhosts entsprechend mit den Zugangsdaten der Datenbank dort überschrieben werden. Oft wird dabei der Name der Datenbank und der Nutzername vorgegeben und dass Passwort kann man selber festlegen oder ändern.

Was bei Einsteigern mitunter für Verwirrung sorgt ist der DB_HOST. Damit ist der Server gemeint, auf dem die Datenbank liegt. Da aber häufig Apache-Webserver und MySQL-Datenbank auf dem gleichen Computer ausgeführt werden, ist der DB_HOST in den meisten Fällen der (aus Sicht des Apache-Webservers) „eigene“ Computer, also localhost. Es gibt aber auch Webhoster, die aus technischen Überlegungen die MySQL-Datenbank auf einem anderen Webserver installiert haben. Hier wird dann ausdrücklich angegeben, welche Webadresse als Datenbank-Host angegeben werden muss. (Andersherum: wird nicht extra auf einen externen Server hingewiesen, ist es mit ziemlicher Sicherheit localhost).

So. Neues Kapitel. 🙂

Bisher ging es ausschließlich darum, wie WordPress an die Daten in der neuen Datenbank herankommt. Bei einem Umzug ist aber noch ein weitere Punkt zu beachten: WordPress verwendet an verschiedenen Stellen absolute URLs, etwa für alle Mediendateien, aber auch für Links, Widgets, Menüs, etc. Teilweise sind diese URLs auch noch als serialisierte Daten angelegt (damit sind mehrere Daten in einem Datenfeld gemeint). Es gibt verschiedene Varianten, wie man diese URLs anpassen kann:

Zum Beispiel könnte man direkt (z.B. mit phpMyAdmin) in die Datenbank eingreifen. Allerdings übersieht man hier leicht Einträge und die Chance, das man mehr Unheil anrichtet, ist vergleichsweise groß. Es gibt auch Varianten, bei denen man die neue URL fest in die wp-config.php oder die functions.php einträgt. Damit wird der Eintrag in der Datenbank durch die Abfrage einer Konstante überschrieben, bleibt aber in der Datenbank selber unverändert, was nicht optimal ist. Eine recht effiziente Änderung ist, WordPress mit define( 'RELOCATE', true ); „mitzuteilen“, dass man mal eben umziehen möchte. Dabei wird kurzerhand das bisherige Muster zum Erstellen von URLs durch den Abruf der gegenwärtigen (neuen) Serveradresse ersetzt (wem das alles noch nicht kompliziert genug ist, kann gerne hier Details nachlesen). Das kann man geschickt ausnutzen, in dem man sich auf dem neuen Server über die Seite wp-login.php anmeldet und geschwind unter Einstellungen > Allgemein die URL der neuen Domain einträgt. Anschließend sollte man die „Krücke“ RELOCATE wieder aus der wp-config.php entfernen, bevor jemand versucht, die Funktion für Schabernack auszunutzen.

Nun wird zwar für das WordPress-Front- und Backend die neue URL verwendet, aber die Einträge für Mediendateien, Menüs, Links, etc. sind noch nicht angepasst. Wenn man es sich einfach machen möchte, kann man flugs das Plugin Better Search Replace installieren und mit Hilfe dieses Plugins die gesamte Datenbank nach z.B. http://localhost:8888/ durchsuchen und den Teil der URL mit https://paul-huber-und-soehne.de/ ersetzen. Das Plugin wird anschließend vermutlich nicht mehr benötigt und kann wieder gelöscht werden.

Hatte ich erwähnt, dass bei solchen Aktionen Backup sinnvoll sind? 🙂

Übrigens: Wenn es mit der unkomplizierteren Methode mit Duplicator nicht klappt, kann das an der Serverkonfiguration liegen. In solchen Fällen geht auch ein Backup/Restore mit Plugins wie UpdraftPlus Backup oder BackWPup.

Der Thread wird ein wenig unübersichtlich. 🙂

Ich gehe nochmal ein paar Schritte zurück zu dem Beitrag von chakotay, der mit „Ich danke dir sehr für deinen ausführlichen Post …“ beginnt … 

Du möchtest eine bestehende Website bei einem fremden Webhoster auf deinem Mac lokal als Testversion klonen. Dazu hast du

1. MAMP installiert,
2. lokal eine Datenbank wordpress1 angelegt und
3. die gesamten WordPress-Dateien vom Webserver in ein Verzeichnis Applications/MAMP/htdocs/wordpress1/ kopiert.
4. Außerdem hast du die Datenbank beim Webhoster exportiert und in die Datenbank wordpress1 in MAMP importiert.

So weit ist das schon mal alles prima. (Ein typischer Einsteigerfehler wäre: Nur die Dateien kopieren und ganz vergessen, dass die Inhalte in der Datenbank liegen. Oder umgekehrt. Hast du aber alles richtig gemacht. Prima.)

WordPress hat eine Konfigurationsdatei wp-config.php, in der unter anderen auch die Zugangsdaten zur Datenbank stehen. Da sind jetzt noch die alten Zugangsdaten vom Webhoster drin, die natürlich für deine lokale Installation nicht mehr stimmen. Sie sollten jetzt so lauten:

/** Name der Datenbank in MAMP */
define('DB_NAME', 'wordpress1');
/** MySQL-Datenbank Nutzername in MAMP */
define('DB_USER', 'root');
/** MySQL-Datenbank Passwort in MAMP */
define('DB_PASSWORD', 'root');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Mit diesem Daten sollte WordPress zumindest auf die Datenbank zugreifen können und du solltest unter http://localhost:8888/wordpress1/wp-login.php zumindest schon mal das Login-Formular sehen können. Funktionieren tut es vermutlich noch nicht richtig, weil in der Datenbank alle möglichen Links auf den Webserver deines Webhosters verweisen.

Um das jetzt zu korrigieren, fügst du in der wp-config.php gleich unterhalb von define('WP_DEBUG', true); die folgende Zeile vorübergehend ein:

define( 'RELOCATE', true );

Jetzt müsstest du dich zumindest über http://localhost:8888/wordpress1/wp-login.php im Backend deiner lokalen Installation anmelden können. Wenn das klappt – supi! – kannst du die beiden Einträge der URLs in Einstellungen > Allgemein auf http://localhost:8888/wordpress1 ändern.

Jetzt fehlt noch ein letzter Schritt, damit auch die Links für die ganzen Mediendateien und Links, etc. angepasst werden. Dazu installierst du in deine lokale Installation das Plugin Better Search Replace und ersetzt dann http://link-zur-domain-beim-Webhost.de mit http://localhost:8888/wordpress1

Abschließend kannst du in der wp-config.php noch die vorübergehend eingefügte Zeile wieder entfernen.

Für alle Änderungen in Dateien würde ich übrigens den kostenlos erhältlichen Editor Atom.io empfehlen.

Erzähl mal. ob das so geklappt hat.

Ich bin absoluter Laie, Ü50 🙂 …

Ich doch auch. 😉

In meiner wp-config.php stand die Zeile define(‚WP_DEBUG‘, true); auf „false“.

Daran merkt man, dass irgendwann die Konzentration nachlässt. 🙂

Mit define('WP_DEBUG', true); werden Fehlermeldungen (auch im Frontend) ausgegeben und erlauben so, abgesehen von speziellen Debugging-Werkzeugen (z.B. Debug-Bar) eine Fehleranalyse. Da man aber nicht möchte, dass potentielle Angreifer Fehler auch noch soweit analysieren, dass ihnen ein Angriff erleichtert wird, sollte der Wert bei produktiven Websites auf falsegesetzt werden. (Lokal lass ich es aber gerne auf true, weil ich dann schneller merke, wenn etwas nicht stimmt.)

Wenn jetzt soweit alles läuft, kannst du dir auch noch diesen Beitrag ansehen. Hier wird erklärt, wie du WordPress ohne Unterverzeichnis aufrufen kannst.

Übrigens gibt es viele Möglichkeiten, sich (statt mit virtuellem Kuchen) bei WordPress einzubringen: Schreib mal zu deinem Lieblings-Plugin einen kleinen Kommentar auf der Plugin-Seite, klick mal auf den Button „Works with my WordPress-Version“, hilf einem Nachbarn, seine Website einzurichten … Es finden auch regelmäßig WordPress Meetups statt, bei denen man viel lernen (oder sich zumindest nett unterhalten) kann.