WordPress-Neubau gar nicht so einfach, wie gedacht

Was will denn der Uhle jetzt mit einem WordPress-Neubau? Es läuft doch alles. Ja, das ist auch so, und da bin ich auch froh drum. Aber so einfach ist es dann doch nicht. Es gibt einen ganzen Sack von Gründen, wieso man einfach mal testen sollte, ob man seinen Blog umziehen kann. Das habe ich gemacht und bin erschrocken. Warum, wieso, weshalb? Das werde ich mal eben erzählen. Vielleicht kommen ja andere Nutzer von WordPress auf andere Ideen oder stehen vor dem gleichen Problem.

Wozu ein WordPress-Neubau?

Es gibt allerlei Gründe, wieso es mal zu einem Neubau der WordPress-Installation kommen kann oder muss. Nehmen wir doch einfach mal das Beispiel, dass man den Hoster wechseln möchte. Oder wir haben uns überlegt, einen – nun ja – Abzug des Blogs in eine Testumgebung reinzuladen. Oder es ist etwas an der WordPress-Installation kaputt gegangen, was sich nicht einfach so reparieren lässt.

Ich wollte also einige Dinge probieren und dabei nicht am offenen Herzen operieren. Das ist so der klassische Fall. Dazu habe ich mir der Einfachheit halber auf meinem Computer den XAMPP installiert. Ich bin darauf gekommen, nachdem ich diesen Artikel gelesen hatte. Ich hatte schon mal vor langer Zeit den XAMPP im Einsatz, und nun war es wieder so weit. Aber: Oh, weh mir, das Backup ließ sich nicht herein zaubern. In solchen Situationen kommt man schon ins Schwitzen. Eben weil ein WordPress-Neubau jederzeit passieren kann.

Was habe ich denn versucht?

Es gibt ja verschiedene Möglichkeiten, einen Blog mit WordPress mal zu exportieren. Ich nutze zum Beispiel das Backup-Tool „Updraft Plus“. Das baut mir ein Backup aus Datenbestand und Datenbank, komprimiert das Alles und schiebt es zu Google Drive und damit weg vom Server. Ich wollte einfach mal testen, wie es denn funktionieren würde, den Blog wiederherzustellen, wenn „Updraft Plus“ nicht zur Verfügung steht. Also habe ich in XAMPP den PHPMyAdmin gestartet und dort versucht, die Datenbank zu importieren. Und das ging schief. Auch Anpassungen der php.ini änderten nichts. Die Datenbank ließ sich nicht importieren.

Also dachte ich mir, dann muss es eben anders gehen. Ich bin über Werkzeuge -> Daten exportieren gegangen und wollte irgendwas exportieren. Irgendwas deshalb, weil gar nichts funktionierte. Wenn ich den Export-Versuch starten wollte, landete ich auf der Startseite meiner Webseite. Das kann doch so nicht stimmen. Ich habe dann mit „WP All Export“ und „WP All Import“ versucht, die Artikel zu exportieren und in XAMPP zu importieren. Aber beim Import muss ich jeden Artikel einzeln importieren? Über 4700 Artikel? Das ist nicht euer Ernst.

So wird das natürlich nichts mit einem WordPress-Neubau. Ich denke, ich mache das Ganze wie früher auch schon. Ich nutze den MySQLDumper, der inzwischen MyOOSDumper heißt, aber immer noch so funktioniert. Mit ihm habe ich perfekt meine Backups machen können. Und nachdem ich in dem Tool auch Datenbanken wiederherstellen kann, kann ich den MyOOSDumper ja auch bei XAMPP installieren und den dort benutzen.

Mein Plan zum WordPress-Neubau

