Datenübernahme vom alten xt:Commerce Shop (Gambio, modified, etc.)

  • Bitte nächstes mal dadrauf achten das keine Passwörter enthalten sind, habs mal weggekürzt, die


    PHP
    1. debug(......);


    Zeilen kannse wieder raus nehmen, die waren nur zum testen.

  • "hhgag" wrote:


    So nun werden auch die Kunden mit fasst allen Infos übernommen, außer dem ersten Eintrag, sprich Admin alter Shop.


    Hallo,
    zuerst dachte ich, der Import hat geklappt, da nach ca. 1 Minute folg. Hinweis auf dem Bildschirm stand:
    Starting conversion
    Starting product conversion


    Wenn ich allerdings dann den Shop aufrufe, dann stehen keine Bezeichnungen etc. dort nur Preise.


    Schaue ich mir dann die Datenbank an, dann stehen in der Tabelle products und in der Tabelle ms_products_of_store ca. 800 Datensätze (in der XT-Datenbank sind aber ca. 5000). Andere Tabellen wie products_description bleiben leer...


    Ok dachte ich, ich lösche alles einmal und setze den Shop nochmals neu auf, damit auch ja nichts in irgendeiner Tabelle schon steht. Neu installiert und dann sofort die Importdatei ausgeführt. Ist allerdings dann das gleiche gewesen (es wurden ein paar mehr Datensätze in die zwei Tabellen geschrieben, das wars dann auch schon).


    Altes System: xtcommerce304 SP2.1


    Mike

  • Höchstwahrscheinlich wird die max_execution_time nicht ausreichen um das Script komplett auszuführen, guck mal bitte nach wie lang dieser ist, würde bei 5000 Artikeln auf ca. 90sek tippen, die dürften reichen. Ansonsten sicherheitshalber auf einen höheren Wert erhöhen, kann ja danach wieder herunter gesetzt werden.


    Es kommt zum Schluss die Meldung, dass die Konvertierung komplett ist (ich meine ich hätte es rot gefärbt).

  • "hhgag" wrote:


    Höchstwahrscheinlich wird die max_execution_time nicht ausreichen um das Script komplett auszuführen, guck mal bitte nach wie lang dieser ist, würde bei 5000 Artikeln auf ca. 90sek tippen, die dürften reichen. Ansonsten sicherheitshalber auf einen höheren Wert erhöhen, kann ja danach wieder herunter gesetzt werden.


    Es kommt zum Schluss die Meldung, dass die Konvertierung komplett ist (ich meine ich hätte es rot gefärbt).


    Ok, so halbwegs hats mal geklappt (habe wohl eine etwas sehr große Datenbank)...
    Beim Import habe ich aber festgestellt, dass die Umlaute äöüß im HHG-Shop nicht mehr richtig dargestellt werden. Bei blinkyth's Test (siehe http://www.shop.cmt-internetservice.de/) anscheinend auch nicht...
    Habe XT und HHG lokal unter XAMPP installiert. Wenn ich die zwei Datenbanken mit phpmyadmin anschaue, dann werden bei XT die Umlaute richtig angezeigt, bei der HHG-Datenbank nicht, selbst diese nicht, welche direkt im HHG-Shop angelegt werden... An was kann denn das liegen?


    Mike

  • MySQL 5 ?
    Kollationen der Datenbanken identisch?


    Wenn nicht kann es dazu kommen, es wird bei der Tabellenerstellung keine Kollation angegeben, d.h. der Defaultwert wird genommen. Wenn die sich unterscheiden kann es zu Umlautproblemen kommen. Die werden vom Script nicht beeinflußt, da diese von einer Datenbank abgefragt und direkt ohne Bearbeitung ins nächste gejagt zu den entsprechenden Spalten.

  • Hallo,


    MySQL - 5.0.19-nt
    Protokoll-Version: 10
    Server: localhost via TCP/IP
    Benutzer: root@localhost
    MySQL-Zeichensatz: UTF-8 Unicode (utf8)
    Zeichensatz / Kollation der MySQL-Verbindung:
    UTF8_unicode_ci


    phpMyAdmin - 2.8.2.4
    MySQL Client-Version: 5.0.24a
    Verwendete php Erweiterungen: mysql


    sowohl bei XT als auch bei HHG ist bei allen Datenbanken die Kollation latin1_general_ci eingestellt.
    Gebe ich jetzt bei XT und bei HHG im Shop beispielsweise einen Kunden ein mit äöüß und rufe dann phpmyadmin auf und sehe mir die Datenbank customers an, dann ist in der XT-Datenbank äöüß drinn, bei HHG stehen diese Zeichen in phpmyadmin drinn: äöüß
    Im Shop selbst wird es aber richtig dargestellt...


    Importiere ich jetzt in phpadmin eine csv-Datenbank (z. B. für products), dann werden unter phpmyadmin die Umlaute äöüß richtig dargestellt; im Shop von HHG leider dann nicht, sondern dann diese: äöüß


    Mike

  • Stell mal bitte unter Sprache die Kodierung um auf ISO um, Standard mäßig kommt er mit utf-8, kann da dran liegen ;-)

  • Hallo,
    also wenn ich jetzt einmal im Shop die Codieung des Browsers umstelle auf Westeuropäisch (ISO) und dann im Shop einen Artikel oder was anders mit äöüß eingebe, dann wird in phpmyadmin der Zeichensatz auch mit äöüß angezeigt und somit ist dann auch ein Fernzugriff via Access problemlos möglich. Jedoch nach einem Neustart des Browers ist die Codierung wieder auf UTF8. Rufe ich über das gleiche System den XT-Shop auf, ist die Codierung des Browers gleich auf westeuropäisch (ISO) eingestellt...
    Ich glaube, dass Problem gab es auch schon mal bei XT. Im Forum von XT steht dazu, dass man die /lang/german.php abändern müsse:
    @setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.UTF-8', 'German');
    abändern auf:
    @setlocale(LC_TIME, 'de_DE@euro', 'de_DE', 'de-DE', 'de', 'ge', 'de_DE.ISO_8859-1', 'German','de_DE.ISO_8859-15');


    Bei mir ist diese Datei ja bereits von haus auf so...
    So nun dachte ich, wenn ich in HHG in /store_files/(Shop-nr)/lang/german.php die gleiche Stelle ändere, wäre das Problem gelöst. Aber der Shop startet im Browser immer noch mit der Kodierung utf8.


    Kann man das irgenwo anders ändern, dass der Browser beim Shopaufruf immer mit Codierung Westeuropäisch (ISO) startet?


    Mike

  • Hi Mike,


    Du musst es im Adminberiech unter Land/Steuern => Sprachen machen, dort sind die Kodierungen für die Sprachen selbst die setlocale hat nicht mit dem im Header ausgegebenen Informationen zutun, naja nur indirekt =)

  • Hallo,
    ich hoffe, ich nerve noch nicht...
    Ok, wenn ich im Admin-Menü unter Land/Steuer das Land Deutschland auswähle (habe ja nur dieses, da ich englisch gelöscht habe), was muss nun wohin:
    im Feld charset habe ich ISO-8859-1 eingegeben und im Feld Codierung de (steht ja auch schon drinn) und speichere ab. Jetzt starte ich den Browser wieder neu, aber es ändert sich nichts. Wenn ich im IE7 unter ANSICHT -> CODIERUNG gehe, dann wird dort wieder UTF-8 angezeigt...


    Dann habe ich mal folg. angeschaut:
    im Admin/Core-Verzeichnis und im Core-Verzeichnis die header.php
    In beiden php-Dateien habe ich einmal folg. ersetzt:
    charset=<?php echo $_SESSION['language_charset']; ?>"
    durch
    charset=iso-8859-1


    Neustart des Browsers und nun stimmt die Codierung...
    Ich weiß nur nicht, ob das so korrekt ist, oder ob ich nur oben etwas falsch eingegeben habe.


    Mike

  • Hallo,
    kleiner Fehler:
    charset=<?php echo $_SESSION['language_charset']; ?>
    durch
    charset=iso-8859-1
    wurde ersetzt; ein " war zuviel drinn...


    Mike

  • Hmm hattest reigester_globals on wa, wird wohl auch überschrieben :evil:

  • Hmm, hattest register_globals on wenn ich mich recht entsinne, wird wohl irgendwo überschrieben :evil:

  • hmm, naja dann muss das aber auch passen.
    Poste mal hier rein was im Header steht im Shop.


    Unter Land/Steuern => Sprache muss bei der jeweiligen Sprache unter
    Charset die gewünschte Kodierung eingetragen werden und diese erscheint eigentlich auch im Header dann

  • So, jetzt funktioniert es auch bei mir richtig!!!
    Die header.php-Dateien habe ich wieder auf den Originalzustand gesetzt.
    Im Admin-Menü unter Sprache / Steuer die CHARSET auf iso-8859-1 gesetzt und den Browser neu gestartet -> Shop startet mit Codierung ISO-8859-1 im Browser.
    Beweisumlast: Sprache / Steuer die CHARSET auf UTF-8 gesetzt und den Browser neu gestartet -> Shop startet mit Codierung UTF-8
    Wieder im Admin-Menü unter Sprache / STeuer die CHARSET auf iso-8859-1 gesetzt und den Browser neu gestartet -> Shop startet mit Codierung ISO! Na endlich...


    Meister, ich bringe bei Gelegenheit Blumen vorbei und sage DANKE für die laaange Geduld! [Blocked Image: http://smiliestation.de/smileys/Gluecklich/221.gif]


    Mike

  • Kein Problem =)

  • Ich habe das Script gerade auch mal getestet und bin auf ein Problem gestossen:


    In einigen unserer Artikelbezeichung wurde das ' Zeichen verwendet (wie z.B. Fifa '97). Hier gab es nun einen SQL-Fehler.


    gelöst habe ich das Problem, indem ich inc.hhg_db_perform.php wie folgt geändert habe:


    < $query .= '\'' . hhg_db_prepare($value) . '\', ';
    ---
    > $query .= $db->qstr(hhg_db_prepare($value)) . ', ';


    Nun stellt sich mir dir Frage, ob das nicht generell sinnvoll wäre. Zwar konnte ich keinen Fehler im Shop erzeugen - ich konnte aber auch keine Stelle finden, wo ein Escaping vorgenommen wurde. Also das ganze setzt scheinbar auf magic_quotes on.



    Das Import Problem könnte man aber auch so lösen:


    $products_description->fields["products_name"] = addslashes($products_description->fields["products_name"]);


    $products_description->fields["products_description"] = addslashes($products_description->fields["products_description"]);
    $products_description->fields["products_short_description"] = addslashes($products_description->fields["products_short_description"]);


    $products_description->fields["products_keywords"] = addslashes($products_description->fields["products_keywords"]);


    Oder habe ich einen Denkfehler und es ginge alles viel einfacher?

  • wir haben es soweit komplett durch das System umgebaut, das Update ist fertig und wird gleich (wenn ich nicht vorm Laptop vor Schlaflosigkeite nicht einpennen sollte) bzw. Morgen früh Online gestellt.


    Wollte es zwar Heute hoch packen, nur kam mein Nachwuchs Heute Morgen um 5 in die Quere =)

  • &quot;hhgag&quot; wrote:


    ...(wenn ich nicht vorm Laptop vor Schlaflosigkeite nicht einpennen sollte)...


    hmmmm... was denn nun?


    super sache das! schön zu sehen, dass hier taten auf posts folgen. und nicht nur ein "böser" moderator einfach posts löscht.


    macht weiter so. ich werde anfang des jahres unseren store auf hhg ce umziehen. zwar steckt schon 'ne menge herzblut im alten source. aber eine codebasis die wirklich GPL ist gefällt mir einfach besser.