Sonstiges

bestehendes WordPress Blog auf PC 1:1 lokal kopieren

Um ein laufendes WordPress-Blog, das online verfügbar ist, lokal auf den Computer inkl. aller Artikel, Kommentare, Plugins, Tags etcpp zu übertragen, muss man folgendes tun (nutze „oben“ einen auf Linux basierenden Rootserver zum Ausliefern der Inhalte des Online-Blogs für die Leser und auf meinem lokalen PC läuft Windows Vista). Ach ja, wozu man das Blog lokal kopieren soll? Um beispielsweise neue Plugins oder auch neue WordPress-Versionen auszutesten. Aufgrund der Größe meiner Blog-Datenbank kann ich Operationen in den Datensätzen innerhalb der WordPress-Datenbank lokal auf dem PC viel schneller vornehmen (größerer Speicher, schnellere Platte, bessere CPU), ohne gleich etwas kaputtmachen zu können und kann dann anschließend die Datensätze in die echte Datenbank hochladen, wenn es erforderlich sein sollte.

1. XAMPP downloaden und auf dem PC installieren. Aktivieren. XAMPP? Ist eine Software, um einen Webserver lokal laufen zu lassen. Wozu? Ohne Webserver wird ein lokales WordPress Blog nicht laufen, ganz einfach. Es braucht dazu Apache (Webserver, um Blogseiten im Browser darzustellen), PHP (Sprachbasis von WordPress) und MySQL (Datenbank, die die Einträge des Blogs vorhält) = XAMP (A = Apache-Webserver, M = MySQL Datenbank, PP= Perl + PHP, X= Bebriebssystem Linux, MacOS, Windows oder Solaris.. XAMPP gibts für alle 4 Betriebssysteme)

Nach dem Installieren, den Dienst Apache und MySQL aktivieren (über eigene Oberfläche, seht Ihr schon):
XAMPP

2. Alle Dateien des WordPress Blogs per FTP in das Verzeichnis „C:/[XAMPP]/HTDOCS/[BLOGVERZEICHNIS] kopieren. Sieht dann im Dateimanager so aus:
WP Lokal

3. Die Datei WP-Config.PHP im Verzeichnis C:/[XAMPP]/HTDOCS/[BLOGVERZEICHNIS] aufrufen und entsprechend editieren:
WP Config local
Der Datenbankname kann gleich bleiben, muss aber nicht. Lasst es einfach so, wie es ist. Nach Installation von XAMPP ist jedoch im Gegensatz zur Online-Datenbank (wo WordPress seine Daten ablegt) der Datenbank-User „root“ und das Datenbank-Passwort leer. Das müsst Ihr in der wp-config.php anpassen. Beachtet die Sicherheitshinweise in den Kommentaren zu dem voreingestellten User root ohne Passwort.

4. Datenbank-Inhalte kopieren. Die Datenbank enthält sämtliche Artikel, Kommentare, Kategorien, Tags und weitere, zB von Plugins herrührende Datensätze. Wenn Ihr die Datenbank nicht kopieren würdet, wäre das lokale WordPress-Blog komplett leer, würde aber auch so nicht laufen, da in der Datenbank bestimmte Konfigurationseinträge vorhanden sein müssen, um das Blog überhaupt lokal aufrufen zu können. Ihr könnt dazu drei Wege gehen:
Weg 1: Online aufs Blog gehen -> im Admin-Menue „Manage -> Backup“ aufrufen -> Backup der Datenbank starten -> lokal sichern -> im Browser „http://localhost/phpmyadmin“ eingeben -> Datenbank anlegen (dabei den gleichen Datenbanknamen eintragen wie online oder neuen benutzen)
WP DB local
Und die soeben lokal gesicherte WP-Datenbank (liegt als Datei vor, meistens mit Dateinamen wie in der Art „Datenbankname_wp_20081011_462.sql.gz“) importieren. Klappt der Import mit der Dateiendung .gz nicht, einfach per 7zip, Winzip oder WinRAR entpacken, man erhält eine .sql-Datei. Dann statt dem .gz-File das .sql-File zwecks Import auswählen:
WP DB local