Die hier laufende Installation ist seit April 2009 aktiv. Es wurden Plugins installiert und wieder entfernt, zeitweise trug der Blog einen Fehler mit sich herum und lud nicht korrekt, es war ein stetes Auf und Ab. Es spricht also nichts dagegen, den dann doch mal perspektivisch neu zu bauen. Ich habe damit keinen Stress. Aber man muss ja wenigstens eine Strategie haben, wie es denn gehen könnte, wenn der Blog mal kaputt ist. Und da verfolge ich folgenden Plan:

  1. Installation von XAMPP
  2. Installation von WordPress
  3. Installation von MyOOSDumper in XAMPP
  4. Umzug des Blogs in die Testumgebung mit MyOOSDumper

Ich muss dann halt einen ganzen Haufen Anpassungen machen. So habe ich, weil es vor Jahren noch möglich war, einen angepassten Pfad zu den ganzen Medien hier im Blog. Das ist seit einigen Versionen schon nicht mehr möglich. Und wenn ich es mir einfach machen will, muss ich WordPress mitteilen, wo die Medien liegen. Hier muss in der Datei wp-config.php nach „require_once(ABSPATH.’wp-settings.php‘);folgender Eintrag hinzugefügt werden:

define('UPLOADS', 'Ordnername');

Solche Anpassungen gibt es einige hier im Blog. Und da muss ich mich halt einfach mal durcharbeiten. Als Ziel steht da, dass ich einfach eine perfekt eingerichtete Testumgebung vorliegen habe, mit der es mir vielleicht sogar möglich ist, den hier aktiven Blog zu ersetzen. Ich meine, der Gedanke wäre dann ja, eine „Hier wird gearbeitet“-Seite hinzustellen, die Seite zu löschen und den Schritt 4 oben einfach Richtung Webserver zu machen. Aber das muss ich mir noch überlegen.

Warum mache ich das?

Es sind so kleine Dinge, bei denen man merkt, dass der Blog irgendeinen Fehler mit sich herum schleppt. Das ist ja auch nach fast 9 Jahren kein Wunder. Zeigen Sie mir das Windows, das so lang durchhält, ohne zwischendurch neu installiert worden zu sein. Wenn ich zum Beispiel in den Theme-Dateien keine Änderungen vornehmen kann, ohne dass mir meine Seite ausfällt, dann muss irgendwas nicht stimmen. Und da ist es einfach an der Zeit, sich Gedanken darum zu machen, wie es weitergeht. Ich werde mir jedenfalls etwas einfallen lassen müssen. Es scheint nun also doch ein WordPress-Neubau anzustehen.

