Neu Umzug auf neuen Server schlägt fehl

[Tscherno]

Hallo *,

ich versuche nun schon seit zwei Tagen einen vorhandenen Shop3 auf einen neuen Server umzuziehen. Auf diesen wurden schon ein paar andere Seiten und auch ein Shop4 (allerdings ein kleinerer) erfolgereich ohne Probleme umgezogen.

- Die PHP Version entspricht der alten (5.6)
- Shop-Check zeigt, dass alles passt
- config.JTL-Shop.ini.php => PFAD_ROOT stimmt noch
- Es wurde zuerst eine Plesk-Migration für die Dateien und DB versucht, danach ein manueller Export und Import der DB
- Shopdateien wurden mit neuestem 3.20er Dateien überschrieben
- Rechte wurden wie im Wiki angegeben manuell nochmal gesetzt

Ergebnis => Der Shop läuft scheinbar, es tauchen keine sichtbaren Fehlermeldungen auf. Logfiles zeigen auch nicht. Allerdings werden keine Menüeinträge, keine News, keine CMS Seiten und keine Artikelbilder angezeigt. Die URLs für die Artikelbilder sind auch scheinbar falsch. Ein Webshopabgleich läuft durch. Ich habe auch schon einen Komplettabgleich mit Zurücksetzen der Shopdateien versucht. Auch das Ändern des Templates hilft nichts.

Ich bin hier wirklich am Verzweifeln und habe keine Idee wo es liegen kann. Irgendwelche Vorschläge was ich noch probieren könnte?

 

[css-umsetzung]

Lass lieber jemanden schauen, der das ständig macht.
Wenn du da plesk laufen hast, brauchst du mit dem richtigen php modul auch keine speziellen rechte.

Niemand weiß, was du eventuell falsch gemacht hast, bevor er es nicht gesehen und selbst überprüft hat. Dein Problem hört sich komisch an, könnte am cache oder an deiner session liegen, (ja session).

 

[Tscherno]

Lass lieber jemanden schauen, der das ständig macht.

Ich würde schon gerne verstehen was das Problem ist. Es ist nicht so, dass ich sowas in der Art nicht schon gemacht habe. Das ganze sollte ja kein Hexenwerk sein => Datenbank migrieren, Dateien migrieren und Rechte ggf. anpassen.

Wenn du da plesk laufen hast, brauchst du mit dem richtigen php modul auch keine speziellen rechte.

PHP läuft as FastCGI mit dem entsprechenden User des Webspaces. Die Cache-Ordner werden auch nach dem leeren wieder befüllt.

Niemand weiß, was du eventuell falsch gemacht hast, bevor er es nicht gesehen und selbst überprüft hat. Dein Problem hört sich komisch an, könnte am cache oder an deiner session liegen, (ja session).

Welcher Cache? Object-Cache habe ich schon deaktiviert. Browser-Cache eher nicht, tritt auch ohne Cache bzw. mit anderem Browser auf. Session also eher auch nicht.

 

[css-umsetzung]

Was mir sorgen macht, das dein versuch das über plesk zu migrieren schon nich geklappt hat, dann hast du das selbst exportiert, wie hast du das exportiert, über die shell? Eine Datenbank würde ich nur über die shell ex und importieren oder mysqldumper nehmen.

Dann hast du das mit den neusten 320er Dateien überschrieben, was war es denn vorher, hast du dann das update gestartet oder war es schon der neuste 320er?
Was ist mit den dns Einträgen, sicher das du den neuen aufrufst?

Fcgi benötigt keine schreibrechte, was sagt das errorolog, hast du mal die Fehlerausgabe vom shop aktiviert?



Da sind so viele Fragen offen....

 

[Tscherno]

Was mir sorgen macht, das dein versuch das über plesk zu migrieren schon nich geklappt hat, dann hast du das selbst exportiert, wie hast du das exportiert, über die shell? Eine Datenbank würde ich nur über die shell ex und importieren oder mysqldumper nehmen.

Also ich hatte die letzten Jahre eigentlich nur positive Erfahrungen mit dem Plesk Migrator gemacht, aber natürlich kann immer was schief gehen. Der Export danach war per phpMyadmin. Kann natürlich auch was schiefgehen. Daher habe ich heute nochmal von vorne einen sauberen Export per mysqldump und eine saubere Kopie per scp durchgeführt. Leider ist das Ergebnis wieder identisch.

Dann hast du das mit den neusten 320er Dateien überschrieben, was war es denn vorher, hast du dann das update gestartet oder war es schon der neuste 320er?

Das war nur ein Versuch um eventuelle Dateiprobleme auszuschliessen. Die Version war natürlich die identische. Aber jetzt habe ich per scp ja eine 100%ige 1:1 Kopie die nicht funktioniert.

