Free Stuff » xt:Commerce » tabellenfreie Templates
Die Shopsoftware XT-Commerce verwendet ein Templatesystem, dass traditionell aus Tabellen besteht. Die Software ist ansonsten, im Hinblick auf die Komplexität und die Tatsache, dass sie auch kostenfrei ist, gut zu gebrauchen. Daher liegt es nahe, dem Tabellenproblem zu Leibe zu rücken.
An dieser Stelle möchte ich gleich einmal die ungefähre Bearbeitungszeit vorwegnehmen, um XT-Nutzern hier die Entscheidung für oder wider ein eigens geschriebenes Template zu erleichtern. Bei guten x/html /css /(php Grundlagen) - Kenntnissen muss man mit ca. 100 Arbeitsstunden rechnen. Der Aufwand ist deswegen so groß, weil sich das Template in eine Vielzahl von html und php Dateien gliedert. Zudem kommen zahlreiche Modifikationen am Quelltext des Shops selbst hinzu, da viele Funktionen html-Code mit ausgeben. Ich werde später im Einzelnen darauf eingehen.
Wer bereits jetzt sein Vorhaben aufgegeben hat, kann sich alternativ auch ein fertiges tabellenfreies Template bei uns kaufen.zum Shop.
Die Dateien:
Ich werde zunächst alle Dateien auflisten, in denen Veränderungen vorgenommen werden müssen/sollten:
Systemdateien:
für Modifikationen der Javascriptfunktionen:
Templatedateien:
Es sind demnach ca. 100 Dateien, die bearbeitet werden müssen. Die Bearbeitung der Images und Buttons ist natürlich nicht zwingend erforderlich, sofern man kein eigenes Design entwerfen möchte.
Die Durchführung:
Es gibt verschiedene Möglichkeiten, die Tabellen systematisch aus dem Quelltext zu entfernen. Ich werde hier nur auf eine eingehen, die “Kahlschlagmethode”. Man entfernt einfach sämtliche vorhandenen Stylesheets und beginnt ganz von vorn mit der Positionierung. Diese Methode hat den Vorteil, dass man mit einem vorbereinigten Rohling die Arbeit mit den Stylesheets beginnen kann. Da die meisten Stylesheets ohnehin nur Farb -und Schriftformatierungen beinhalten, ist es nicht sonderlich problematisch, alle Styles zu entfernen. Lediglich die, zur Formatierung der Javascriptfunktionen nötigen Styles sollte man übrig lassen. Dies sind:
Diese stehen ziemlich am Ende der Datei.
Die index.html ist die zentrale Datei, welche sämtliche Boxen sowie den Content beinhaltet. Mit der Umgestaltung dieser Datei sollte also begonnen werden. An den Klassen lässt sich leicht die Funktion der einzelnen Tabellen ablesen. So enthält die class=”navRight” alle Smartyvariablen, die im Template den rechten Navigationsbereich mit den entsprechenden Boxen beinhaltet. Es bietet sich hier also an, die Tabellen gegen ein Div-Element zu tauschen, dass zum Beispiel mit der id naviRight oder ähnlich bezeichnet werden kann. Ähnlich verfährt man weiter mit den anderen Bereichen. Diese lassen sich in 5 Hauptbereiche zusammenfassen:
Man kann an dieser Stelle natürlich die index beliebig erweitern, je nachdem, welche Aufteilung man später erziehlen möchte. Ich empfehle für die Box {$box_search} eine Platzierung im Headerbereich. Aber das sollte jeder selbst entscheiden.
Anschließend richtet man die Container entsprechend der neuen Aufteilung aus und überprüft die Stylesheetangaben an den gängigen Browsertypen. Ich setze an dieser Stelle hinreichende Kenntnisse voraus, da der Artikel sonst den Rahmen sprengen würde.
Die nächsten Schritte werde ich nur grob skizzieren. Sie machen den Großteil der Arbeit aus und gleichen sich sehr von den Abreitsabläufen.
Schritt 1: Formatierung der Boxen
Im Template befindet sich der Ordner boxes. Darin befinden sich alle Untertemplates der einzelnen Boxen. Da die Boxen, zumindest auf jeweils einer Seite, identische Ausmaße haben, bieten sich Klassen für die einzelnen Formatierungen an. Die beiden Templatetag-Typen, die einem begegnen sind Textvariablen wie {#heading_example#} und den Inhaltvariablen wie {$BOX_EXAMPLE}. Bei den Variablen, die mit dem Präfix #heading beginnen, bietet sich eine h2 oder h3 Formatierung an. Bei den Inhaltsvariablen sollte man ggf. überprüfen, was ausgegeben wird und dann entscheiden, welche Formatierung die beste ist.
An einem Beispiel der Boxen will ich auf eine kleine Schwierigkeit aufmerksam machen:
Als Beispiel wähle ich die Box “Kategorien” (box_categories.html). Dieses Template ist recht schnell umgeschrieben. Es beinhaltet ja auch nur 2 Variable. Doch eine davon hat es in sich, {$BOX_CONTENT}. Diese Variable wird in der Datei categories.php im Verzeichnis templates/templatename/source/boxes definiert. Und in dieser Datei wird eine weitere Datei angesprochen, welche die eigentliche Kategoriefunktion ist. Diese Datei befindet sich unter: templates/templatename/source/inc und heißt xtc_show_category.inc.php. Das ganze ist also stark verschachtelt. Aber keine Sorge, diese extremen Verschachtelungen sind nicht die Regel.
Ich gehe hier noch kurz auf die Datei xtc_show_category.inc.php ein. Man sollte hier versuchen, eine Liste zu erzeugen, die jeder Kategorie und auch jeder Unterkategorie ein Listenelement zuschreibt, sodass man am Ende eine große Liste mit allen Kategorien erzeugt. Eine verschachtelte Liste mit mehreren ul-Elementen wäre natürlich die sauberste Lösung, jedoch müsste man dann auch die Schleife, in der die Kategorien erzeugt werden komplett neu schreiben. Hier ist jedem selbst überlassen, wie er diese Angelegenheit lößt. Zusammenfassend könnte man also die Variable {$BOX_CONTENT} in eine Liste einschließen und die Kategorien selbst mit Listenelementen ausgeben lassen.
Die einzelnen Box-Untertemplates haben im Regelfall also auch eine php-Datei, die unter Umständen auch html-Quelltext ausgibt. Die Trennung von php- und html-Code ist bei der ganzen Sache auch schon die Hauptschwierigkeit, da, wie im Beispiel der Kategorien gesehen, die “Erzeuger-Dateien” nicht immer gleich zu finden und teilweise stark verschachtelt sind. Für die Boxen bildet die Kategorieausgabe allerdings die einzige Ausnahme, Javascript mal außen vor. Man findet die php-Dateien der Boxen allesamt im Order templates/templatename/source/boxes.
Schritt 2: Formatierung der Module
Nachdem nun die Boxen von allen Tabellen befreit wurden, ist es an der Zeit, sich den Modulen zu widmen. In der Index.html werden alle Module in der Templatevariablen {$main_content} geladen. Die Module befinden sich, wie die Boxen auch, in einem separaten Ordner (module). Die Masse der Module verlangt ein etwas systematisiertes Vorgehen, da man sich sonst doppelte und dreifache Arbeit machen würde. Es ist also zunächst wichtig, Gemeinsamkeiten einzelner Modulelemente herauszuarbeiten. Nehmen wir als Beispiel die Auflistung von Produkten. Es gibt einige Module, die Produkte nach dem gleichen Prinzip auflisten. So zum Beispiel “Neue Artikel” (modul=new_products.html) oder Auflistungen in einer Kategorie (modul=categorie_listing.html). Es ist für die Arbeit mit den Stylesheets, wie auch für die Usability des Shops von Vorteil, wenn solche Darstellungen vereinheitlicht werden. Man muss also nur einmal eine Klasse, sagen wir ProductList{} erstellen und kann diese dann für alle weiteren Produktauflistungen gleichen Typs verwenden. Auch Buttons wie “zurück” und “jetzt kaufen” sollten zu einer Klasse zusammengefasst werden.
Die Formatierung der Module ist mit Abstand die langwierigste und auch nervigste Angelegenheit, da gerade hier viele html Elemente vom XTC-Code selbst generiert werden. Wer nun den Anspruch hat, wirklich jede Tabelle aus dem Code zu entfernen, der muss auch einige Dateien des Quellcodes verändern. (Siehe Liste in Teil1 “Systemdateien”). Ich schlage für die Bearbeitung der einzelnen Module folgende Vorgehensweise vor: Man sollte die Module in logischen Paketen formatieren. Also nicht der Reihe nach, sondern nach Funktionalität gegliedert. Beginnt man zum Beispiel mit der account.html, sollte man anschließend auch die “umliegenden”, also jene Module, die direkt mit der account.html kommunizieren, bearbeiten. So hat man zum Einen eine bessere Übersicht und zudem verliert man bei den verwendeten Klassen nicht den Überblick.
Ich empfehle für eine grobe Einteilung der Module zunächst die Unterscheidung zwischen den offenen Bereichen wie Produktansichten, Kategorien etc und den geschlossenen, sprich accountabhängigen Bereichen wie “Meine Bestellungen”, “Meine Daten” etc. Man sollte hier auch im Design einige Unterschiede machen, um dem User zu visualisieren, in welchem Bereich er sich gerade befindet.
All jenen, die ein tabellenarmes/freies Template zur besseren Suchmaschinenindizierung nutzen wollen, sei gesagt, dass es nicht erforderlich ist, accountabhängige Module zu formatieren, da diese ohnehin über die robots.txt von der Indizierung ausgeschlossen werden. Es würde für diesen Zweck also ausreichen, die Module der offenen Bereiche zu formatieren. Man spart sich damit im Übrigen auch einige Zeit und Mühe. Wer allerdings als Gründen der Barrierefreiheit dieses Vorhaben verfolgt, sollte nach Möglichkeit alle Module umschreiben. Eine Ausnahme bilden hier lediglich die Module für die Print-Ausgaben (z.B.:”print_product_info.html”).
Ich werde hier nicht im Detail auf die einzelnen Module eingehen, da mir für eine solche tiefgehende Doku momentan die Zeit fehlt. Wer Schwierigkeiten hat, in bestimmten Modulen die zugehörigen Quellcode-Dateien zu finden, kann mir aber gern eine Email schreiben.
Grundsätzlich kann man so vorgehen, dass man sich zunächst an die Formatierung des jeweiligen Moduls macht, anschließend das Ergebnis mit einem source-view kontrolliert und sollten dann noch Tabellen sichtbar sein, sucht man die Stelle im Module und sucht in den oben genannten Systemdateien nach dem Ursprung des Codes. Daszu ein Beispiel: - Man bearbeitet die checkout_confirmation.html und stellt fest, dass einige Bereiche immer noch mit Tabellen ausgegeben werden. Verursacher sind in diesem Fall die Variablen {$PRODUCTS_BLOCK} und {$TOTAL_BLOCK} . Ein Blick auf die Liste mit den Systemdateien (Siehe teil1) lässt vermuten, dass jene Variablen in der Datei checkout_confirmation.php generiert werden. Und so ist es auch. In den entsprechenden funktionen müssen anschließend nur noch die Tabellen in adäquate Tags umgeschrieben werden.
Ein Sonderfall: Die Module sofortueberweisung_abort.html und sofortueberweisung_success.html sind nur schwer zu formatieren. Um diese Templates kontrolliert formatieren zu können, müsste man sie sich anzeigen lassen. Dies ist aber nur möglich, wenn man eine Sofortüberweisung ausführt. Sicherlich kann man eine Testüberweisung ausführen und dann die Templates entsprechend umschreiben. Allerdings stellt sich auch hier wieder die Frage nach der Verwendung des Templates. Wenn das Template zur eigenen Nutzung vorgesehen ist, kann man ja selbst abschätzen, ob man diese Zahlungsweise überhaupt anbieten möchte oder nicht.