10 Replies to “WordPress-Neubau gar nicht so einfach, wie gedacht”

  1. Ich habe schon einige Blogs umgezogen und denke die letzten Male liefen schon sehr unaufregend und schnell ab. Die Unbekannte ist meiner Meinung nach sehr oft der Hoster zu dem man übertragen will. Ein neues Backend, ein neues DB Tool usw. können da dann zum Hindernis werden.

    Was ich hingegen noch nie gemacht habe, es fiel mir erst mit dem Lesen dieses Artikels auf, ist zu versuchen den Blog aus einem Backup wiederherzustellen. Warum das so ist? Keine Ahnung – set & forget einer Backuplösung sind eigentlich ein Anfängerfehler. Sei´s drum – ich stehe zu meinem Fehler und werde deinen Test mal mit meiner Backuplösung durchführen (Xcloner)

    1. Also ich habe das schon mal mit dem MySQLDumper und FTP und so gemacht. Das ging alles. Ich wollte aber mal den ganzen Ballast loswerden. Und was mich auf die Palme bringt, ist das der Export nicht mehr funktioniert.
      Ich habe mit Updraft Plus eine Wiederherstellung versucht. Das ging schon gar nicht so schlecht. Aber ich muss da noch weiter rumprobieren.

  2. Kann auch nur MyOOSDumper wärmstens empfehlen. Ich nutz immer noch die Vorgängerversion davon und hatte niemals Probleme damit. Das beste Tool überhaupt um die DB zu sichern und wiederherstellen. Ich mach damit täglich mein DB Backup.

    1. Der Vorgänger funktioniert noch? Dann hast du aber bestimmt kein PHP 7.x. Denn erst damit funktioniert der MySQLDumper nicht mehr. MyOOSDumper wurde deshalb ja überhaupt erst entwickelt. Aber du hast Recht, das funktioniert prächtig.

      1. Richtig. Ich hab den noch mit MySQL 5… laufen. Ist eh abgetrennt von Rest da stört mich das nicht. Der „Nachfolger war mir zu arg zusammengefriemelt. Ist inzwischen vielleicht besser, müsst ich mal wieder anschauen.

  3. Hallo

    Schau Dir mal „Duplicator“ von https://snapcreek.com/ an.
    Wir nehmen nur mehr das, denn:
    – urschnell: Unsere größte Site, beinahe 5000(!) Artikel, fast 4GB Bilder ist in unter einer 1 Stunde (kopiert)
    – die Kopie lässt sich überall installieren, auch am XAMPP
    – dafür sorgt ein eigener Installer der fürs Zielsystem mitgeliefert wird
    – Pfade werden dabei automatisch auf die neue Umgebung umgebogen
    – jede Menge Kriterien (Auschluß von Dirs, usw.)
    – Testtool, um etwaige Probleme im Vorfeld erkennen
    – das alles kostet nix (ok, es gibt ne Pro-Variante, ab 39,-)

    1. Nun ja, damit habe ich mich vorhin aus dem Blog ausgesperrt. HTTP 503, BruteForce Schutz. Nach dem Umbenennen des Verzeichnisses in FTP war mein Blog wieder verfügbar.
      Wahrscheinlich hat sich der Duplicator mit Updraft Plus behakt. Ich muss da noch weiter schauen. Aber prinzipiell hast du Recht. Damit kann man viel machen.

      1. aha – das tut mir leid

        komisch, habe jede unserer Kleinen Sites, einige mittlere Kundensites und das große News-Magazin-Blog damit gesichert und etliche davon am XAMPP wieder installiert. (Wobei: Alle Projekte entstehen ohnehin am XAMPP – mit dem Plugin habe ich testweise halt noch eine Instanz nebenbei installiert).

        Updraft Plus kenne ich ja nicht, weiß auch nicht ob es einen Konflikt mit Duplicator geben könnte. Möglich, ja. Ich würde ja alle ähnlichen Tools restlos deinstallieren (auch in der DB nach Resten schauen) und es dann mit Duplicator versuchen.

        „HTTP 503, BruteForce Schutz“
        Das große Blog sitzt auch hinter 3 Schutzmechanismen, inkl. Cloudflare und reagiert recht heikel auf gewisse Veränderungen, auf neue Scripts, Tools usw. – doch Duplicator durfte damit alles tun.

        Hast da irgendwelche Schutzmechanismen (Serverseitig, Dienste, Plugins), welche diese „BruteForce Schutz“ Meldung ausgeben? (Muss man aber jetzt nicht hier öffentlich nennen, braucht ja nicht jeder zu wissen)

        Bei welchen Schritt der Installation/Aktivierung kam das? Oder erst beim Archiv erstellen?
        Hier, in https://wordpress.org/support/plugin/duplicator gibts auch ein paar Meldungen bez. Statuscodes im 500er Bereich – evtl. hilft das. Einige davon tippen auch auf Cloudflare…

        1. Nee, das war anders. Ich habe das Tool installiert und getestet. Ich wollte mich später weiter damit beschäftigen. Und beim nächsten anmelden kam der BruteForce-Schutz. Irgendwas anderes als das Tool habe ich nicht gefunden. Und der Blog funktioniert ja auch wieder, seitdem ich das entfernt habe.

          Ich werde mich mal wieder mit MySQLDumper beschäftigen. Das habe ich ja alles verlinkt. Damit dürfte wenig schief gehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert