Duplicator ist manchmal nicht sehr hilfreich

Nichts gegen das Duplicator Plugin an sich. Es ist wirklich zuverlässig, kinderleicht zu bedienen und nimmt einem WordPress-Entwickler einiges an Arbeit ab. Das Plugin wird ja nicht nur für Webseiten-Umzüge eingesetzt, sondern mehr zum Entwickeln von Seiten, die dann live gehen.

Duplicator zählt zu den Umzugs-Plugins, die sich um alles kümmern: Datenbank und Dateien. Aber gerade bei den Tabellen gibt es da so Eigenheiten beim Duplicator, die einem schnell die gute Laune verderben – wenn man nicht aufpasst.

Beim Re-Import lässt einem Duplicator die Wahl, ob es die Tabellen in einer neuen Datenbank anlegen oder eine bereits bestehende Datenbank benutzen soll. Neue Datenbanken anlegen ist cool – aber dem gewöhnlichen shared Webhosting Nutzer steht dies leider nicht zur Verfügung. Sei es aus technischen Beschränkungen oder weil die Anzahl an erlaubten Datenbanken begrenzt ist.
Gut, denkt man sich – wähle ich eben die Installation in eine bestehende Datenbank. Zugangsdaten eingegeben, Verbindungstest durchgeführt – OK und Installation gestartet. Klappt auch gut, nur dass dafür die gesamte Datenbank erstmal plattgemacht wird, bevor Duplicator da was installiert. Wenn zufällig andere Anwendungen auf der Datenbank laufen (z.B. weitere WordPress Seiten) und da wird kein Datenbank-Backup gefahren – uiuiui. Graue Haare und viel nächtlicher Kaffee sind die Folge.

Und das WordPress Tabellenpräfix?

Aber selbst wenn Duplicator die Datenbank nicht plattmachen würde, hätte man ein hässliches Problem. Die meisten Leute ändern das Standard-Tabellen-Präfix wp_ nicht. Die meisten Leute exportieren auch immer nur aus einer WordPress Installation heraus und Duplicator lässt die Änderung des Tabellenpräfixes nicht zu. Mehrere Tabellen mit dem gleichen Namen in einer Datenbank – das geht nicht. Also selbst wenn Duplicator in eine bereits genutzte Datenbank exportieren könnte – wenn dort schon gleichlautende WordPress-Tabellen liegen, kommt man wieder nicht weiter.

Wie man in diesem Fall vorgehen könnte

Ich behelfe mir in diesem Fall so: Gibt es eine WordPress Installation auf der entsprechenden Datenbank, die gleichlautende Tabellenpräfixes hat, muss entweder diese oder die umziehende WordPress Seite dahingehend abgeändert werden. Wie man die Tabellenpräfixe manuell ändert, habe ich in einem früheren Artikel beschrieben.
Dann ziehe ich mir ein komplettes Backup der Datenbank. Alles. Weil Duplicator eben auch alles löscht.
Dann die Duplicator Installationsroutine durchspielen, sich freuen, dass es geklappt und hat und die gelöschten Tabellen dank des Backups wieder einspielen.

Das klappt natürlich nur wenn Tabellen durchschnittlicher Größe beteiligt sind. Unter Umständen muss man das Backup-Script aufteilen und auch dann gerät phpmyadmin irgendwann an seine Grenzen.

Wie gesagt, wenn es einem der Webserver erlaubt, neue Datenbanken out of the blue anzulegen oder man eine leere Datenbank zur Verfügung hat, ist alles kein Problem. Dann gibt es wenig, was mit dem Duplicator mithalten kann.
Wenn aber genau der von mir beschriebene Fall eintritt, hat man mit dem Duplicator ganz schön Arbeit. Da gibt es andere Plugins, die in Betracht gezogen werden sollten. Mir wurde heute Akeeba empfohlen, was wohl aus der Joomla Ecke kommt.

Schreibe einen Kommentar

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