|

WordPress-Umzugsprotokoll

Das ist mein erster Eintrag unter der neuen Domain und auf eigenem webspace. Bisher hatte ich meinen Blog bei wordpress.com. Was der endgültige Auslöser für den Umzug war, steht hier – der Gedanke schwelte aber ohnehin schon länger in mir. Ein Punkt war auch, dass ich den Eindruck hatte, die bei wordpress.com angebotenen kostenpflichtigen Zusatzdienste wären über die Jahre hinweg immer teurer geworden. Und da macht man sich so seine Gedanken: Werden die restlichen Basis-Dienste wirklich immer kostenlos bleiben? Werden eines Tages Dienste, die für einen Wechsel entscheidend sind, auch kostenpflichtig?

So einen Umzug sollte man zwar nicht überstürzen, allerdings sollte man sich irgendwann auch einmal zu einer Entscheidung durchringen. Deshalb bin ich seit letzter Woche bei einem Provider, und zwar bei einem aus Dresden. Einfach wegen der alten Regel Kauf Sauf „Surf sächsisch!“. Und weil sie gerade ein Sonderangebot hatten. Netterweise bot mir Herr Menzel von der Firma MSISP an, mir WordPress gleich mit vorzuinstallieren. Außerdem bot er weiterhin an, mir dabei zu helfen, meinen Blog zu verlegen – beim, wie er schrieb „SQL Dump“.  Ich hatte keinerlei Ahnung, was das sein sollte, ging aber aber zunächst nicht darauf ein, sondern behielt das nur als mögliche Notlösung im Kopf. Denn leider verspüre ich diesen (höchst unlogischen) sportlichen Gedanken in mir, das irgendwie selbst schaffen zu müssen.

Theoretisch ist es auch ganz einfach: Man exportiert einfach im alten Blog über die Export-Funktion sämtliche Inhalte und hat diese dann in Form einer xml-Datei. Diese muss man im neuen Blog nur importieren. Aber wie bekommt man die im alten Blog gespeicherten, in den Artikeln verwendeten Bilder und pdf-Dateien mit? Die xml-Datei enthält diese nicht, in dieser befinden sich nur die Artikel, Kommentare, Seiten usw. Das, so wurde mir von netten Mitmenschen erklärt, geschieht automatisch. Man klickt im neuen Blog im WordPress-Import-Plugin einfach an „Download and import file attachments“, dann wird das alles mit herüber kopiert und auf dem neuen Webspace abgespeichert. Genial!

Leider gab es aber eine kleine Hürde beim Importieren: Das Import-Plugin konnte laut Angabe nur max. 4MB große xml-Dateien verarbeiten, meine war aber 10MB groß. Was macht man da? Im Internet nach Lösungen suchen. Mehrere schrieben, so mache man das ja auch auf keinen Fall, dafür solle man besser dringend den MySQLDumper benutzen, ohne den ginge das gar nicht.

Hier rächte es sich, dass ich in den letzten 10 Jahren bestimmte Fachgebiete sträflich vernachlässigt hatte. SQL? Das ist irgendwas mit Datenbanken, schon klar, aber wie das nun genau funktioniert … irgendwie über phpMyAdmin, hat mich alles nie interessiert. Datenbanken hatte ich zwar schon angelegt, aber mit Access, worüber Profis ja stets nur die Nase rümpfen. Ich hatte Ende der 90er, Anfang der (wie nennt man die Epoche eigentlich) Nuller auch Internetseiten angelegt, gepflegt und war sogar bis zu der Erkenntnis vorgedrungen, dass css eine feine Sache ist. Aber ich war dann froh, als es jemand übernahm, der sich besser damit auskannte. Ich muss nicht alles können – manches kann man auch einmal anderen überlassen. Aber nun könnten ein paar Kenntnisse nicht schaden.

