ShopNix

Tagebuch eines Shops auf Basis von osCommerce

Archive for the ‘xtCommerce’ Category

Übersetzungshilfe

leave a comment »


Die Übersetzung der sprachabhängigen Komponenten einer Software ist oft ein mühsames Unterfangen, zumal die Übersetzer ungern in der Syntax sprachabhängiger Dateien arbeiten. Zudem haben sie erst nach etlichen Arbeitsschritten die Möglichkeit, das Ergebnis ihrer Bemühungen im Zusammenhang zu sehen.

Deshalb habe ich ein kleines Programm geschrieben, das sowohl mit der in PHP weit verbreiteten Variante mit Konstanten zurecht kommt, als auch die Syntax der Smarty-Template-Engine versteht.

Für die Einrichtung sind Vorkenntnisse in PHP und MySQL erforderlich. Das Ergebnis ist eine Weboberfläche, auf der auch ein Übersetzer ohne derlei Kenntnisse arbeiten kann. Lediglich für die Übernahme eventuell enthaltener Formatierungen und Variablen muss er möglicherweise eine kurze Einweisung bekommen.

Die zu übersetzenden Termini werden im Zusammenhang mit den Kontext des Programms in Blöcken angeboten, vor dem Block steht die Konstante bzw. Variable, oben der Text in der Ausgangssprache darunter jeweils ein Eingabefeld für die Zielsprache.

Der Übersetzer kann jederzeit auf Mausklick die Zieldateien erzeugen und im parallel installierten Zielprogramm sein Ergebnis im Zusammenhang überprüfen.

Die Software steht unter dem Titel sx-translator auf SourceForge zum Download bereit. Da es im Zusammenhang mit dem modified Shop entstanden ist, sind die mitgelieferten Tabellen bereits für diesen Shop vorbelegt. Wer das System für andere Zwecke einsetzen möchte, muss dessen Dateien anlegen und die Sections der Smarty language.conf einpflegen. Das geht bisher noch nicht über die Weboberfläche. Die Dateien der Quellsprache werden dann in die DB eingelesen, anschließend sollte diese Funktion in der  Konfiguration gesperrt werden.

Auf Anfrage kann auch eine Testumgebung gestellt werden. Bitte verwenden Sie dazu die Kommentarfunktion.

Advertisements

Written by spessart

16. Mai 2013 at 20:05

Artikel Import aus xtCommerce und CAO nach OpenERP

with 3 comments


Ein Kunde will von seinem alten Warenwirtschaftssystem CAO auf OpenERP umsteigen. Natürlich will er seine Artikel nicht noch einmal von Hand eintupfen.

Dabei stellt sich das Problem, daß er nur die aktiven Artikel aus dem Shop übernehmen will, wesentliche Daten jedoch nur in CAO vorhanden sind.

Deshalb werde ich die Artikel aus dem Shop holen und nach OpenERP importieren. Anschließend schiebe ich einzelne Attribute aus CAO nach.

Die Kunden sollen komplett aus CAO WaWi übernommen werden.

Direkt in die Datenbank von OpenERP zu schreiben ist zwar möglich, aber es bietet sich an, die XML-RPC-Schnittstelle des ERP-Systems zu nutzen. Damit soll sichergestellt werden, daß alle notwendigen Referenzen und Abhängigkeiten erfüllt werden.

Grundlage ist das Beispiel aus der Dokumentation.

Die Methode funktioniert an sich sehr gut. Die Ermittlung der erforderlichen Attribute kann über den Debug-Modus des OpenERP-Clients erfolgen. Dazu wird der Client im Terminal mit dem entsprechenden Parameter gestartet und die Ausgabe auf eine Datei umgeleitet.
./openerp-client.py -l debug_rpc &> ~/debug_rpc.txt

Ein Problem, das ich nicht lösen konnte: Der Primärschlüssel wird ignoriert. Im Allgemeinen ist das nicht kritisch, lediglich für den Kategoriebaum kann ich die Daten nicht übernehmen.

Sollte irgendjemand in der großen weiten Welt eine Lösung haben, möge er die Kommentarfunktion nutzen!

Written by spessart

27. August 2011 at 09:09

epay, ein Zahlungsverfahren im eBusiness

leave a comment »


Die transact Elektronische Zahlungssysteme GmbH ist ein innovativer und unabhängiger Dienstleister für die Abwicklung bargeldloser Zahlungen mit ec-Karte, Geldkarte sowie Kreditkarten.

