Linkverfolgung

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.

Performance Optimierung

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.

xt:Commerce – Performance

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.

xt:Commerce – MySQL 5.0 – Performance

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 natürlich zwanglä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 natürlich 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 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.

Admin: Programm ins Menu einbinden

Die Menus liegen, nach Gruppen getrennt, im Verzeichnis admin/includes/boxes. Die sprachabhängigen Konstanten dazu sind z.B. in languages/german.php definiert. Eingehängt werden die Menüs in includes/column_left.php

Das Programm selbst liegt in admin/DATEI.php, die Sprachkonstanten in languages/german/DATEI.php.

Zeichensatz, von ISO-8859-x zu UTF-8

Es gibt eine Reihe guter Gründe, auf den Internationalen Zeichensatz UTF-8 umzustellen.

• Alle Sprachen können im gleichen Zeichensatz behandelt werden
• Betriebssysteme stellen um
• XHTML nennt UTF-8 als Standard
• Browser schalten automatisch auf UTF-8 wenn nicht explizit anderes gefordert wird

Im osCommerce Shop stellt man den Zeichensatz in der ersten sprachabhängigen Datei pro Sprache ein, z.B. in includes/languages/german.php, jeweils ein Mal pro Sprache, für Shop und Admin getrennt.

Standardmäßig wird Deutsch in ISO-8859-1 ausgeliefert, dem Zeichensatz für Westeuropa. Der Wert ist als Konstante definiert [define('CHARSET', 'iso-8859-1');] und taucht im Quelltext der ausgelieferten HTML-Seite als Meta-Tag wieder auf.

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Will ich nun umstellen, genügt es natürlich nicht, nur diese Einstellung zu ändern, denn die soll nur den Browser darüber informieren, wie die Seite zu interpretieren ist. Ich muss außerdem die sprachabhängigen Dateien umkodieren. Unter Linux geht das sehr schön mit dem Tool “recode”.

recode ISO-8859-1..UTF-8 german.php

Der gegebene Anlaß für diese Aktion ist die Anforderung, einen polnischen Shop aufzubauen. Die passende Sprach-Contribution steht im Zeichensatz für Mitteleuropa, ISO-8859-2 zur Verfügung, und ich codiere sie schon vor der Inbetriebnahme um.

Für die Datenübernahme bekomme ich eine Exceltabelle, die ich mit OpenOffice öffne und als ASCII-Datei gleich in UTF-8 abspeichere.

Zahlungsbedingungen und ähnliche Texte

Ein permanentes Ärgernis ist die Bearbeitung der Zahlungsbedingungen und ähnlicher Texte. Deshalb würde ich gern einen kleinen Texteditor für diese Zwecke zur Verfügung stellen. Prinzipiell soll das so funktionieren wie z.B. dieser Blog.

In einer eigenen Infobox sollen alle vorhandenen (und veröffentlichten) Texte gelistet werden. Erfasst und bearbeitet werden die Text im Admin mit dem neuen Programm admin/text.php, dessen Rohgerüst ich als Kopie aus admin/orders_status.php übernehme.

Zur Aufnahme eines neuen Programms sind folgende Schritte notwenig:

• Erstellen des Programms als admin/text.php
• Übersetzung(en) erstellen als admin/includes/languages/SPRACHE/text.php
• Eintrag in admin/includes/filenames.php
• Menü in admin/includes/boxes/localization.php
• Die Übersetzung für den Menüeintrag in admin/languages/SPRACHE.php
• Erstellen der neuen Tabelle sx_text in der Datenbank
• Eintrag in admin/includes/database_tables.php

Jetzt gehts los. Die Tabelle sieht so aus:

CREATE TABLE sx_text (
  text_id smallint,
  language_id smallint,
  text_sort smallint,
  text_title char(35),
  text_content text,
  primary key (text_id, language_id)
)

Der Text bekommt also eine laufende Nummer verknüpft mit der Sprache zur eindeutigen Zuordnung, eine Sortierfolge und einen Titel für den Link der zugehörigen Infobox.

Im Shop gibt es nun noch eine neue Infobox, die als Linktext den Titel des Texts verwendet, der Link verweist auf eine neue Routine, die Inhalt des jeweiligen Texts anzeigt. Die Mehrsprachigkeit ist nach dem typischen Schema in osCommerce gewährleistet, d.h. gemäß der Variable $languages_id wird der Text in der passenden Sprache angezeigt.