Immerhin bekam ich den Tipp, dass man die Export-Dateien ja auch in mehrere Häppchen aufteilen* und so einzeln importieren kann. Auf die Idee wäre ich nie gekommen. Und das hat funktioniert. Zumindest teilweise. Die Bilder sind nämlich alle noch auf dem alten Server. „Download and import file attachments“ hatte ich beim Import jeweils aktiviert und mich nun auf jeweils mehrere Stunden Importdauer eingestellt, aber es ging jeweils viel zu flott für mehr als 100 MB Bilder. Alle Texte sind nun hier im neuen Blog und die Bilder werden hier auch korrekt angezeigt, aber sie werden dabei jeweils vom alten Server abgerufen. Eigentlich ist das noch nicht einmal negativ, denn dadurch spare ich Speicherplatz (also letztlich Geld), aber es ist technisch nicht perfekt. Ich müsste deshalb  noch alle Bilder und Dokumente auf den neuen Webspace kopieren und nachher die Links austauschen. Auf dem alten Server sind sie – wie man an den Bild-URLs erkennt – in Unterordnern nach Jahren und Monaten sortiert. Glücklicherweise habe ich alle meine Bilder zufälligerweise nach demselben Schema auch immer auf meinem Computer gespeichert. Ich muss sie also nur so, wie sie sind, uploaden. Leider ist die Neuzuordung nicht 100%ig korrekt, denn manchmal aktualisierte ich  alte Artikel später und fügte dazu auch neue Fotos dort ein. Die sind dann freilich in dem Unterordner gelandet, der zum Tag des Uploads und nicht zum Tag der Artikelveröffentlichung gehört. Ein paar Problemchen könnten also entstehen, die ich manuell korrigieren muss. Aber das hat ja Zeit.

(* „Werkzeuge“>“Exportieren“> „alle Inhalte“ abwählen und „Artikel“ über mehrere Zeiträume einzeln exportieren. Das kann man nacheinander wieder importieren)

Viel dringender ist etwas anderes: Interne Links auf eigene Artikel. Die verweisen nun stets auf den Artikel auf dem alten Server. Und da mir bekannt ist, dass Suchmaschinen doppelt vorhandene Artikel schlechter einstufen, habe ich im alten Blog das meiste bereits offline gesetzt. Die Links müssten alle aktualisiert werden. Das scheint noch nicht einmal so kompliziert zu sein, denn man kann in der Datenbank (die alle Texte enthält) einfach per „Suchen und Ersetzen“ alles austauschen. Ich habe beim ersten Überfliegen den Eindruck bekommen, dass die Prozedur hier beschrieben wird, aber ich will mir das ganz sorgfältig durchlesen, weil ich absolut keine Lust habe, mir hier etwas kaputt zu machen.

Um das zu vermeiden, brauche ich logischerweise zunächst ein Backup der Datenbank. Ein Backup zu erstellen, scheint ganz einfach zu sein, dafür gibt es massenhaft WP-Plugins. Mich würde nur interessieren: Wie stelle ich es eigentlich wieder her? Wo muss die gesicherte Datei eigentlich wieder hin? Und wieso kann ich die mir nicht vorher einfach per ftp downloaden? Bei einer Access-Datenbank geht das ja auch. Es ist echt nervig, wenn man keine Ahnung von solchen Sachen hat.

Ich denke, die wichtigsten internen Links werde ich mal fix manuell korrigieren.


Was für Plugins habe ich installiert?

  • 2 Click Social Media Buttons (sehr feine Sache, fügt die datenschutzmäßig korrekten, erst zu aktivierenden „auf Facebook empfehlen“ (usw.) Schalter ein)
  • Antispam Bee (wg. Datenschutz besser als Askimet)
  • Broken Link Checker (oh je … der zeigt mir eine Menge Korrektur-Arbeit an)
  • Cachify
  • Google XML Sitemaps
  • MCEComments (damit kann man beim Kommentar-Schreiben Text formatieren und muss nicht mehr mit diesem html agieren)
  • Statify (bin noch nicht sicher, ob das wirklich etwas nutzt, ich kann ja auch Google Analytics verwenden)
  • TinyMCE Advanced (sehe nur ich hier beim Schreiben, ermöglicht mehr Textformatierungen, aber auch Grafik-Elemente – z.B. obige Linie – oder Tabellen)
  • Social Media Widget (Für die Google+- und Facebook-Schaltflächen)
  • WordPress Database Backup
  • WordPress Importer
  • WP-Optimize