Mit transact SecurePay steht ein Formular zur Verfügung, das über ein <iframe> in eine bestehende Applikation eingebunden werden kann.

Der Ablauf ist dem Verfahren bei PayPal ähnlich, durch die Einbindung des <iframe> wird der Übergang vom Shop zu einem externen Dienstleister nicht so drastisch in Erinnerung gebracht, der ganze Ablauf wirkt homogener.

Ein Zahlungsmodul für xtcModified ist verfügbar, das mit kleinen Änderungen auch auf osCommerce und xtCommerce läuft. Anfragen bitte per Kommentarfunktion.

Written by spessart

22. August 2011 at 20:34

Zeichensätze im Shop

leave a comment »


Inzwischen ist der internationale Zeichensatz utf8 schon fast Standard. Wer Shops in verschiedenen Sprachen betreut, wird daher über kurz oder lang darauf umstellen um Konvertierungen zwischen den verschiedenen Zeichensätzen künftig zu vermeiden.

MySQL bietet dazu eine Vielzahl von Parametern, deren Auswirkungen bedacht sein wollen. Die Parametern sind in Systemvariablen abgelegt und können vom Client abgefragt werden.

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';

Diese Parameter können teilweise auch vom Client per SQL geändert werden und ihr Zusammenspiel ist nicht nur für die Ausgabe wesentlich, sondern auch für die Sortierfolge oder die Suche nach Strings mit dem Schlüsselwort LIKE. In Abhängigkeit von den Einstellungen konvertiert MySQL ggfls. die Ausgabe. Hat man alles richtig gemacht, sieht nicht nur die Ausgabe sauber aus, sondern eine Suche nach einem Suchbegriff mit Umlaut bringt, unabhängig von der Groß- / Kleinschreibung, alle Ergebnisse.

Für meinen VARIO-Helicopter Shop zog ich zunächst einen Dump und kodierte ihn mit dem Linux-Tool recode von iso-8859-15 nach utf8 um. Anschließend fügte ich folgende Zeilen ein:

ALTER DATABASE `3_vario-es` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
set names 'utf8';
set character set 'utf8';

und las den Dump in die Datenbank ein. Um auch die Clientverbindung zum Shop richtig einzustellen, fügte ich anschließend in shop/includes/functions/database.php ab Zeile 22 zwei zusätzliche Zeilen ein:

    if ($$link) {
    	mysql_select_db($database);
// ShopNix.b 
    	mysql_query("set names 'utf8'");
    	mysql_query("set character set 'utf8'");
// ShopNix.e
    }

Aufpassen: Die Funktion muß natürlich auch im Admin-Bereich angepasst werden!

Die sprachabhängigen Dateien habe ich ebenfalls mit recode umkodiert und in der jeweiligen Führungsdatei (z.B. german.php) die Konstanten für die Kodierung angepasst. Aufpassen: Der W3C-Standard will die Schreibweise „utf-8“ für die HTML-Header, MySQL braucht „utf8“!

Zum Umkodieren mit PHP5 muss (unter Debian) das Paket php5-recode installiert sein. Hier ein Beispiel des Funktionsaufrufs: mysql_real_escape_string(recode_string('ISO-8859-1..UTF-8', $row['categories_name'])) im Zusammenhang mit einem Transfer von der alten Datenbank mit ISO-8859-1 Kodierung zur aktuellen Datenbank mit UTF-8.

Written by spessart

11. November 2009 at 09:31

xt-Commerce, Anmeldung funktioniert nicht

leave a comment »


Problem

Nach Neuinstallation funktioniert die Anmeldung nicht, in application_top.php wird bei jedem Versuch eine neue Session angelegt.

Lösung

Die Funktion xtc_get_top_level_domain(SERVER) funktioniert nicht richtig, sie schneidet den Hostnamen ab. Als schneller Hack kann die Variable $current_domain in Zeile 234 mit dem Domainnamen vorbelegt werden.

Bug in Version

xt:Commerce Version v3.0.4

Written by spessart

30. Oktober 2009 at 14:30

Veröffentlicht in Bugs, xtCommerce

Tagged with , , ,

Performance Optimierung

leave a comment »


