ShopNix

Tagebuch eines Shops auf Basis von osCommerce

Archive for the ‘osCommerce’ 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

Produktvarianten per Stückliste

leave a comment »


Hierbei handelt es sich um eine einfache Methode, Produktvarianten mittels Stückliste zu hinterlegen und in dieser Form in den Warenkorb zu transferieren. Dazu benötigen wir eine zusätzliche Tabelle, in die der Hauptartikel, eine laufende Nummer pro Produktvariante, die Stücklistenposition und deren Menge eingepflegt wird. Dies geschieht zumindest vorläufig auf Basis einer Excel-Tabelle, die anschließend in die Tabelle sx_variant der Shop-Datenbank importiert wird.

Das Programm product_info.php erhällt eine kleine Erweiterung, die diese Stückliste ggfls ausliest und in den Warenkorb kopiert.

Beispiel für den Aufruf: http://xxx/product_info.php?products_id=34437&variant=1

Written by spessart

2. März 2010 at 13:19

Veröffentlicht in Erweiterungen, osCommerce

Tagged with , ,

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

Linkverfolgung

leave a comment »


Ich möchte gerne wissen, wie gut externe Links auf meinen Shop bzw. auf einzelne Produkte angenommen werden. Die einfachste Möglichkeit, solche Links differenziert aufzunehmen ist die Vergabe einer ID, die an den Link angehängt wird. An zentraler Stelle (am Ende des Scripts includes/application_top.php) hänge ich eine Funktion an, die auf die GET-Variable „idseo“ prüft und ggfls. einen Zähler hochsetzt. Dazu ist natürlich auch die neue Tabelle sx_idseo in der Datenbank nötig.

Der Link sieht dann beispielsweise so aus:

http://vapr.shopnix.de/shop/product_info.php?products_id=26&idseo=3

So kann ich z.B. auch sehen, ob eine geschaltete Anzeige gut angenommen wird, ob mir ein Bannertausch den erwünschten Erfolg bringt und vieles mehr. Natürlich soll das im Backend abzufragen und zu verwalten sein.

Dazu kopiere ich zunächst die Dateien languages.php (Programm und Sprachkonstanten) auf sx_idseo.php und passe entsprechend an.

Dann kommt natürlich der Menüeintrag hinzu, und das alles funktioniert nur, wenn ich auch die Tabellen und Dateinamen als Konstanten in database_tables.php und filenames.php hinterlegt habe.

Solche Techniken können unter der Rubrik SEO (Search Engine Optimization) oder Suchmaschinenoptimierung verbucht werden.

Written by spessart

27. April 2009 at 16:26

xt:Commerce – MySQL 5.0 – Performance

leave a comment »


Die Performance von xt:Commerce ist generell schlechter als die von osCommerce. Das ist zum einen zwangsläufig so, weil mehr Features eben auch mehr Aufwand bedeuten. Ein Teil der Probleme liegt allerdings auch in der kleinen Installationsbasis, die zwangsläufig zu geringerem Feedback führt.

Einen Teil der Probleme kann man durch Tuning der Datenbank reduzieren. Sehr hilfreich ist dazu das Script tuning-primer.sh das z.B. mit wget http://www.day32.com/MySQL/tuning-primer.sh erhältlich ist. Unter Debian ist das Paket bc Voraussetzung für das Script.

Entsprechend der Empfehlungen des Scripts habe ich die Parameter table_cache, read_buffer und join_buffer_size angehoben.

Anschließend habe ich eine Meldung im Supportforum abgesetzt und erhielt postwendend Antwort:

ALTER TABLE `shipping_status` ADD INDEX ( `language_id` );
ALTER TABLE `products` ADD INDEX ( `products_startpage` );
ALTER TABLE `products_to_categories` ADD INDEX ( `categories_id` );
ALTER TABLE `orders_products` ADD INDEX ( `orders_id` , `products_id` );
ALTER TABLE `zones_to_geo_zones` ADD INDEX ( `geo_zone_id` );
ALTER TABLE `tax_rates` ADD INDEX ( `tax_zone_id` );
ALTER TABLE `products` ADD INDEX ( `manufacturers_id` );

Damit reduziert sich das Problem (zumindest auf den ersten Blick) ganz erheblich.

Auf Grund meiner Auswertungen werde ich wohl noch einige Schlüssel hinzufügen. Dabei ist zu beachten, daß diese Indizes natürlich auch von der installierten Version und eventuellen Zusatzmodulen abhängen.

alter table whos_online add index (session_id);
alter table whos_online add index (time_last_click);
alter table specials add index (expires_date);
alter table products add index (session_id);
alter table personal_offers_by_customers_status_1 add index (products_id);
alter table products_description add index (language_id);
alter table customers add index (customers_status);
alter table products add index (products_ordered);
alter table specials add index (products_id);
alter table orders add index (orders_status);
alter table customers add index (customers_email_address);
alter table search_keywords add index (search_text);
alter table products_xsell add index (products_id);
alter table products_xsell add index (products_xsell_grp_name_id, products_id);
alter table content_manager add index (language_id, content_group);

Um Notwendigkeit und Wirkung eines Schlüssels zu testen, betrachte ich zunächst die Queries, die in mysql-slow.log protokolliert werden und kopiere sie mit dem vorangestellten Schlüsselwort „explain“ in den MySQL-Client zur Ausführung. Dann lege ich den oder die Schlüssel an, von denen ich mir eine Performancesteigerung erwarte. Anschließend lasse ich mir wieder mit explain die Auswirkungen anzeigen. Wenn ein Schlüssel keinen Vorteil bringt, lösche ich ihn sofort wieder, denn auch ein Index zuviel ist nicht gut für die Gesamtleistung des Systems.

Written by spessart

30. März 2009 at 16:15

Veröffentlicht in osCommerce, Performance, xtCommerce

Tagged with , ,