Ich habe eine kleine, auf WP 498 basierte Test-Website MIT dem Plugin zu CP migriert. Das ging auch nach mehrmaligen Anstoßen des Upgrades (am blauen Button (s. https://i.imgur.com/emPUR9j.jpg))
Da kam immer: „Eine andere Aktualisierung wird durchgeführt“ (s. https://i.imgur.com/TQxGgUm.jpg) KA, warum? Irgendwann klappte es aber, „Welcome to ClassicPress“ erschien.
So, die Site hatte nun 529 geänderte und 3 neue Dateien - und sie funktionierte!
ABER: Ich konnte keine Kategorie uo. Beiträge aufrufen!
Erst als ich die Permalink-Struktur von „Beitragsname“ zu „Einfach“ änderte, (also mit …/?p=1) ging es.
Was nun?
Habe also das ganze rückgängig gemacht, die WP Version wieder hergestellt. Passt.
Dann alles nochmal migrieren, nun OHNE Plugin
Passt! Alles funktioniert, egal welche Permalink-Struktur man einstellt, alles perfekt!
Anm.: Es wurden vom Vergleichstool nun 528 Dateien als verändert angezeigt. Eine weniger als mit dem Plugin – nur welche? Weiß nicht. Egal, Hauptsache es funzt nun.
Anm.2: Habe mir das Plugin ein bissl angeschaut, (als ob ich mich da auskennen würde ) und mir fiel nur eines auf: Eine der aufgerufenen Funktionen, die irgendwas mit „links“ zu tun hat (function “classicpress_version”), gibt es gar nicht …
Es stellen sich in diesem Zusammenhang mehrere Fragen.
Die erste schon beim Screenshot: Das Plugin merkt an, dass Änderungen an den WP-Dateien selbst vorgenommen worden sind - das sollte man generell vermeiden. Könnte aber auch der Grund für die anschließend von dir beschriebenen Probleme sein.
Daher gleich die nächste Frage: Warum sind manuelle Änderungen an den Standard-Dateien von WordPress vorgenommen worden?
Weitere Fragen:
Welche Plugins sind bei dieser Installation aktiviert? Es kann insb. bei “Sicherheits”-Plugins a la iThemes Security und WordFence zu Problemen kommen, d.h. diese könnten die Migration fälschlicherweise als “Hack-Versuch” identifizieren. Daher wäre eine Liste aller aktiven Plugins sehr praktisch, um ausschließen zu können, dass der Grund für die fehlgeschlagene Migration an einem der genannten Plugins lag.
Wie wurde die WordPress-Installation urspr. durchgeführt? D.h. ist das eine klassische, also selbst hochgeladene und installierte WordPress-Installation, oder etwa eine “App-Installation” via Hosting-Software, also etwa Plesk?
Läuft die Test-Website lokal, also auf deinem eigenen Rechner, oder befindet sich diese bei einem Webhoster oder eigenen Server?
Welche Revision / Version des Update-Plugins hast du installiert?
Hallo w0lf!
Freut mich, dass hier doch jemand deutschsprachiger da ist!
Aha, du meinst wo da steht "modified core files detectet … " oder so. Da dachte ich (wg. schlechtem Englisch) das hieße - diese Dateien werden nun vom Plugin modifizert.
Das tue ich eigentlich nie.
Das einzige wäre die wp-config.php. Hier habe ich evtl. mal die (lokalen) DB Daten eingetragen.
Und wie bei allen Tests am XAMPP define('E_DEPRECATED', true); //E_ALL & ~E_DEPRECATED & ~ uä. Fehler-Ausgaben drin.
Vielleicht war das der Fehler …
Man sollte das migrieren mal mit einer echt frischen WP Installation machen.
Nur wie gesagt: Manuell funzte es ja sofort.
Diese sind installiert:
Accordeon Menu CK + dessen PRO Version (aktiv, sonst sehe ich keine Buttons)
CM Curated RSS Aggregator (zur Zeit der Migration deaktiv)
FooBox Image Lightbox (zur Zeit der Migration deaktiv)
WP Migrate DB (zur Zeit der Migration deaktiv)
Diese Testsite läuft auf XAMPP (noch mit PHP 5.6), also klassisch am localhost. Auf dem alles recht gut läuft. Konfig ist auch so, dass Scripts nicht gleich abbrechen “max_execution_time” uä. sind hochgeschraubt.
Hm … dann gibt es eigentlich kaum noch Faktoren, die zu dem von dir beschriebenen Problemen führen dürften.
Pauschal fällt mir noch ein:
Sprache: Standardinstallation oder auf Deutsch? (wäre bisserl absurd, aber never say never …)
System, auf dem XAMPP läuft: Seit ca. WP 4.2 hat WP die Angewohnheit, bei Installation als auch Upgrades ziemlich heftig die CPU zu belasten; was teils zu internen Timeouts führen kann - das tritt primär bei lokalen Installationen auf (auch XAMPP), aber auch bei relativ unterbutterten Systemen mit sehr eingeschränkten Resourcen (LowEndBox-V-Server mit 1 GB RAM usw.). Und diese Timeouts können auch dazu führen, dass die Dateien nicht vollständig kopiert werden usw.
Daher natürlich die Frage: Auf was für einem System hast du den Migrations-Test mit Plugin durchgeführt? Eine grobe Beschreibung (Prozessor, RAM, Betriebssystem) sollte dafür schon aussreichen.
Als Beispiel: Mein Entwicklungsrechner ist ein ThinkPad T520 mit i5-2540M, 16 GB RAM und Linux Mint 17.3.
naja, ich tippe weiterhin auf die wp-config.php wo ich evtl. zu viel herumgepfuscht habe.
Hätte ich mehr Zeit, würde ich das gerne auf ein neues WP loslassen.
Ich fand ja inzwischen andere (dt.) Nutzer, bei denen es auch geklappt hat. Die haben sich evtl. nicht so dämlich angestellt wie ich.
Dachte Deutsch wäre Standard - wenn ich mir wo ein dt. Paket lade. (und das kommt immer von WP selbst). Aber ja, es ist deutsch.
hmmm, ich habe sehr oft den Taskmanager offen im Systray - sehe also wenn die Leistung plötzlich hochgeht (man täts auch hören - hätte man nicht immer voll aufgedrehte Kopfhörer auf ) Aber da war nichts.
Also so Werte hat die Win-Kiste (ja zugegeben, Windows-Nutzer) hier nicht. Dennoch sollte auch ein 4er AMD mit 8 GB das schaffen. Der stemmte schon ganz andere Sachen …
) und mir fiel nur eines auf: Eine der aufgerufenen Funktionen, die irgendwas mit „links“ zu tun hat (
) Aber da war nichts.