Weg 2: Wenn der Import aus bestimmten Gründen nicht klappt und Ihr die Möglichkeit habt, direkt auf die Online-Datenbank zuzugreifen, nutzt WINSCP im FTP-Mode und kopiert die MySQL-Dateien online (unter Debian /var/lib/mysql/…) nach XAMP unter „CXAMPPMySQLData[Datenbankname als Verzeichnisname]“
WP DB local
Eine MySQL-DB ist letztlich auch nichts weiter als ein Sammelsurium aus Dateien! Den Weg musste ich gehen, weil der Import auf dem herkömmlichen Wege via phpmyadmin nicht ging, Bigdump ebenfalls versagt hatte. Bigdump?

Weg 3: Wenn der Import nicht klappt und Ihr auch keinen Zugriff auf die MySQL-Verzeichnisse auf dem Onlineserver habt, ladet Euch BIGDUMP herunter. Die Datei BigDump.php ins Verzeichnis C:XAMPPHTDOCSBIGDUMP legen und im Browser „http://localhost/bigdump/bigdump.php“ eingeben. Backup der WordPress-Datenbank auswählen (die .gz-Datei vorher entpacken = man erhält eine .sql-Datei, mit der Bigdump unter Windows Vista lokal umgehen kann). Warten. Fertig ist der Import.

5. Table WP-Options anpassen (Quelle): Nun müsst Ihr lediglich zwei Dinge in der lokalen WordPress-Datenbank verändern, dann seid Ihr roger. Ruft dazu die Datenbank über „http://localhost/phpmyadmin“ auf. Geht dann in die Tabelle WP_Options und sucht nach den Datensätzen „SITEURL“ und „HOME“ (meistens unter den ersten 50 Datensätzen zu finden). Wie folgt anpassen:
WP local
WP local

6. Ruft nun das WordPress-Blog unter „http://localhost/[mein_blogverzeichnis]/wp-admin“ auf und gebt Eure Logindaten wie gehabt fürs Online-Blog ein. Dat wars! Sollte es Probleme mit den Artikel-URLs geben (Thema „schöne permalinks“), siehe Kommentar 1/paddya.

Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