getestet, als nutzlos eingestuft:

  • Jetpack von WordPress.com
  • Google Analytics for WordPress (habe den Sinn nicht erkannt, Tracking-Code kann man auch manuell eingefügen)
  • Yet Another Related Posts Plugin (soll ähnliche Artikel unterhalb jedes Artikels mit erwähnen, hat bei mir aber thematisch völlige Unpassendes aufgelistet)
  • AWS Easy Page Link (soll interne Links besser einfügbar machen – habe keinen Unterschied festgestellt)
  • Google Plus Stream Plugin For WordPress (sollte rechts neben den Artikeln die jeweils letzten vier Postings aus meinem Google+-Stream anzeigen, allerdings funktionierte das nur zu Beginn. Nach einigen Tagen wurde nichts mehr aktualisiert und ich erhielt einen Hinweis von meinem Provider, dass im

    Error_LOG für meine Internetseite pro Aufruf ca. 300 KB an Fehlermeldungen abgelegt wurden. In denen kamen ständig Google+-Textfragmente vor.)


Ein paar Kleinigkeiten sind noch zu klären. Morgen werde ich deshalb einem Kollegen ein paar  Fachfragen stellen … der arme Kerl! Aber selber schuld, dass er sich mit Typo3 auskennt – dadurch gilt er bei uns als Fachmann für Internetzeugs. Fragen wären: Was ist eine Sitemap? Das habe ich eingereicht bei Bing und Google, aber was macht das konkret? Muss ich die nach jedem Artikel aktualisieren? Was ist der Zusammenhang zwischen Google Webmaster-Tools und G. Analytics – warum ist das nicht dasselbe? Warum muss man das verknüpfen? Und muss man das überhaupt? Und was um Himmels willen, ist nun eigentlich der Sinn dieses Tracking-Codes?


Übrigens: Ich hatte auch überlegt, auf einen Google-, also blogger.com-Blog zu wechseln, weil man dort z.B. sehr umfangreiche Möglichkeiten der Theme-Gestaltung hat. Da ich aber in den letzten Monaten dort einen Blog für ein Jugendprojekt eingerichtet habe und dort auch einige Inhalte mit eingestellt habe: Indiskutabel! Ich bereue mittlerweile, dass ich diesen Blog nicht auch mit WordPress erstellt habe.

Naja … angeblich kann man Google-Blogs auch nach WordPress exportieren. Nichts leichter als das!


Nachtrag: Die „301 Weiterleitung“, also die Umleitung aller alten Adressen hierher habe ich nun auch gemacht. Das geht nur bei wordpress.com und ist mit 13$ kostenpflichtig. Ein Glück, dass der Dollar gegenüber dem Euro so wenig wert ist!