Alle Queries aus den Programmen zu ziehen, einzeln zu überprüfen und zu optimieren scheint eine Aufgabe für Sisyphos zu sein. Ganz so schlimm wird es allerdings nicht, wenn wir betrachten, daß der Bereich, der wirklich ins Gewicht fällt, doch relativ beschränkt ist. Gerade von den Suchmaschinen werden nur wenige Programme gezogen, wenn robots.txt richtig gepflegt ist. Schwerpunkt der Forschung müssen also die Programme sein, die robots.txt erlaubt, der Schwerpunkt ist index.php und die includierten Module.

index.php enthält keine relevanten Queries.

Fündig werde ich in den Boxen, wobei mir eine Schwäche des Template-Systems auffällt. Eine Trennung von Layout und Inhalt, die Funktionalität im Layout versteckt? Nicht so ganz gelungen.

  • templates/XXX/source/boxes/best_sellers.php
  • templates/XXX/source/boxes/whats_new.php
  • includes/modules/upcoming_products.php

Die drei Scripts sind wesentliche Übeltäter. Die Bestsellers sind leicht zu fassen, den Term
current_category_id in (c.categories_id , c.parent_id)
ersetze ich durch
(c.categories_id = '" . (int)$current_category_id . "' or c.parent_id = '" . (int)$current_category_id . "')
In Zusammenhang mit den richtigen Indizes zur Tabelle categories ist dieses Problem erledigt.

Die beiden anderen Fälle sind nicht so leicht zu lösen. Hier wird wohl eine andere Lösung notwendig.

Fortsetzung folgt. 😉

Written by spessart

22. April 2009 at 15:00

xt:Commerce – Performance

leave a comment »


Nach Einbau eines Moduls für suchmaschinenfreundliche URL brach die Performance des Systems erneut zusammen. Es wird nichts über bleiben, als mit Hilfe der Logfiles die SQL-Queries zu analysieren und nach und nach zu optimieren. MySQL hat, wie jede brauchbare Datenbank, einige Instrumente um ungünstig formulierte Queries aufzustöbern. Im ersten Schritt schalte ich in der Konfiguration (Debian: /etc/mysql/my.cnf) das Protokoll für langsame Queries ein. Für mich sind die folgenden Parameter geeignet:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes

Ich protokolliere also alle Queries, deren Ausführung länger als 2 Sekunden dauert, und solche die keine Indizes verwenden, in einem eigenen Log-File. Ein Beispiel eines solchen Queries:

select distinct p.products_id, p.products_price, p.products_tax_class_id,
  p.products_image, pd.products_name
from  products p, products_description pd, products_to_categories p2c, categories c
where p.products_status = '1' and c.categories_status = '1'
  and p.products_ordered > 0
  and p.products_id = pd.products_id
  and pd.language_id = '2'
  and p.products_id = p2c.products_id
  and p2c.categories_id = c.categories_id
  and '424' in (c.categories_id, c.parent_id)
order by p.products_ordered desc limit 10;

Im MySQL-Client führe ich dieses Query mit dem vorgestellten Schlüsselwort EXPLAIN aus und erhalte als Ergebnis unter anderem die Zahl der sequentiell abgearbeiteten Datensätze. In meinem Beispiel sind das 1786 Datensätze. Davon werden 1780 Sätze verworfen, denn mein Query liefert unterm Strich nur 6 Datensätze zurück. Ändere ich die vorletzte Zeile meines Queries in:

  and (c.categories_id = '424' or c.parent_id = '424')

kann der Optimizer auf Primärschlüssel zurückgreifen und das Query wird performant abgearbeitet. Damit ist zwar die technische Lösung gefunden, aber leider noch lange nicht implementiert. Diese Methode zeigt mir nämlich nicht, wo das Query in der Software vorkommt. Da die Queries in der Shop-Software dynamisch zusammengebaut werden, kann ich auch nicht ohne weiteres nach einer Zeichenkette suchen. Es ist eben wie so oft: Vor den Preis haben die Götter den Schweiß gesetzt.

Dieses spezielle Query fand ich in templates/XXX/source/boxes/best_sellers.php, und stoße damit auf eine erhebliche Schwäche des vielgerühmten Templatesystems. Offensichtlich gelang es nicht, Code und Design zu trennen, denn das Query ist im „Design“ enthalten.

Written by spessart

18. April 2009 at 21:14

Veröffentlicht in Performance, xtCommerce

Tagged with , , ,