Was ist mit den dns Einträgen, sicher das du den neuen aufrufst?

Ja. Mittlerweile habe ich zum Testen auch eine subdomain, das führt natürlich zu Problemen mit den Lizenzen. Aber das erklärt auch nicht das Verhalten des Shops die Links zu den Bildern und die Seiten nicht richtig aufzubauen.

Fcgi benötigt keine schreibrechte, was sagt das errorolog, hast du mal die Fehlerausgabe vom shop aktiviert?

Warum benötigt FastCGI keine Schreibrechte? Der unterschied ist doch nur, dass die PHP-Prozesse normalerweise mit dem "korrekten" User laufen und nicht alle im Apache-Kontext. Dieser User braucht natürlich trotzdem die Schreibrechte - hat er auch.

Errorlog sagt leider auch nichts. Du meinst /admin/systemlog.php ? - oder gibt es noch andere Loggingausgaben?

 

[css-umsetzung]

Nein ich meine das Errorlog vom Server, wenn du plesk hast kannst du das bestimmt auch einsehen.

nochmal zu Plesk und der migration, ich finde diese, wenn man Plesk hat toll, weil alles einfach und unkompliziert geht, mich wundert nur das es bei dir nicht geklappt hat.

Ich bin noch weihnachtlich angehaucht 🙂 rufe mich an dann schauen wir per Teamview drauf.
Kontaktdaten sind in meinem Impressum.

 

[Tscherno]

Ich konnte leider in keinem Logfile irgendwelche Hinweise finden. Danke für das Supportangebot. Ich werde mich noch etwas damit rumärgern, dann komme ich nochmal auf dich zu.

Was ich jetzt getestet habe und was wirklich interessant ist: Ich habe eben mal den Shop auf dem neuen Server auf Shop4 aktualisiert (nur so eine Vermutung, da ich ja auf dem gleichen Server einen anderen Shop4 ohne Probleme umziehen konnte). Siehe da: Alles funktioniert scheinbar wunderbar. Alle Seitenelemente werden sauber geladen, inklusive der Bilder.

Es scheint irgendwo im Shop3 ein Problem mit einer der Serverkomponenten bzw. Einstellungen zu geben. In der identischen Umgebung klappt es mit Shop4. Hauptunterschied der mir einfällt ist ioncube. Beim neuen Shop sind die Dateien ja nicht mehr verschlüsselt. Plugin sollte es keines sein, die habe ich testweise auch alle deaktiviert.

Die Loaderversionen sehen aber laut PHP-Info bei beiden gleich aus - PHP ist ebenso bei beiden 5.6.29:
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v5.0.18, Copyright (c) 2002-2015, by ionCube Ltd.
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Ich werde später nochmal von vorne migrieren und die Einstellungen und Umgebung Schritt für Schritt vergleichen. Was definitiv noch ein gutes Stück neuer ist, ist MySQL bzw. MariaDB. Der neue Server läuft auf 5.7.16, der alte auf 5.5 irgendwas.

 

[css-umsetzung]

also der 4er selbst braucht kein Ioncube mehr, nur der 3er. Nachdem du ja sagtest du hast die Datenbank mit mysqldump exportiert hast du ja auch einen Serverzugriff.
die logs sind in /var/ww/vhost/system/domain/

in den neueren Plesk Versionen kann man die auch über den Adminbereich aufrufen.

 

[Tscherno]

Ich hatte die Logs schon überprüft. Da kommen keinerlei relevante Meldungen.

 

[css-umsetzung]

dann lass den Profi dran 🙂

 

[Tscherno]

dann lass den Profi dran 🙂

Was würde der machen?

 

[css-umsetzung]

Per teamview kostenlos schauen
So in ca. 2 stunden

 

[Sternchen_ella]

Hallo, konntet ihr das Problem lösen? Ich stehe vor selbigen

Danke im Voraus

 

[css-umsetzung]

Das ist lange her, das lief auf einem lokalem system glaube ich da war ich auch am wundern.

 

[Sternchen_ella]

Mein Shop liegt auf einem externen Php-Server, welche bald abgeschaltet wird. Ich bräuchte etwas Hilfe ... Ich habe Ihnen eine Anfrage über "Unterhaltung" gesendet.

 

[Tscherno]

Hallo,

kein lokales System, ein frischer Webserver. Es lief auch beim nächsten Versuch nicht. Was funktionierte (kannst ja mal ausprobieren) war der Shop auf dem neuen Server nach Upgrade auf Shop4. Wir wollten sowieso auf Shop 4, daher machen wir jetzt erst Shop4 (morgen Abend, wenn alles klappt) und danach erst den Umzug. Es scheint beim Shop3 an irgendeiner Stelle eine Inkompatibiltät mit der neuen Umgebung zu geben.