39 Kommentare

  • Nicht vergessen: Mod-Rewrite in der Apache-Config aktivieren, falls man schöne Permalinks auf seinem Blog nutzt. Bei XAMPP ist es meines Wissens default deaktiviert.

    [XAMPP-Verzeichnis]apacheconfhttpd.conf öffnen und „€œLoadModule rewrite_module modules/mod_rewrite.so“€? suchen. Sofern keine # am Zeilenanfang steht, ist alles okay, ansonsten die Raute entfernen, danach Apache neu starten.

  • WordPress: Produktivsystem in ein Testsystem überführen…

    Vor Kurzem wurde WordPress in Version 2.1 veröffentlicht. Da dies ein Majorupdate ist, das viele Änderungen mit sich bringt, empfielt es sich vor dem Upgrade eines bestehenden Blogs erst ein Testsystem einzurichten, um den Upgradeprozess durc…

  • Ach Robert, wie schön Du das immer erklärst. Ich hab das vor ewig langer Zeit mal gemacht, aber so eine schöne 100%-e Erklärung hatte ich damals nicht und es ging natürlich allerlei schief. Naja, ich leb ja immernoch.

  • Problem bei der ganzen Umzugsaktion ist die Server-Konfiguration. Paddya hatte ja schon mod_rewrite angesprochen, welches man bei XAMPP manuell frei schalten muss. Je nachdem wie der Server konfiguriert ist, können aber auch noch ganz andere Probleme auftauchen. Mal von der Konfiguration von PHP und MySQL (Zeichensatz!!!) ganz zu schweigen.
    Hat man einen eigenen Server, ist es kein großes Problem. Einfach die httpd.conf, php.ini my.ini kopieren und anpassen. Bei einem Shared-Host sieht es aber schon ganz anders aus. Hier hilft es sich eine kleine PHP-Datei anzulegen ([?php phpinfo(); ?] – eckige Klammern durch spitze ersetzen), diese Datei unter einen beliebigen Namen speichern und aufrufen. So erhält man umfangreiche Informationen über die Server-Konfiguration was die Arbeit u.U. etwas erleichtert. Die Datei anschließend aus Sicherheitsgründen wieder löschen.

    Gerade im Fall von Shared-Hosts kann XAMPP aber schnell ein Griff ins Klo werden. Denn bei XAMPP sind PHP5 und MySQL5 integriert. Viele Shared-Hosts setzen aber noch auf PHP4 und/oder MySQL4. Im Grunde genommen kein großes Problem, kommt WP mit beiden Versionen zurecht. Fängt man allerdings an zu basteln, kann es schnell mal frickelig werden wenn man unterschiedliche PHP/MySQL-Versionen einsetzt.
    Hier wäre es zu überlegen ob man nicht Apache, PHP und MySQL selber installiert. Dies ist nur unwesentlich schwerer und es gibt reichlich Anleitungen im Netz wie man das richtig macht (plus Tips&tricks).

    Zu guter letzt würde ich noch den MySQL-Befehl LOAD DATA INFILE für den Datenimport ans Herz legen. Dazu dann noch eine funktionale GUI für MySQL (z.B. MySQL Control Center). Mit diesen Befehl kann man Textdateien (wie sie z.B. von WP-Backup erzeugt werden) direkt von MySQL in die Datenbank einlesen lassen. Das geht oft schneller und einfacher als die vielen Import/Export-Tools.
    Wo wir gerade beim Thema MySQL sind: Das wohl häufigste Problem beim Import von Datenbanken dürfte der Zeichensatz sein. Wer hat nicht schon mal ein Backup importiert und lauter merkwürdige Zeichen anstatt Umlaute vorgefunden? Hier sollte man sich im Vorfeld auch mal schlau machen (Internet hilft). Vermeidet zumindest viel Frust&Ärger.

  • Mit Linux-Shell-Zugriff kann man die Datenbank übrigens ganz einfach kopieren (bzw. sichern). Diese Methode ist deutlich weniger fehleranfällig (Abbruch durch Timeout o.ä.) und schont die Nerven:

    mysqldump –opt –user=[user_name] –password=[password] [database_name] > backup.sql

    Die Backupdatei (backup.sql) kann dann natürlich noch komprimiert oder direkt per FTP oder SCP kopiert werden. Lokal kann man sie dann wie oben beschrieben importieren.

    So kann man beispielsweise auch per Cronjobs regelmäßige Backups speichern lassen. Per Shell wird die Backupdatei dann so wieder eingespielt:
    mysql [database_name] < backup.sql

    Mehr Infos: http://dev.mysql.com/doc/refman/5.1/de/mysqldump.html

  • @Ralf, yep, von Ausnahmen lebt die IT-Welt:) Aber ein Hinweis für den Import der Datenbank: in phpmyadmin gibt es einen Optionsschalter, um anzugeben, welche Datenbankversion man online nutzt (Kompatbilitäsmode oder so ähnlich heißt der Schalter)

    Der Weg via WinSCP-FTP war mein einzige Möglichkeit, den doofen Dump zu umgehen, der bei anschließenden, normalen Imports zB mit einem Verweis auf doppelte Datensätze beim CREATE ausstieg. So einfach Dateien von A nach B kopiert und gut wars. Habe btw an den Versionen nix gedreht: Oben läuft eine 4er Mysql, unter XAMPP bereits einer 5er.

  • Ups, kaum gibt es kein Edit mehr, schon bräuchte ich es. Die Parameter [user_name], [password] und [database_name] müssen natürlich jeweils durch die entsprechenden Einträge ersetzt werden (ohne [ und ]). Außerdem steht vor jedem Parameter (opt, user, password) ein doppeltes Minus (also — [minusminus] statt – [minus] … ich glaube Robert klaut immer eins, wenn zwei eingeben werden… *g*)

  • @André, joo… werde heute Nacht gaanz vorsichtig Ajax edit comments wieder reaktivieren und beobachten. Exakt das war übrigens auch die indirekte Ursache für mein Import-Problem, weil doppelte Datensätze vorlagen. Und ich WP A Edit Comments in Verdacht hatte, meine Table wp-comments über einen unbekannten Bug mit doppelten IDs vollgeklatscht zu haben.

  • Tja Robert, das Umschalten in phpmyadmin wird dir aber nichts nützen wenn du lokal ein Plugin/Script installiert hast welches explizit eine 5er-Version (PHP/MySQL) erwartet. Da haben sich schon einige einen Wolf gesucht warum lokal alles wunderbar klappt, online aber nichts läuft. 1:1 kopieren sollte dann auch bedeuten die entsprechenden Versionen zu verwenden und nicht irgendwas kompatibles.

    Falls übrigens der Login lokal nicht klappt, hilft es die Cookies zu löschen.

  • und immer schön vorsichtig sein, denn xammp IST eine Webserver er simuliert das nicht nur. Das heißt das funktioniert wie bei Eurem Provider auch, wer sucht der findet und böse Menschen könnten dann auf Eurem PC spazieren gehen. unbedingt den vorgeschlagen Sicherheits-Check durchführen und das Ding damit halbwegs zu machen. Wenn ich das unter Windows XP mache (was ab Service Pack 3 schwierig ist, weil da einige Ports gesperrt werden), dann zieh ich den Netzstecker.
    Wenn ich ernsthaft mit xammp arbeiten will, dann gehe ich ganz schnell zu meiner Linux-Installation, da gibt es den xammp auch und man kann haarscharf den Webserver des Providers nachbauen. php-Version etc. Ich empfehle dazu http://linuxmint.com/….

  • Thx, genau das wonach ich suche. Denn auch wenn mein Blog noch sehr überschaubar ist, wollte ich nicht an der Online-Version updaten, sondern auf jeden Fall erstmal eine lokale Installation erstellen.

    XAMPP ist dafür echt genial, allerdings auf dem Mac noch etwas „unausgereift“ im Vergleich zur Version für Windows. Deswegen hatte ich bei der Installation direkt eine Anleitung verfasst und ich dachte, das passt ja hier genau hin (XAMPP-Installation auf Mac OS).

    Hoffe es ist ok, hier den Link zu Posten …

  • Toller Artikel – sehr ausführlich! Kann ich für meinen aktuellen Blog gebrauchen, denn komischerweise musste ich gestern feststellen das die neusten drei Post auf einmal weg waren. 🙁

  • Zum Exportieren auf dem Root-Server viel schneller: auf der Konsole mysqldump (sagte Andre ja oben schon), zum Importieren dann „mysql“ auf die Eingabezeile des lokelen PC tippen und dort mit „source pfadzudatenbank.sql“ den Dump importieren. Und DB-User „root“ auf dem Webserver ist nicht so empfehlenswert.

  • Und damit man das ganze nicht via localhost/wordpress/sonstwas aufrufen muss, sollte man noch in der windows/system32/drivers/etc/ die hosts anpassen sowie im Verzeichnis Apache2/conf/httpd.conf anpassen.

    windows/system32/drivers/etc/hosts:

    127.0.0.1 DOMAIN.dev

    Apache2/conf/httpd.conf : (steht meistens ganz unten in der Datei

    NameVirtualHost 127.0.0.1:80

    ServerAdmin webmaster@DOMAIN.dev
    DocumentRoot C:/webserver/apache2/htdocs/VERZEICHNIS/public
    ServerName DOMAIN.dev

    AllowOverride All

    Dann den Webserver neu starten (über das Interface oder über den DiensteController in Windows) und schon kann die lokale Installation über domain.dev erreichen.

    Selbstverständlich kann man auch schnitzel.lokal oder sonstwas angeben. Sogar domain.de wäre möglich, dann aber ist über diesen Rechner die „wirkliche „Domain.de nicht mehr erreichbar, da intern auf dem Rechner dann die DNS Einträge geändert wurden.

    Hoffe das war verständlich.

  • Leider ist in meinem vorherigen Kommentar die Anweisungen in spitzen klammern entfernt worden. Die Anweisungen stehen aber auch in der httpd.conf beispielhaft drin. Und in der hosts muss nur die zeile stehen, wie Sie oben steht. So.

  • @Robert,
    ich weiß nicht ob es mir heute besonders auffällt oder schon länger so ist. Aber wenn die Seite bereits da ist, ich auch schon kommentieren kann, lädt sie noch lange weiter erstmal photobucket.com und anschließend c7.statcounter.com

    Falls das schon länger eingebaut ist, ist es heute zumindest viel langsamer.

  • die Bilder sollten den Seitenaufbau nicht hemmen, statcounter kann schon mal nerven, verhindert aber ebensowenig den Seitenaufbau, da es zum Schluss geladen wird im Footer. Du siehts womöglich eher den Lade-Icon oben rechts im FF? Oder es kann hin und wieder sein, dass beim Kommentieren der Seitenaufbau in der Tat nervt, was aber eher an der Werbeanzeige von Lifestream liegen kann, die im Einzelartikel zu sehen ist

  • immer gut solche Artikel, grundsätzlich war mir die Vorgehensweise schon klar, aber gerade gestern bin ich fast verzweifelt, weil es nicht funktionieren wollte und heute lese ich im Kommentar von paddya genau die Lösung die ich brauche.
    Zufälle gibt´s… 🙂

  • @Robert #25
    Nein, mich nervt, wenn ich beim Kommentieren links neben mir ständig wechselnd lese „Übertragen der Daten von …“
    Normalerweise, so wie jetzt auch wieder, lädt die Seite einen Moment und dann ist gut.

    Heute mittag lud es ewig noch bevor lifestream aufgerufen wurde, und da waren es die beschriebenen Einbindungen. Jetzt scheint alles wieder normal. Vielleicht war’s nur ein kurzfristiges Problem…

    Falls nicht melde ich mich nochmal…

  • Stress und Fehler beim Updaten von WordPress im Vorhinein verhindern…

    In den letzen Wochen waren bei WordPress mehrere Updates fällig. Unter den Bloggern gab es geteilte Meinungen, wie die Installation verlaufen ist. Von “ohne Probleme” bis “Ich schmeiße alles hin!” waren alle Meinungen vertrete…

  • @ Dominic´s post #22
    ich nehme an, Du meintest
    die xampp/apache/conf/extra/httpd-vhosts.conf
    und nicht die Apache2/conf/httpd.conf mit folgenden Eintrag:

    NameVirtualHost 127.0.0.1:80

    ServerAdmin webmaster@DOMAIN.dev
    DocumentRoot C:/webserver/apache2/htdocs/VERZEICHNIS/public
    ServerName DOMAIN.dev

    AllowOverride All

    __
    in der httpd.conf finde ich nichts dergleichen.
    Wäre toll, wenn DU mir kurz antworten könntest, denn ich bin auf diese URL-Simulation total angewiesen und siehe http://forum.wordpress-deutschland.org/konfiguration/38834-localhost-zugriff-verweigert-geht-nicht-ohne-index-php.html#post265367 kriege ich es nicht hin!
    Danke, Sebastian

  • hallo ich bin gaaaaaaaaanz neu bei der sache und ich weiß nicht warum gibt es bei mir überhaupt diese Verzeichnis „blog“ nicht.
    kann mir bitte jemand helfen?

  • @#35:
    Das Verzeichnis „Blog“ wurde in dem Beispiel nur erstellt, um den Blog vom Server lokal zu speichern. Es wurde also zusätzlich angelegt. Ist nicht automatisch nach der XAMPP Installation vorhanden. Kannst das Verzeichnis nennen wie du willst, zum Beispiel auch „wordpress“ und dann deinen Blog reinkopieren. Geht nur darum den hinterher wieder zufinden.
    Musst hinterher im Browser nur das richtige Verzeichnis angeben: „http://localhost/[Blogverzeichnis]“

  • Ich musste mal wieder eine Präsantation lokal sichern, um das kommende WP-Update UND ein Theme-Update zu testen. Gerade wenn man mit Problemen rechnen muss, ist das ganz hilfreich. Noch ein Hinweis zu den sehr hilfreichen Ausführungen oben: Wenn der Aufruf der Seite nicht klappt, mal die Permalinks neu abspeichern. Und schauen, ob man nicht versehentlich eine .htaccess mit auf XAMPP kopiert hat, dann diese löschen!

  • Moin, vielen Dank für deine Anleitung.
    Insgesamt hat der „Umzug“ ganz gut geklappt.
    Allerdings kann ich momentan keine Seiten meines Blogs aufrufen.
    Ich hab die 2 entsprechenden Einträge in der DB geändert.

    Beim Aufruf einer Artikelseite, lande ich immer auf localhost/xampp

    Vielleicht weiß ja jemand was auf die schnelle!
    Danke!

Kommentieren