Ich habe auf meinenm Hosting neben der Produktiv-Installation (in Unterverzeichnis) eine Testumgebung (in parallelem Unterverz.). Beide sind in einem GIT Repository. Auf staging_catalog habe ich soeben ein Update auf 2.1.0.7 gemacht. Seither zeigt sich aber seltsamerweise auf der Produktion ein Umlaut-Problem. Ich befürchte, da hat der Installer irgendwie auf die falsche DB zugegriffen, aber ich verstehe nicht warum, und was er geändert haben sollte. Laut GIT gibt es an den produktiv-Dateien keine Änderung, darum verdächtige ich eine Einstellung in der DB. Die Produktion hat Tabellen mit latin1_swedish_ci, die Test-DB mit utf8_general_ci was mir beides korrekt erscheint. Im Quelltext der produktivseite sehe ich UTF8, obwohl unter catalog/admin/languages.php bei Deutsch iso-8859-15 steht... Gibt es weitere Stellen, an denen man die Zeichencodierung einstellt? Dass beim Update etwas falsch lief, obwohl ich keinen Fehler erkenne, könnte an einer Modifikation von mir liegen: Vor dem Update habe ich in den beiden configure.php Dateien eine änderung eingebaut, die es mir erlaubt, diese im gemeinsamen git-repository von produktion und staging zu haben, und auf der Test-Installation trotzdem eigene Pfad- und DB- Einträge zu haben: PHP: // get local settings if available (used to overwrite path- and db- settings on test-installations) if (@include(dirname(__FILE__) . '/local.configure.php')) { // local.configure.php was included } else { Falls im Verzeichnis vorhanden, wird die Datei local.configure.php included, und die defines darin statt in der originaldatei gemacht. Und diese local- Datei gibt's eben nur in der test-installation, und sie ist nicht mit GIT verwaltet. Was mir ansonsten noch einfällt, das Update-script hat (am Ende, glaube ich) eine Reihe von PHP-Warnings ausgegeben, die ich leider nicht kopiert habe. Ich meine, es ging um "can not open stream..." irgendwas. Wobei das ja nichts mit der porduktiv-installation zu tun haben sollte... Ansonsten scheint die Testinstallation korrekt aktualisiert, wobei, das genau zu sehen, ist wohl schwierig, was würdet ihr da anschauen?
GELÖST! Heute Morgen war das Problem nicht mehr nachvollziehbar, weshalb ich auf eine caching-geschichte schloss. Aber plötzlich waren die Fehler wieder da. Nun habe ich festgestellt, dass es ein caching-Problem auf client-Seite ist. Wenn ich erst die staging-seite besuche (2.1) und danach die production (2.0), bekomme ich dort die Fehler. Dürfte ja eigentlich nicht passieren, wenn die beiden Shops in verschiedenen Unterverzeichnissen wohnen, ist also wohl irgendwo ein kleiner, unwichtiger Bug versteckt...
Wenn die beiden Systeme sauber konfiguriert sind kann so was nicht geschehen,,,,, Über die unterschiedlichen Verzeichnisse und die Datenbankparameter sind die Shops sauber getrennt. Ein möglicher Fehlergrund könnte allerdings das "cache"-Verzeichnis sein, das leider in der Datenbank geführt wird, und daher beim klonen mitwandert., Und das evtl auf das falsche cache-Verzeichnis auf dem Server zeigt. Füge mal in den "application_top.php" (Frontend und Admin) nach PHP: xtc_db_connect() or die('Unable to connect to database server!'); folgendes ein: PHP: define('SESSION_WRITE_DIRECTORY',DIR_FS_CATALOG.'cache/'); ein.
Es liegt tatsächlich am in der DB gespeicherten Session-Pfad. Ich hab's aber nicht in der application top, sondern in den beiden configure.php 's abgelegt. Scheint mir sinnvoller, wegen Updatesicherheit, und auch weil's eben eine konfiguration ist... Oder mache ich einen Denkfehler dabei?