Außerdem ist es sinnvoll, einige Zeilen in admin/language.php zu ergänzen. Damit werden neue Texte pro Sprache in der Datenbank angelegt, wenn eine neue Sprache angelegt wird.

Als Rich Text Editor (rtf editor) habe ich tinyMCE gewählt. Der Editor ist klein, schnell und kann alles, was ich brauche.

xt:Commerce vs osCommerce

Das Shopsystem xt:Commerce ist ein Abkömmling oder Branch von osCommerce. Zwar widerspricht das System meiner Philosophie eines möglichst schlanken Systems, dafür sind einige nette Gimmicks enthalten, die sich meine Kunden wünschen.

Erste Erfahrungen zeigen, daß der Umstieg (für den Programmierer) nicht ganz einfach ist, und mit einiger Wahrscheinlichkeit für keinen Beteiligten allzu großen Vorteile bringt.

Das beginnt mit der in xt integrierten Template-Engine, die Applikation und Layout (oder Design) voneinander trennen soll. Das ist mit einigem Aufwand verbunden, aber nicht vollständig gelungen.

Weiteres in Kürze.

Pseudo-Shops in osCommerce

Ein Kunde wünscht verschiedene Bereiche für die unterschiedlichen Warengruppen seines Shops. Eine funktionale Änderung ist nicht erwünscht, die Warengruppen sollen nur optisch abgesetzt und die Kategorien sollen dadurch übersichtlicher werden. Als mögliche Lösung bietet sich an, die erste Kategorie-Ebene für diesen Zweck zu verwenden.

Prinzipiell gibt es dazu einige Contributions, z. B.:

http://www.oscommerce.com/community/contributions,1730
oder
http://www.oscommerce.com/community/contributions,2802

Wer sich schlau machen möchte, kann nach Multi-Shop, Multi-Store und Great Categories Ausschau halten. Unter diesen Suchbegriffen sollte sowohl im Forum als auch in den Contributions etwas zu finden sein.

Die Contributions sind mir nicht ganz geheuer, unter anderem deshalb, weil sie scheinbar seit länger Zeit nicht mehr bearbeitet wurden. Daher versuche ich eine eigene Lösung. Eine erste Suche über die Sourcen nach dem Begriff “categories_name” ergibt, daß die SQL-Abfragen dazu nur an wenigen Stellen vorkommen.

includes/boxes/categories.php
includes/application_top.php
includes/functions/general.php
index.php

Das sollte zu schaffen sein, zumal index.php ohnehin noch zur Überarbeitung ansteht.

Nach längerer Sucherei ist das Problem mit sehr geringen Eingriffen zu lösen. Zuerst gibt es wieder einen Parameter in der Konfiguration, SNX_OPTION_PSEUDO_SHOPS kann die Werte ‘True’ oder ‘False’ annehmen.

Dann füge ich in includes/header.php eine zusätzliche Tabelle ein. Hier soll die erste Kategorieebene in Form von Karteireitern dargestellt werden. In includes/boxes/categories.php blende ich nun erste Kategorieebene aus, indem ich die Ausgabe der entsprechenden Zeilen unterdrücke.

Auf der Administrationsebene ändert sich nichts, da die Kategorien lediglich optisch anders angeordnet sind.

So ist mit einem Bruchteil des Codes der oben angeführten Contributions die Anforderung umgesetzt.

Infoboxen ein- und ausschalten

Der osCommerce-Shop hat ein 3-spaltiges Layout. Die beiden äußeren Spalten sind von Infoboxen bevölkert.

• Kategorien
• Hersteller
• Neue Produkte
• Schnellsuche
• Informationen
• Warenkorb
• Bestellübersicht
• Herstellerinfo
• Benachrichtigungen
• Weiterempfehlungen
• Angebote
• Bewertungen
• Sprachen
• Währungen

Nicht alle diese Boxen sind gleichzeitig sichtbar. Das ist abhängig vom aktiven Programm, oder davon, ob der Kunde angemeldet ist oder nicht. Einige davon halte ich für überflüssig, andere werde ich noch einfügen. Deshalb möchte ich diese Boxen vom Backend aus ein- bzw. ausschalten können. Eigentlich nicht besonders schwierig, ich habe eine neue Gruppe zur Konfiguration hinzugefügt und für jede der Boxen (ausgenommen die Kategorien) einen Schalter eingefügt.