Umzug per CopyPaste spinnt bei WP Sites

[pezi]

Hallo!

Nachdem das installieren eines 7er XAMPP auf Win 10 32bit etwas holprig verlief und mit der Hilfe hier und etlicher Hartnäckigkeit doch glückte, gibt es neue Probleme.

Früher konnte man ja die Webs und mysql Ordner (oder gleich den ganzen XAMPP) einfach auf einen neuen Rechner kopieren und die Site lief (wenn die Pfade gleich waren).
Scheinbar geht das nicht mehr so einfach, zumindest bei den WP-Sites springt immer der Wordpress Installer an. Obwohl alles rüber kopiert wurde, alle Daten und Dateien da sind und die Logins stimmen.

Klar, sauberer ist eine zuvor exportierte *.sql per phpmyadmin in eine neue DB zu importieren. Wenn die Verbindungsdaten stimmen, läuft es.
Und noch besser ist die Installation von WP Sites, die zuvor mit dem Plugin "Duplicator" als lauffähige Kopie samt Installer vorliegen.

(Websites, welche nicht auf WP basieren (ja sowas gibts noch) also mit selbstgestrickten CMS, die laufen sofort.)

Also: Was könnte WP Sites, welche nur per Copy/Paste umgezogen wurden, so stören, dass sie eine neue Installation machen wollen? (Die übrigens nicht funzt, es hagelt dann 1000 Fehlermeldungen bez. Table exist - auch wenn sie nicht da sind ... usw.)

PS: Der eigentlich einzige Unterschied zwischen den beiden XAMPPs ist, das der "alte" (auch eine 7er Version) eine 64bit Version war und die neue hier muss temp. mit 32 bit laufen.

[Nobbie]

Also wenn copy & paste, dann geht das nur wenn man auch das komplette Xampp umzieht. Also einfach den ganzen Xampp Ordner kopieren. Aber von einem Xampp zu einem anderen Xampp die inneren Verzeichnisse zu kopieren, das kann an tausendundeins Gründen scheitern, insbesondere MySQL/MariaDB entwickelt sich so schnell weiter, dass die kopierten Daten nicht unbedingt kompatibel sind. Außerdem sind die verschiedenen Xampps auch oft unterschiedlich konfiguriert.

Und eine Kopie von 32bit nach 64bit würde ich gar nicht erst versuchen, auch in Datenbanken gibt es binäre Integerfelder und genau die werden dann mit 64bit dargestellt statt mit einst 32bit. Also so geht es leider nicht, entweder den ganzen Xampp Ordner kopieren oder zumindest sicherstellen, dass exakt die gleichen Xampp Releases installiert sind (was aber auch nicht der Fall ist).

[pezi]

Also wenn copy & paste, dann geht das nur wenn man auch das komplette Xampp umzieht.

Ok, wäre besser.

...die inneren Verzeichnisse zu kopieren, das kann an tausendundeins Gründen scheitern, insbesondere MySQL/MariaDB entwickelt sich so schnell weiter, dass die kopierten Daten nicht unbedingt kompatibel sind. Außerdem sind die verschiedenen Xampps auch oft unterschiedlich konfiguriert.

Klingt auch logisch

Und eine Kopie von 32bit nach 64bit würde ich gar nicht erst versuchen,

Ok, verstehe.

Was ich aber nicht verstehe:
Warum klappt das noch immer bei den Steinzeit Sites mit selbstgebastelten CMS? Ist die heutige WordPress Struktur (va. bez. DB) vielleicht so viel ... komplexer? Irgendwas muss ja ausgerechnet WP an dieser meiner russischen Methode stören ...

Egal: Die alten Sites (sind eh nur mehr ein "Museum") funzen.
Neueres, also WP und CP basierende installiere ich eben völlig neu. Bzw. eben per phpmyadmin uo. Duplicator umziehen.

Somit ist das halbwegs klar, die eigentlich eher theoretische Frage fast gelöst.

Danke!

[Nobbie]

Was ich aber nicht verstehe:
Warum klappt das noch immer bei den Steinzeit Sites mit selbstgebastelten CMS?

Ich würde vermuten, dass das an der früher benutzten "Engine" (das ist eine Zugriffsebene, wie MySQL intern die Daten speichert) "MyISAM" liegt. Damals entsprach eine Datenbank einem Ordner unter Windows und jede Tabelle entsprach einem Tripel gleichlautender Dateien, nur mit drei verschiedenen Endungen. In einer der drei Dateien wurde die Tabellenstruktur deklariert, in der zweiten Datei standen die Tabellendaten und in der dritten die ganzen Indizes (auch "Schlüssel" genannt). Diese Schicht war ziemlich lange kompatibel über viele Releases hinweg, die wird seit langem nicht mehr weiterentwickelt (was aber genau gut ist, dadurch ändert sie sich auch nicht mehr). Seit einigen Jahren benutzt MySQL/MariaDB aber nicht mehr die Engine MyISAM, sondern stattdessen InnoDB. Das hat technische Gründe, damit wurden Features realisiert, die man mit MyISAM nicht mehr realisieren konnte. Bei InnoDB ist aber die Datenstruktur auf der Festplatte komplett anders, da gibt es keine Ordner und Dateien für Datenbanken und Tabellen, es gibt eine monströse Datei mit Namen "ibdata1" und da steht alles drin. Und diese Datei ist intern ggf. von Release zu Release nicht mehr kompatibel. Das (so vermute ich) ist das grundsätzliche Problem.

Wenn man richtig Ahnung von der Materie hat, dann kann man auch heute noch WordPress bzw. seine Xampp Installation anpassen, dass MyISAM benutzt wird statt InnoDB. Wahrscheinlich hat man dann die Kompatibilät von früher wieder, aber garantieren kann ich es nicht. Insgesamt erscheint mir InnoDB sowieso (zumindest unter Windows) sehr instabil zu sein, es gibt irrsinnig oft in diesem Forum das gleiche Problem, dass auf einmal die Datenbank nicht mehr funktioniert. Das schiebe ich auf Probleme mit InnoDB, speziell unter Windows. Ich betreibe schon lange kein Windows mehr und habe solche Problem unter Linux nicht. Aber das ist eine andere Baustelle.

[pezi]

Ich würde vermuten, dass das an der früher benutzten "Engine" (das ist eine Zugriffsebene, wie MySQL intern die Daten speichert) "MyISAM" liegt.

Das fiel mir auch auf. Und es stimmt! Nur die neueren Installationen sind InnoDB und genau die funzen nicht wegen der hanebüchenen Kopiererei.

Damals entsprach eine Datenbank einem Ordner unter Windows und jede Tabelle entsprach einem Tripel gleichlautender Dateien, nur mit drei verschiedenen Endungen.

Ja genau, irgendwas mit myd frm usw.

Bei InnoDB ... gibt eine monströse Datei mit Namen "ibdata1"

Stimmt. Habs versucht nun diese und andere zu kopieren und XAMPP/MySQL neustarten, doch da kommt ein Fehler, der meint, das eine Tabelle der phpmyadmin DB, namens "pma__column_info" nicht existiert. Besser ich lasse solche Experimente, sonst darf ich gleich nochmal XAMPP installieren.

eProbleme mit InnoDB, speziell unter Windows

Oje ...

Ich betreibe schon lange kein Windows mehr und habe solche Problem unter Linux nicht. Aber das ist eine andere Baustelle.

Stimmt auch. Habe ich eh versucht. Hpts. mit Mint, aber leider nie eine unfallfreie Installation hinbekommen. Schade, weil wenns mal läuft gibts nur mehr Vorteile.