9 Comments

  1. Hallo Frank,
    schön dass der Umzug geklappt hat.
    Eine Sitemap die du bei den Suchmaschinen einreichst ist eine Datei in der alle deine Seiten aufgelistet werden und mit Priorität bestückt werden. Das ist also quasi so, als würdest du dem Google und dem Bing sagen, hier ist der offizielle Seitenplan von mir. Das solltet ihr finden. Meist finden die noch viel mehr. Daher musst du eine Sitemap auch nicht bei jedem neuen Artikel akualisieren. Gute Plugins machen das aber von sich aus und der crawler der suchmaschinen findet dann wenn er vorbei kommt automatisch die aktuelle Variante.
    Google analytics ist ein Werkzeug das eng mit dem Geldverdienen bei Google zusammen hängt, also Adsens und AdWords zusammen hängt. Für Werbekunden war es mal sehr wichtig zu wissen welche Zielgruppe sie auf deiner Seite eigentlich so erreichen. Und dazu gab es das Analytics tool. Der Tracking code in deiner Seite Trackt, also die Daten deiner Besucher. Er schreibt mit welches Betriebssystem die haben, welche Bildschirmauflösung, wo sie her kommen und wann sie dich und wie lange angesurft haben und alles sowas. Daraus macht das anaytics schöne niedliche Grafiken, am besten mit vielen Pfeilen nach oben. 🙂 Und du kannst sehen welche Suchbegriffe die Leute eingegeben haben um zu dir zu finden und sowas. Das wiederum hilft dir deine AdWords besser zu setzen und somit weniger Geld zu verschwenden.
    Dumm nur, dass das Adwordstool mittlerweile die vollen und ähnliche Funktionen eingebaut hat und dass das Webmastertool auch ein Update an funktionalität bekommen hat. Seit dem macht für mich Analytics irgendwie keinen Sinn mehr. Denn es hat noch ein Problem, der Tracking code wird von Googleservern geladen und das kann unter Umständen die Performance deiner ganzen Seite sogar aushebeln. Das heißt, Google belohnt seiten für seinen Index, die schnell laden und baut dir dann ne Fußfessel ein, die deine Seite bremst. Willkommen in der neuen Welt. 🙂 
    Analytics ist auch Datenrechtlich ein sonderfall, weil Goggle die Daten natürlich auch so auswertet die er über deine Seite sammelt, also für sich und nicht nur für dich. Das wiederum müssen deine User wissen. Mein Vorschlag dazu wäre das Analysetool piwik, das open Source ist, das du auf deinem eigenen Server/Webspace installierst und bei dem nur du die Daten deiner Besucher analysieren kannst. Die Funktion ist ähnlich, ein Tracking code wird eingebunden und dann sammelt auch piwik die Daten, aber eben für sonst niemanden aus zu werten.
    Das Webmastertool zeigt dir dann neben den Keyword auch noch Daten zu deiner Seite an und Verbesserungsvorschläge für ddeine seiten im Index. Das heißt du reichst deine Sitemap ein und er sagt dir wieviele Seiten davon bereits indexiert sind, Er sagt dir, auf welchen Seiten er fehler beim crawlen deiner seite gefunden hat und er zeigt dir wer von wo auf deine Seite linkt und so weiter. Außerdem hast du dort die Möglichkeit bestimmte seiten die dir nicht passen, dass er die im Index hat, oder auch z.B. als Link unter deinem Eintrag mit anbietet zu löschen. Mit dem ein oder anderen testtool sagt er dir auch ob deine Seite schnell ist und ob du doppelte Einträge bei Keywords Description ider Titel hast. Das Tool ist also Sinnvoll für alle die sich darüber informieren wollen, was der Google, übrigens auch der Bing, so über die eigene Seite wissen und wie man darauf einfluss nimmt.
    Soviel erstmal um deinen Kollegen etwas zu entlasten und dann frag gleich spezieller so zu sagen. 🙂

  2. Schade, dass so zwischenkollegiale Gespräche verhindert werden 😉 So hätten M. und ich mal wieder ein Gesprächsthema abrechnen können. Über uns wird ja immer behauptet, wir würden tage- oder gar wochenlang nie reden. Wir sagen allerdings: Wo zu auch? Ein „Hallo!“ früh und ein „Tschüss!“ Nachmittags reichen völlig aus. Ich lese mir Deine Lehrmaterialien später durch (muss jetzt nach einer Woche Krankheit erst einmal eine kurze to-do-list abarbeiten und denke dabei spontan an eine Sponge-Bob-Folge).

  3. Hallo Frank,
    na, dann viel Erfolg mit den weiteren Schritten! Da bin ich froh, dass ich mit wenig Ahnung gleich mit einer eigenen Domain angefangen hatte.
    Jetpack finde ich übrigens wegen der Detailtiefe an Seitenstatistiken durchaus nützlich. Als Bonus gab es eine Jahresbilanz, u. a. mit beliebtesten Artikeln, meist-kommentierten Artikeln, fleißigsten Kommentierenden usw., nett aufbereitet. Hat noch ein paar andere Nützlichkeiten, z. B. vereinfachte Einbindung von Videos etc. Ich nutze allerdings auch nur einen Teil der Features.
    Manuelle Anpassungen würde ich versuchen, so weit wie möglich zu vermeiden, z. B. bei internen Links. Hab allerdings selbst noch keinen „virtuellen Umzug“ gemeistert.

  4. Nein Frank, anders. Du gehtst jetzt vorbereitet ins Fachgespräch, so dass du noch gezieltere Fragen stellen kannst. Alle Umstehenden werden es für ein unglaubliches Fachgespräch halten und euch nicht dabei stören. Und Fachgespräche kann man gleich zum doppelten Satz abrechnen. 😉 Zwischenmenschliche Kommunikation auch Non-digital finde ich immer noch als sehr wichtige Grundlage für so ein Leben. 

  5. Sehr geehrter Herr Nagel,
     
    melden Sie sich doch einfach kurz bei unseren Support, er hilft Ihnen die Links in Ihrer DB anzupassen, bzw. gibt Ihnen auch eine kurze Anleitung zum „DoitYourself“. Dann können wir auch Ihre Bilder entsprechend kopieren und die Pfade auch anpassen. Das ganze dauert max. 10 Min. 

    Ihr MSISP Kundensupport

  6. Anmerkung: Darauf bin ich übrigens eingegangen. Und in kurzer Zeit funktionierte alles. Danke! Ein paar einzelne Bilder fehlen noch – da hatte ich anscheinend ein paar doch nicht so korrekt gespeichert. Das korrigiere ich noch.

  7. Ich hab jetzt auch mal eine Art Umzug gemacht, allerdings andersrum als oft im Netz beschrieben. Zum Testen von WP-Updates, neuen Plugins etc. habe ich eine „localhost“-Installation, d. h. eine Entwicklungsumgebung, die lokal auf meinem Rechner läuft. Wenn da was schief geht, kann ich das besser verschmerzen als beim „echten“ Blog. Die lokale Version war allerdings ziemlich veraltet – die Artikel schreibe ich nur „live“ für das Online-Blog. Nun wollte ich den Stand der Datenbank anpassen. Nach einigen lehrreichen Fehlversuchen hat das geklappt. Letztlich hab ich eine neue Datenbank angelegt, die Tabellen der live-Version dort importiert und in der wp-config.php auf die neue Datenbank verwiesen. (Sicher hätte ich die neuen Tabellen auch in die alte Datenbank kopieren können – ich wollte es halt so machen …) Das Anpassen der Links (von http://statistik-dresden.de auf die localhost-Adresse) klappte per SQL in phpMyAdmin.

    Folgende Tabellen waren bei mir betroffen (bei mir ist noch ein Präfix vor den Tabellennamen, das wird vermutlich bei anderen Blogs anders lauten):
    wp_blc_instances (Feld raw_url)
    wp_blc_links (Felder url und final_url)
    wp_options (option_value)
    wp_posts (post_content, guid, pinged)
    wp_comments (comment_content)
    wp_links (link_image: verweist auf Uploads-Ordner)

    Die Uploads-Ordner musste ich natürlich ebenfalls rüberziehen.
    Kleine Unterschiede zwischen den beiden Blogs gibt es noch bei einzelnen Einstellungen der Plugins – das stört mich grad nicht, wird ignoriert.
    Hier ein Beispiel für einen SQL-Befehl zum Anpassen der Linkstruktur:
    UPDATE `neuewp_datenbank`.`wp_blc_instances`
    SET raw_url =
    replace(raw_url, ‚http://statistik-dresden.de‘, ‚http://localhost/statistik-dresden‘)

    Wünsche allen, die so eine Prozedur durchführen, Erfolg dabei! Gerade bei großen Blogs mit vielen Artikeln würde es mir davor grauen, Link für Link manuell anzupassen. Computer helfen einem schließlich dabei, Probleme zu lösen, die man ohne sie nicht hätte.

  8. Dass Manche erst lokale Installationen vornehmen, hatte ich bei meinen Forschungsarbeiten auch gelesen. Das wegen Updates usw. anders herum zu machen, klingt aber auch logisch.

    Vor den Link-Anpassungen hatte ich auch ein paar Bedenken, aber wie schon erwähnt, haben mir die Leute von meinem webhoster das fix erledigt. Den Rest hat mir das Plugin „Broken Link checker“ angezeigt. Das war ziemlich viel, lag aber meist nur an (durch mich) schlampig abgespeicherten Bildern und ließ sich durch Zuordnung der Bilder in die richtigen Ordner einfach beheben. Wichtiger war aber, dass tatsächlich viele externe Links inzwischen falsch waren. Das hätte ich ohne das Plugin nie bemerkt. Das habe ich inzwischen korrigiert, was deutlich mehr Arbeit war. Dabei habe ich bemerkt, dass mein einstiger eifrigster Kommentator Michael W. inzwischen seine gesamte digitale Existenz gelöscht hat, denn alle seine Links auf seine eigenen Blogtexte führten inzwischen ins Leere. Auch irgendwie bemerkenswert …

Comments are closed.