…Blödsinn ist! Jetzt mal ernsthaft: Gambio, Commerce:SEO, Ecombase-Shop, xtc:Modified. Und mindestens zehn vergessen. Bei den ganzen Forks sollte man langsam echt mal aufpassen, dass man noch genug Messer im Haus hat. Ãœberall schießen die Abgabelungen mit Mini- bzw. Micro-Teams an Programmieren aus dem Boden, einen guten Frontend-Developer hat keiner und man wurschtelt lustig vor sich hin anstatt Kräfte zu bündeln – und nur bei Gambio und Ecombase ist Substanz hinter der ganzen Geschichte zu erkennen.

Ich glaub ja fast, ich mach einfach mal nen svn-tag aus meinem trunk, geb ihm nen lustigen Namen und publiziere meinen eigenen Fork. Dann hätten wir zumindest das Frontend-Problem mal im Griff.

Tendenziell eher weniger. Ich möchte das integrieren, aber das ist irgendwie nur möglich, wenn man sich dabei selbst arm macht. Eine Testumgebung analog zur Paypal Sandbox fällt aus wegen gibt’s nicht. Die Folge ist eine halbseidene Integration, die, wenn sie mal genutzt wird, eigentlich immer Probleme macht. Nur: Debuggen kann man das halt nicht. Keine Ahnung, wie das eBay gemacht hat, aber da gibt’s wohl Kunden erster und zweiter Klasse.

Wobei ich mir eher wie ein Kunde der Holzstuhlklasse vorkomme. Denn wenn man den Merchant Support per E-Mail was fragt muss man sich in Geduld üben. Meine Anfrage ist auf jeden Fall seit drei Tagen offen und es gab noch nicht mal den gefürchteten Autoreply.

So wird das nichts, Moneybookers! Das ist schlicht und ergreifend ein Armutszeugnis. Sowohl technisch als auch was den Support angeht! Dann lieber Sofortüberweisung einbauen. Das funktioniert und die Akzeptanz ist ungefähr fünf mal so hoch wie bei Moneybookers.

[update]: Komisch, dass man immer erst bloggen muss. Moneybookers hat sich aber auf jeden Fall mittlerweile gemeldet und das, was am Telefon noch kategorisch verneint wurde (Testumgebung), gibt es sehr wohl und Moneybookers kann Zugänge auch in Testaccounts umwandeln. Da fragt man sich schon: Warum nicht gleich so und warum nicht schneller?

Zwar gibt es noch keine Lösung für einen solchen Online-Shop, aber für xt:Commerce springt die Görlitzer Firma Kiwi-Vision GbR mit ihrem „Kandy-Modul� für den Open-Source-Shop in die Bresche, das alle gängigen Abhängigkeiten, die in der Mobilfunkbranche existieren, kennt. Man kann das Modul entweder separat erwerben oder den kompletten Shop drumherum gleich mit.
Wie so so viele andere Module auch ist das Kandy-Modul explizit auf xt:Commerce 3.0.4 SP2 ausgelegt – ein Umstand, der sicherlich der schlechten (sprich: nicht vorhandenen) Abwärtskompatibilität von xt:Commerce an und für sich geschuldet ist, aber da sich die Entwicklung der nächsten Version des Shops, welche Versionsnummer auch immer die haben wird, wohl noch über geraume Zeit hinzieht, dürfte das kein allzu großer Fallstrick sein.

Das Modul biete viele interessante Features, die das Administrieren eines Handy-Online-Shops in vielerlei Hinsicht erleichtern:

Verwaltung von Verträgen

Interessant bei einem Handy-Shop ist natürlich primär mal die Verwaltung von Verträgen – kauft ja nicht jeder wie ich ein Handy ohne Vertrag, nur um sich kurze Zeit später wieder ein neues zu kaufen. Verträge lassen sich über den Admin neu anlegen, aktivieren und deaktivieren sowie natürlich löschen und bearbeiten. Dabei kann der Shopbetreiber entscheiden, ob der Vertrag in einer Kurzliste angezeigt wird oder nicht und kann darüber hinaus Aliasnamen vergeben, die sich intern und öffentlich unterscheiden dürfen. Als Komfortmerkmale für den Kunden steht durch das Modul der Download einer Informationsdatei zum Vertrag sowie der Vertrag selbst als Dateidownload zur Verfügung. Beschreibungen und Tarifkonditionen können darüber hinaus mit angegeben werden, um den Kunden mit noch mehr Informationen zum Vertrag zu versorgen.
Verträge können einzelnen Providern, Netzen, WKZ- und Tarifklassen zugewiesen werden, die Angabe von Vertragsprovision, Grundgebühr und der Mindestumsatz versteht sich von selbst. Auch eine termingesteuerte Vertragsprovision ist möglich. Diese Einstellungen sowie die Angabe von Startguthaben, Paketpreis und Anschlusspreis können über die Vertragsverwaltung vorgenommen werden, hier kann auch eine Tarifeignung eingestellt werden.

Provider, Tarifklassen, WKZ-Klassen und Netze

Selbstverständlich können auch Tarifklassenwerte festgelegt werden und Provider, WKZ-Klassen, Netze und Tarifklassen bearbeitet, angelegt oder gelöscht werden. Hier wird auch ein Antragsformular auf Providerebene als Downloaddatei zur Verfügung gestellt sowie Logos für Netze und Provider.

Geräte und Verbindungen

Mit dem „Kandy-Modul“ können anschließend schnell und einfach Produkte aus dem Shop als Vertragsgeräte definiert und an die vorher angelegten Verträge gebunden werden. Außerdem lassen sich dann die Gerätepreise bei Vertragsbindungen festgelegen. Zusätzlich kann der Shop-Betreiber WKZ-Klassen vorgeben und Gerätedaten zuweisen.

Shopbereich

Im Shop selbst wird dem Kunden das Handy, welches er ausgewählt hat, mit dem Preis ohne Vertrag angezeigt. Zusätzlich wird der „ab“-Preis, für den das Handy mit dem günstigsten Vertrag erworben werden kann, angezeigt.

Produktdetails

Der Kunde kann beim Produkt den Tarif im Bereich Gerätedetails auswählen. Der Gerät kann aber genauso über das Handynetz, mit Hilfe einer Suchmaske (Tariffinder) oder ohne Tarif ausgewählt werden. Zudem können die Tarife in der Netzauswahl-Ansicht gruppiert werden.

Tarifwähler

Im Tarifwähler wählt der Kunde einfach den gewünschten Vertrag aus und bekommt dabei alle passenden Geräte und Tarifinformationen angezeigt.

Vertragsverlängerung

In diesem Bereich steht dem Kunden ein Formular zur Verfügung, in welches er seine Kundendaten und das gewünschte Handy eintragen kann. Dieses Formular wird dann an eine E-Mail-Adresse gesendet, die über das Kandy-Modul definierbar ist.

Was ist daran so schwer zu verstehen? Tabellenfrei heißt nicht zwangsläufig, dass man die überall rausmachen muss, sondern nur da, wo sie rein layouttechnischen Charakter haben. Typisches Beispiel für eine Tabelle: Der Warenkorb.
commerce:SEO, dass damit wirbt, ein tabellenfreier, SEO-optimierter Shop zu sein, hat natürlich auch dort die Tabellen eliminiert. Und ein Blick in den Quelltext der Startseite zeigt auch schreckliches:

<div align="center">
  <div id="page_container">
    <div id="page_inner_container">
      <div id="innerBox">
        <div id="outerContainer">
          <div id="innerContainer">
            <div id="wrap">
              <div id="middle">
                <!-- Hauptteil -->
                  <div class="mainbody">
                    [...]
                  </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Will man nicht haben. Wirklich nicht. Für die Seite, die den Shop bewirbt, ein tabellenbasiertes Joomla-Template zu nutzen, zeugt auch von Weitblick.

Aber das soll hier gar nicht Thema sein. Heute geht es um die Frachtdienstleistung mit Fokus auf den internationalen Versand. Das Geschäft über das Internet boomt. Das führt zwangsläufig dazu, dass mehr Pakete verschickt werden. Man kann das ganze kreativ angehen und wie DHL beispielsweise dieses Jahr auch Sonntags ausliefern – oder pragmatisch wie DPD und GLS, die nicht mehr in der Lage sind, irgendwas bis Weihnachten auszuliefern, das nicht gestern bei ihnen war. So innovativ die Post respektive DHL im Inland ist, so unglaublich dilettantisch wird sie, wenn es um den internationalen Versand geht.

Unsere Erzgebirge-Produkte versenden wir ja auch international. Das Paket bekommt bei uns einen schicken internationalen Paketaufkleber, auf dem auch bereits die Sendungsnummer steht, mit der dieses auf die Reise gehen wird. Nur hat der Empfänger nichts davon. Geht die Sendung beispielsweise in die USA, dann kennt das Tracking von DHL USA die Sendung schlicht und ergreifend nicht. Das hat einen einfachen Grund: Das Paket wird auf US-Boden nicht mehr von DHL, sondern vom US Postal Service weiter befördert. Ob DHL Deutschland der eigene US-Ableger einfach nur zu teuer ist oder das ganze aufgrund alter Verträge, als das alles noch verstaatlicht war, geschieht, entzieht sich dabei meiner Kenntnis. Apropos kennen: USPS kennt die Nummer natürlich nicht, denn die würfeln sich eine neue. Die bekommt man dann von DHL Deutschland auf telefonische Nachfrage – ein vom Workflow her eher unpraktikables Vorgehen, wenn man mehr als ein Paket pro Monat international verschickt. In Zeiten globaler Vernetzung ist es mir aber ein Rätsel, warum man nicht Trackingnummern entwickeln kann, die Carrier-übergreifend vom Absender bis zum Empfänger gleich bleiben. Oder zumindest unterhalb der Carrier Schnittstellen zu implementieren, um dem Kunden das Tracking mit der ihm bekannten Nummer durchgängig zu ermöglichen. Denn DHL Deutschland gibt für die ursprüngliche Trackingnummer nur ‘Sendung ist in Transport ins Zielland aufgenommen’ aus und zwar bis sie beim Empfänger vor der Tür steht. Das bekommen sie dann aber wieder mit, dazwischen ist ein schwarzes Loch.
DHL hat oder will keine Ahnung haben, was mit dem Paket ist, sobald es deutschen Boden verlässt. So bekommt man auf Nachfrage schonmal eine irische Trackingnummer und einen Carrier genannt, der aber im Internet quasi unauffindbar ist und der nach eigener Aussage schon seit Jahren keine Pakete für DHL mehr transportiert. Das über Umwege bei DHL UK aufgetane Tracking ist denn auch nur Augenwischerei – meint zumindest DHL Deutschland. Warum das Paket aber im Paketzentrum vor sich hingammelt wissen sie auch nicht. Und auch nicht, warum es nicht zurückgeschickt wird. Aber da, wo das Tracking behauptet, dass es sei, wäre es angeblich nicht. Woher sie das wissen wissen sie aber nicht.

Alles in allem also alles sehr unbefriedigend. Was uns zur Ausgangsfrage, einem Werbespruch von UPS, den sie in Deutschland aus naheliegenden Gründen nicht benutzen, zurückbringt. Eine Menge könnten sie tun, wenn sie nur nicht so schrecklich ehrgeizig wären. Zunächst mal ist deren Preisstaffel eher undurchsichtig, das Schicksal teilen sie aber mit den anderen Paketdienstleistern. Aber man kann ja den Preis direkt im Internet erfragen. Für ein Paket mit einem Gewicht von 3kg in die USA sind aber 115 Euro alles andere als ein guter Preis – egal, ob wir einen Nußknacker für 160 Euro oder ein Räuchermännchen für 65. Und das ist schon der billigste Tarif. Wobei, nicht wirklich. Es ist ‘Expedited Shipping’ und innerhalb einer Woche in den USA. Die Tariftabelle kennt aber durchaus günstigere Tarife im Bereich ‘Standard Shipping’. Die gibt es dann dummerweise aber nicht für die USA. Wobei man sich die Information aus einer anderen Tabelle raussuchen muss. Und da fragt man sich schon, warum das so ist. Ich könnte durchaus damit leben, wenn das Paket zwei Wochen Laufzeit hat – schneller ist DHL auch nicht und das Thema mit den Trackingnummern wäre vom Tisch, denn UPS schmeißt das dann auch in USA wieder auf einen UPS-Laster.

Von der Ankündigung ist nichts weiter geblieben als ein paar Demo-Shops, die aktuell offline sind und eine Ankündigung, die auch irgendwelche Lizenzänderungen ankündigt, im Support-Bereich (hier im Wortlaut). Und wenn man so manchen Support-Kommentar glauben darf, dann sind die Demos noch nicht mal final. Es darf also weiter gespannt auf 3.04 SP2.23.1 gewartet werden.

Vielsagend in dem Zusammenhang auch die Beiträge [1], [2] von Leuten, die im Mutterschiff als Supportler auftreten, um sich dann aus der Diskussion bei ecombase wieder auszuklinken, ohne die angeblichen Fehler richtig zu stellen. Woran das mit der Fehlinformation wohl liegen mag? Sicherlich nicht an der guten, offenen Kommunikationspolitik von xt:Commerce.

Mal schnell eine Ankündigung rauszuhauen, die dann kommentarlos wieder gelöscht und vor allem auch nicht eingehalten wird legt den Verdacht nahe, dass bei xt:Commerce eine gewisse Panik ob der sich abzeichnenden starken Konkurrenz ausbricht, anders kann ich mir nicht erklären, wieso man mit derart blindem Aktionismus sehenden Auges ungebremst gegen die Wand laufen wollte. Mal sehen, wie das weitergeht. Aber eigentlich kann es mir auch egal sein. Die 3.04 SP2.1 läuft ja.

[tags]xt:commerce, xt:c, 3.1, 3.04 SP 2.2, release[/tags]

Derweil ist 3.04 SP2.2 noch nicht dem Betastadium entwachsen, aber es ist mal anzunehmen, dass 3.1 einfach eine umgelabelte 3.04 SP2.2 sein wird. Damit steht zu befürchten, dass sich Template-technisch nicht wirklich etwas verbessert, denn das mit der ersten SP2.2-Beta gelieferte tabellenlose Template ist eher ein schlechter Witz in Bezug auf Semantik gewesen, ähnlich denen, die man vor einem Jahr im Shop verkauft hat.

Es gibt einige sinnvolle Features in 3.04 SP2.23.1, darunter ein Plugin-Manager und die Möglichkeit, Multistores anzulegen. Schaut man sich die Screenshots im Beta-Forum an, dann wohl darüber hinaus noch jede Menge Eye-Candy im Admin-Bereich. Gerade aber mit Multistore und Plugin-Manager dürfte eines klar sein: Ein Update von 3.04 SP2.1 auf 3.04 SP2.23.1 ist selbst bei einem nur minimal modifizierten Shop eher unmöglich. Selbst wenn man alle Änderungen gut dokumentiert hat dürften die Code-Änderungen so weitreichend sein, dass das keinen Spaß machen wird.

Bleibt zu hoffen, dass man Altlasten beseitigt hat, Markup im php-Code beispielsweise, was das entfernen von Layouttabellen zur wahren Herausforderung gemacht hat, oder die inkonsequente Implementierung der Sprachen Рneben den im Beitrag angesprochenen Punkten sind in 3.04 SP2.1 unter anderem die Betreffzeilen der E-Mails, welche der Shop verschickt, nur in einer Sprache m̦glich.

[tags]xt:c, xt:commerce, xtcommerce, beta, 3.04 SP2.2, 3.1, multishop, bugs[/tags]

Das Template selbst kommt im schlichten Grau. Auch wenn Björn dieses nur als Grundlage für die eigene Arbeit ansieht, ein Antialias hätte dem Schriftzug ‘Your Logo here’ trotzdem gut zu Gesicht gestanden. Die Buttons kommen im Web 2.0-Look, ein Photoshop-Vorlage wäre aber zum schnellen Ändern von Buttontexten hilfreich. Es gibt aber zwei verschiedene Arten Buttons, nämlich gelbe und schwarze. Zusammen mit den diversen nicht veränderten Originaldateien, wie etwa den hässlichen Kundengruppe-Icons oder den Bewertungssternen, trägt das nicht unbedingt zur Ãœbersichtlichkeit bei.

Ãœbersichtlich gestaltet sich hingegen der Quelltext. Leider gilt aber für die Boxüberschriften das bereits zum RedRiver-Template gesagte: Die Wahrscheinlichkeit, dass es sich dabei um die wichtigsten Ãœberschriften auf der Seite handelt und daher der Einsatz von h1 gerechtfertigt ist, dürfte gegen null gehen. Diese wäre für den eigentlichen Header, der das oben angesprochene Bild enthält, wesentlich besser geeignet und man hätte sich einen div-Container gespart. Außerdem ist es unter SEO-Gesichtspunkten sicherlich sinnvoller, dass Bild als Hintergrundbild einzubinden und den Text beispielsweise mit der Phark-Methode ‘verschwinden’ zu lassen – wenn es denn überhaupt unbedingt ein Bild im Header sein muss. Auch sollte der anklickbar sein. Meine Hand neigt stark dazu, den Schriftzug zu klicken, um zurück auf die Startseite zu kommen, was derzeit nicht von Erfolg gekrönt ist.

An den Header schließt sich die als Liste realisierte Navigation an. Allerdings ist nicht schlüssig, warum die Liste selbst noch einmal in einen div-Container verpackt und für was das leere <a id="navigation" name="navigation"></a>-Element. Wenn es da nur darum geht eine Sprungmarke zu setzen, das lässt sich auch nur mit einer ID erreichen, was alle modernen Browser mittlerweile als Anker nutzen können. Auch sonst finden sich innerhalb der Anchor-Tags noch einmal span-Elemente, die nicht nur auf den ersten Blick überflüssig erscheinen.

Im Hauptbereich ist die Breacrumb-Navigation keine Liste, ein Umstand, der sicherlich der Tatsache, dass sich das Markup hierfür in den php-Dateien findet, geschuldet ist. Die Kategorien werden als korrekt verschachtelte Liste ausgegeben, der dafür erforderliche php-Code ist noch um ein gutes Stück kompakter und aufgeräumter als meine Adaption von gunnART’s Anpassungen. Das CSS hingegen kaskadiert nicht, wodurch Einrückungen und auch hover-Effekte nur bis zur vierten Ebene vorhanden sind, was sich bei den Einrückungen in Hinblick auf die Ãœbersichtlichkeit durchaus argumentieren lässt, beim Ãœberfahren mit der Maus oder beim Auswählen einer Kategorie ab der fünften Ebene sollte dieser Zustand aber ersichtlich werden. Allerdings muss man vielleicht auch noch mal ans Reißbrett und die Shopstruktur überdenken, benötigt man tatsächlich derart tief verschachtelte Kategorien.

Zu den Boxen selbst habe ich ja schon angemerkt, dass die Überschrift erster Ordnung eher fehl am Platz ist. Auffällig ist auch, dass bei allen Boxen die Überschrift außerhalb eines div-Containers steht, während dieser selbst mitunter nur ein weiteres Blocklevel-Element, etwa eine unsortierte Liste, enthält. Da es kein Element gibt, mit dem sich die gesamte Box ansprechen lässt und die Einzelelemente auch nicht durch ID referenzierbar sind ist ein einfaches Ausblenden oder Umgruppieren nur über das Markup, nicht jedoch über CSS möglich. Als Beispiels mag hier der Erzgebirge-Palast dienen:

<div class="box" id="boxContent">
	<h4>Mehr &uuml;ber...</h4>
	<ul>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/3/content/AGB" class="normal">AGB</a></li>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/1/content/Versandinformationen" class="normal">Versandinformationen</a></li>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/10/content/Zahlungsmoeglichkeiten" class="normal">Zahlungsmöglichkeiten</a></li>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/11/content/Widerrufsrecht" class="normal">Widerrufsrecht</a></li>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/7/content/Kontakt" class="normal">Kontakt</a></li>
		<li><a href="http://www.erzgebirge-palace.com/shop_content.php/coID/70/content/Newsletter-RSS-Feeds" class="normal">Newsletter/RSS-Feeds</a></li>
	</ul>
</div>

Etwas mehr Aufmerksamkeit verdient die Besteller-Box. Wenn das keine sortierte Liste ist, was dann? Ich tendiere hier zu einer ol-dl-Kombi (leider scheint Björn Seibert den experimentellen Bereich eingestellt zu haben, deshalb hier auch kein Link, da mittlerweile auch der Google-Cache die Seite nicht mehr enthält), was dann in etwa so aussehen könnte:

<div class="box" id="boxBestseller">
	<h4>Unsere Bestseller</h4>
	<ol>
		<li>
			<dl>
				<dt>Testprodukt 1</dt>
				<dd>83,00 EUR</dd>
				<dd>zzgl. Versandkosten</dd>
			</dl>
		</li>
		<li>
			<dl>
				<dt>Testprodukt 2</dt>
				<dd>55,00 EUR</dd>
				<dd>zzgl. Versandkosten</dd>
			</dl>
		</li>
	</ol>
</div>

Und bei einem div, der den Klassennamen hrDiv hat und eine horizontale Linie erzeugt, fragt man sich durchaus, warum man nicht einfach das dafür gedachte hr-Element benutzt, bei dem ich sowieso der Meinung bin, dass es zu Unrecht ein Schattendasein führt, da wohl noch immer viele damit die aus den Anfangszeiten des Webs bekannten Trennlinien assoziieren, ohne sich der Gestaltungsmöglichkeiten mittels CSS auch für dieses Element bewusst zu sein.
Das gilt im übrigen auch für die Definitionsliste, die sich für weit mehr sinnvoll einsetzten lässt, als ihr Name vermuten lässt. Entsprechende Ideen mag das obige Beispiel vermitteln, dass sich auch problemlos etwa auf die Rezensionsseite übertragen lässt.

An der ein oder anderen Stelle laufen einem br-Elemente über den Weg, deren einzige Aufgabe offensichtlich darin besteht, einen float zu clearen, was sich eigentlich auch an ein sowieso notwendiges Element binden lassen sollte.

Björn setzt für das Template auf den Transitional-Doctype von XHTML 1.0. Wer das ganze gegen die Strict-Variante validieren will muss neben den hier gegebenen Tipps zur Validitätsverbesserung unter anderem auch noch ein font-Tag im Checkout eliminieren. Das steckt nämlich in den Sprachdateien beim ‘Bearbeiten’-Link.

Alle Formularelemente haben derzeit keine ID, wobei hier als pirmärer schuldiger aber der Shop selbst anzusehen ist. Mit etwas Aufwand an den PHP-Dateien lässt sich aber auch das realisieren, evtl. geht es sogar mit Smarty-Funktionen, ohne die Sourcefiles ändern zu müssen. Nach Auskunft von Björn ist da wohl auch was in Arbeit. Damit würden sich dann auch Formulare besser und zugänglicher gestalten lassen.

Ab und zu laufen einem dann doch noch Tabellen über den Weg. Die dürften aber, wie etwa die Auflistung der Seiten beim Produktlisting oder auch im Checkout-Prozess größtenteils im Source befinden und von daher mit einem Template nicht eliminierbar sein. Apropos Checkout-Prozess: Habe ich eigentlich schon erwähnt, dass ich so langsam aber sicher die Silk-Icons von famfamfam.com nicht mehr sehen kann?

Die einzige berechtigte Tabelle, nämlich der Warenkorb, ließe sich von der Zugänglichkeit her noch verbessern, Anregungen dazu mag das Beispiel auf macx.de liefern.

Alles in allem bietet das YAML-Template eine solide Grundlage für die eigene Entwicklung eines CSS-basierten und weitestgehend layouttabellenfreien Templates, das nicht nach ‘Stange’ aussieht. Bei der Gestaltung des ganzen helfen, nachdem eine Buttonvorlage ja fehlt, möglicherweise die von Deziner Folio zur Verfügung gestellten Ebenenstil- und Verlaufsvorlagen für Photoshop.

Why are you working in the Web business if you’re not interested in it? Go flip burgers instead.
Roger Johansson

[tags]signatur, burger[/tags]

So richtig zu spüren bekommt man das aber eigentlich erst, seit der Internet Explorer 7 draußen ist. Denn der hat einige Bugs nicht mehr, die seine Vergängerversionen noch hatten und die teilweise weidlich ausgenutzt wurden. So etwa, dass alle Varianten des Internet Explorer bis Version 6 einen Underscore vor einer Eigenschaft ignoriert haben. Man konnte also mit

	body {
		background: #F00;
		_background: #FF0;
	}

eine rote Hintergrundfarbe für den body definieren, für den IE hingegen eine gelbe, da der nachfolgende _background aufgrund der Eigenschaften von CSS den vorhergenden background überschreibt. Natürlich nur beim Internet Explorer bis Version 6, denn der betrachtet _background und background als identisch. Alle anderen Browser nicht. Und deshalb funktionierte das. Bislang. Der IE 7 macht es nämlich jetzt auch richtig.
Und genau aus dem Grund sollte man auf die Empfehlung aus Redmond zur Abwechslung mal hören, die da lautet, für IE-spezifische notwendige Anpassungen doch bitte die Conditional Comments zu nutzen, die der Internet Explorer seit Version 5 unterstützt. Dann spart man sich auch derart nachgereichte Bastellösungen. Ich würde im übrigen Abstand davon nehmen, die Conditional Comments direkt in die CSS-Datei zu schreiben. Zum einen werden die dann auch wieder von allen Browsern geladen, die das gar nicht nötig haben und zum anderen sollte man HTML-Kommentare in CSS-Dateien nur dann einsetzen, wenn man scharf drauf ist, vom Validator ein paar Fehlermeldungen um die Ohren geknallt zu bekommen. Aber jetzt verstehe ich wenigstens, was der Autor des Green Velvet Templates damit gemeint hat, dass Conditional Comments mehr Quelltext in der CSS-Datei erzeugen. Und wenn er sich wirklich damit auskennen würde, dann wüsste er, dass Conditional Comments eben kein Hack sind.

[tags]xtc, xt:commerce, hacks, css, underscore hack, conditional comments[/tags]

Nach ziemlich genau fünf Monaten Entwicklungszeit ist es soweit: Der Erzgebirge-Palast erblickt das Licht der Welt. Schwibbögen, Pyramiden, Nußknacker, Räuchermännchen und vieles mehr gibt es ab sofort unter www.erzgebirge-palace.com. Und natürlich auch Artikel zum bevorstehenden Osterfest.

Soviel zur Werbung. Neben allen hier veröffentlichten Änderungen sind noch viele weitere Anpassungen in die xt:Commece-Software geflossen, über den Daumen gepeilt wurde an ca. 300 Stellen Hand angelegt.

Viel Zeit ist dabei in die Anpassung des Templates investiert worden. Das Ergebnis ist ein komplett tabellenloses Layout, auch an Stellen, die durch eine mangelhafte Implementierung der Template-Engine nur durch Änderungen an den php-Dateien in den Griff zu bekommen sind. Das Markup nimmt natürlich auch auf semantische Gesichtspunkte Rücksicht und Tabellen sind an den Stellen, an denen tabellarischer Inhalt dargestellt wird, natürlich noch vorhanden, aber deutlich aufgebohrt worden.

Alles ist noch nicht Gold, was glänzt, so ist das Stylesheet derzeit noch sehr chaotisch und es dürften sich einige Selektoren finden, die im Hinblick auf ihre Semantik auf jeden Fall noch überarbeitungswürdig sind. Aber jetzt ist erstmal durchschnaufen angesagt und der Feinschliff wird dann in den nächsten Tagen und Wochen angegangen.

Die ein oder andere Anpassung werde ich dann auch hier veröffentlichen, etwa die modifizierte Blätterfunktion oder die Integration von Google Maps über den Content Manager, wie etwa auf der englischen About the Erzgebirge-Palace-Seite zu sehen. Besonders ans Herz gelegt sei euch darüber hinaus der Feature-Artikel über die weltberühmten Steinbach-Nußknacker, ein Service, den wir bei entsprechender Ressonanz auszubauen gedenken. Derweil kann man sich in unserem aStore rund um’s Erzgebirge mit Informationen eindecken.

Für das Interview bei lopsta.com habe ich noch ein paar weiterführende Informationen zusammengeschrieben, sobald es veröffentlich ist werde ich natürlich den Link dorthin auch hier kundtun, hier der Link zum Interview:
Interview Erzgebirge-Palast bei lopsta.com.

[tags]xtc, xt:commerce, erzgebirge, erzgebirge-palast, steinbach, nußknacker, räuchermännchen, schwibbögen[/tags]

Das ganze gibt es hier:
template-switcher.txt

Vielleicht kann es ja jemand brauchen.

[tags]xtc, xt:commerce, template, switch, switcher[/tags]

Sicherlich kann man xt:Commerce mit seinem hoffnungslos veralteten Tabellengeschachtel nicht dazu hernehmen, um allgemeine Aussagen über den Zustand des Webs zu machen.

Was vielleicht nicht so klar geworden ist: Der Code im gestrigen Posting ist nicht der original xt:Commerce-Code! Der sieht vielmehr so aus:
Originalcode checkout_shipping_block.html

Dass das nicht so prickelnd ist haben mittlerweile nicht nur die Macher von xt:Commerce erkannt, für die Version 4 (und nach neuesten Informationen schon für Servicepack 2.2 der Version 3.04) wird es neben dem standardmäßigen Tabellenlayout auch ein CSS-Template geben.

Man kann nur hoffen (es wird nicht geschehen, aber die Hoffnung stirbt bekanntermaßen zuletzt), dass sie jemanden fragen, der sich mit so etwas auskennt. Denn das, was diverse Dienstleister, die sich schnell einen „Made for Web 2.0�-Button gemacht haben, da als modernes Webdesign verkaufen, ist größtenteils (die Ausnahmen bestätigen die Regel) nur eines: Schrott in Tüten. Und das ist der eigentliche Kern meiner gestrigen Kritik. Und taugt durchaus, um zu bewerten, wo wir uns (in Deutschland) derzeit befinden, wenn es um Webstandards und semantisch korrektes Markup geht: Weit am Anfang, sehr weit am Anfang. Denn diese CSS-Layouts sollen ja eigentlich eine Alternative zum unübersichtlichen, aufgeblähten und schwer wartbaren Originalcode von xt:Commerce bieten und diesen Anspruch erfüllen die meisten eben gar nicht!

Der Vollständigkeit halber:
Mein Code für checkout_shipping_block.html

Und falls irgendein Suppenkoch noch schicke Buttons für seinen Pfusch braucht, kann er sich hier bedienen:

[tags]webstandards, xtc, xt:commerce, markup, css[/tags]

Neues Jahr, neue Gesetze, neue Vorschriften. Seit Jahresbeginn gelten unter anderem neue Formvorschriften für E-Mails und, mit der Novelle des Telemediengesetzes, kommen gerade auf Shopbetreiber neue Anforderungen in Bezug auf die Datenschutzerklärung zu.

Während sich das Überarbeiten der dreizehn verschiedenen E-Mail-Texte, die sich für alle Sprachen, jeweils in einer reinen Text und einer HTML-Ausprägung sowohl in templates/[template]/mail/ als auch in templates/[template]/admin/mail befinden, allenfalls als Fleißaufgabe erweisen dürfte, da xt:Commerce keine Möglichkeit bietet, an alle E-Mails eine gleichlautende Signatur anzuhängen (aber vielleicht poste ich hier in Kürze mal was entsprechendes), müssen für die Erfordernisse des neuen Telemediengesetzes in Bezug auf Datenschutz stärkere Geschütze aufgefahren werden:

Wörtlich genommen müsste der Nutzer einer gewerblichen Webseite beim ersten Aufruf auf die Datenschutzerklärung hingewiesen werden. Es wird wohl allerdings ausreichend sein, einen entsprechenden aussagekräftigen Link auf die Belehrung in der Fusszeile anzubringen. Spätestens jedoch, wenn ein Bestellvorgang gestartet wird, bei dem der Nutzer seine persönlichen Daten eingibt, muss die Belehrung deutlich eingeblendet werden. Der Vorgang darf erst dann fortgesetzt werden können, wenn der Nutzer die Belehrung akzeptiert hat. Die Zustimmung muss nachprüfbar gespeicht werden.

Nach der Einverständniserklärung muss der Nutzer jederzeit den Inhalt seiner Erklärung abrufen können. Eine per Email versendete Bestellbestätigung sollte neben einem Link auf etwa akzeptierte AGB auch einen Link oder den Volltext der Datenschutzbelehrung enthalten.

Weiterhin ist sicherzustellen, dass der Nutzer des Dienstes die Nutzung jederzeit beenden kann. Wenn etwa ein Benutzer-Account angeboten wird muss dem Nutzer die Möglichkeit geboten werden, diesen zu deaktivieren, die gespeicherten Daten zu löschen bzw. zu sperren.

Tja, ich würde sagen, das sind gleich drei Wünsche auf einmal. Und wer ungern russisches Abmahnroulette spielt und daher nicht darauf warten will, bis die Änderungen in das nach wie vor nicht terminierte SP 2.2 einfließen, findet hier eine Einbauanleitung.

Ein Satz vorab

Wie immer gilt: Alle Änderungen beziehen sich auf xt:Commerce 3.04 SP2.1, der Einbau erfolgt auf eigene Gefahr und nicht nur für diese Anpassungen empfiehlt sich ein Backup, Fragen werden in den Kommentaren beantwortet.

Datenschutzerklärung abnicken

Zunächst mal sollte man wie bei Lübeck online vorgeschlagen und sofern noch nicht vorhanden eine Seite mit der Datenschutzerklärung erstellen und diese in eine der beiden Boxen verlinken.
Als nächsten Schritt gilt es, ähnlich wie bei den AGBs während des Checkout-Prozesses, beim Registrieren eines Accounts oder beim Checkout über den Gastaccount eine Checkbox zu integrieren, mit der der Kunde bestätigt, die Datenschutzrichtlinien akzeptiert zu haben.
Alle Angaben für create_account.php gelten analog auch für create_guest_account.php:
In create_account.php nach

$smarty->assign('INPUT_TEL', xtc_draw_input_fieldNote(array ('name' => 'telephone', 'text' => (xtc_not_null(ENTRY_TELEPHONE_NUMBER_TEXT) ? '<span class="inputRequirement">'.ENTRY_TELEPHONE_NUMBER_TEXT.'</span>' : ''))));

suchen und davor einfügen:

	// BEGIN privacy policy
	$smarty->assign('PRIVACY_LINK', $main->getContentLink(2, ACCEPT_PRIVACY, "class='popup'"));
	$smarty->assign('CHECKBOX_PRIVACY', '<input type="checkbox" value="privacy" name="privacy" id="field_privacy" />');
	// END privacy policy

Dadurch haben wir im Template sowohl einen Link auf die Datenschutzerklärung als auch die Checkbox zur Verfügung. Die 2 in $main->getContentLink steht dabei für die coID (Sprachgruppe) der Datenschutzerklärung, die man im Contentmanager findet oder indem man auf den Link klickt.
Wer nicht die jsPopUp-Klasse von Dirk Ginader nutzt muss natürlich selber wissen, ob und wie er die Erklärung in einem neuen Fenster öffnet.

Damit der Link auch einen sinnvollen Text hat, muss man die Konstante für alle im Einsatz befindlichen Sprachen definieren, beispielsweise in lang/german/german.php:

	define('ACCEPT_PRIVACY', 'Ich akzeptiere Ihre Datenschutzrichtlinien');

Das platziert man dann an geeigneter Stelle im Template, sowohl in templates/[template]/modules/create_account.html als auch in templates/[template]/modules/create_account_guest.html, was bei mir am Ende so aussieht:

	<fieldset>
	        <legend>{#title_privacy#}</legend>
	        <p class="conditions">
	                {$CHECKBOX_PRIVACY}
	                <label for="field_privacy">{$PRIVACY_LINK}</label><span class="inputRequirement">*</span>
	        </p>
	</fieldset>

Jetzt nur noch prüfen, ob die Box auch angehakt war und das ganze zusammen mit allen Informationen in die Datenbank schreiben. Dazu widmen wir uns noch einmal create_account.php:
Nach

$telephone = xtc_db_prepare_input($_POST['telephone']);

fügend wir folgendes ein:

	// BEGIN privacy policy
	$privacy = xtc_db_prepare_input($_POST['privacy']);
	// END privacy policy

Vor

if ($customers_status == 0 || !$customers_status)

fügen wir folgendes ein:

	// BEGIN privacy policy
	if(!isset($privacy) || empty($privacy)) {
            $error = true;
            $messageStack->add('create_account', ENTRY_PRIVACY_POLICY_ERROR);
    }
	// END privacy policy

Hier trennen sich die Wege von create_account.php und create_guest_account.php. In create_account.php ändern wir

$sql_data_array = array ('customers_vat_id' => $vat, 'customers_vat_id_status' => $customers_vat_id_status, 'customers_status' => $customers_status, 'customers_firstname' => $firstname, 'customers_lastname' => $lastname, 'customers_email_address' => $email_address, 'customers_telephone' => $telephone, 'customers_fax' => $fax, 'customers_newsletter' => $newsletter, 'customers_password' => xtc_encrypt_password($password),'customers_date_added' => 'now()','customers_last_modified' => 'now()');

zu

$sql_data_array = array ('customers_vat_id' => $vat, 'customers_vat_id_status' => $customers_vat_id_status, 'customers_status' => $customers_status, 'customers_firstname' => $firstname, 'customers_lastname' => $lastname, 'customers_email_address' => $email_address, 'customers_telephone' => $telephone, 'customers_fax' => $fax, 'customers_newsletter' => $newsletter, 'customers_password' => xtc_encrypt_password($password),'customers_date_added' => 'now()','customers_last_modified' => 'now()', 'privacy' => 'now()');

und in create_guest_account.php ersetzen wir

$sql_data_array = array ('customers_vat_id' => $vat, 'customers_vat_id_status' => $customers_vat_id_status, 'customers_status' => $customers_status, 'customers_firstname' => $firstname, 'customers_lastname' => $lastname, 'customers_email_address' => $email_address, 'customers_telephone' => $telephone, 'customers_fax' => $fax, 'customers_newsletter' => $newsletter, 'account_type' => '1', 'customers_password' => xtc_encrypt_password($password));

mit

$sql_data_array = array ('customers_vat_id' => $vat, 'customers_vat_id_status' => $customers_vat_id_status, 'customers_status' => $customers_status, 'customers_firstname' => $firstname, 'customers_lastname' => $lastname, 'customers_email_address' => $email_address, 'customers_telephone' => $telephone, 'customers_fax' => $fax, 'customers_newsletter' => $newsletter, 'account_type' => '1', 'customers_password' => xtc_encrypt_password($password), 'privacy' => 'now()');

Zwei Sachen sind noch zu erledigen, dann sind wir mit dem ersten Punkt auch schon durch. Die Fehlermeldung ist in allen Sprachdateien zu hinterlegen

define('ENTRY_PRIVACY_POLICY_ERROR', 'Sofern Sie unsere Datenschutzrichtlinien nicht akzeptieren können wir Ihre Bestellung bedauerlicherweise nicht entgegennehmen und auch kein Konto für Sie anlegen!');

und die Tabelle customers ist um das neue Feld privacy zu erweitern:

ALTER TABLE  `customers` ADD  `privacy` DATETIME NOT NULL AFTER  `refferers_id` ;

Da die Codedarstellung in WordPress eher dürftig ist gibt es das ganze in dateiweiser Abfolge auch noch einmal in Textform.

Link in der E-Mail

Man kann den Link zur Datenschutzerklärung natürlich einfach kopieren und in die fraglichen Mailtexte templates/[template]/mail/[language]/order_mail.[txt|html] sowie templates/[template]/mail/[language]/create_account_mail.[txt|html] einfügen. Ein hartkodierter Link ist aber nicht wirklich die Ideallösung und sorgt bei einem eventuellen Domainwechsel für unbändige Freude und in der Form http://www.shop.de/shop_content.php/coID/2/content/Privatsphaere-und-Datenschutz/ sieht das auch nicht wirklich prickelnd aus.

Da hilft ein kurzer Eingriff in create_account.php, dort ersetzen wir

$module_content = array ('MAIL_NAME' => $name, 'MAIL_REPLY_ADDRESS' => EMAIL_SUPPORT_REPLY_ADDRESS, 'MAIL_GENDER' => $gender, 'MAIL_ADDRESS' => $gender =="m" ? EMAIL_ADDRESS_M : EMAIL_ADDRESS_F, 'MAIL_LASTNAME' => $lastname, 'MAIL_FIRSTNAME' => $firstname, 'MAIL_USERNAME' => $email_address, 'MAIL_PASSWORD' => $password);

mit

$module_content = array ('MAIL_NAME' => $name, 'MAIL_REPLY_ADDRESS' => EMAIL_SUPPORT_REPLY_ADDRESS, 'MAIL_GENDER' => $gender, 'MAIL_ADDRESS' => $gender =="m" ? EMAIL_ADDRESS_M : EMAIL_ADDRESS_F, 'MAIL_LASTNAME' => $lastname, 'MAIL_FIRSTNAME' => $firstname, 'MAIL_USERNAME' => $email_address, 'MAIL_PASSWORD' => $password, 'HTTP_SERVER' => HTTP_SERVER);

. In send_order.php fügen wir nach

$smarty->assign('PAYMENT_METHOD', $payment_method);

folgendes ein:

$smarty->assign("HTTP_SERVER", HTTP_SERVER);.
 
In den Bestellmails steht dann {$HTTP_SERVER} als Smarty-Variable zur Verfügung, in <tt>create_account_mail.[txt|html]</tt> ist es {$content.HTTP_SERVER}.
 
Dem eher unschönen Link rücken wir anschließend noch mit mod_rewrite zu Leibe und erstellen uns eine .htaccess-Datei oder ergänzen eine bereits vorhandene:

	### BEGIN privacy policy ###
	RewriteRule ^datenschutz/$ shop_content.php?coID=2&language=de
	RewriteRule ^privacy/$ shop_content.php?coID=2&language=en
	### END privacy policy ###

Konto löschen

Aller guten Dinge sind drei. Fangen wir bei den Sprachdateien an. In lang/[language]/[language].php brauchen wir für die Breadbrumb-Navigation entsprechende Angaben:

	define('NAVBAR_TITLE_1_ACCOUNT_DELETE', 'Ihr Konto');
	define('NAVBAR_TITLE_2_ACCOUNT_DELETE', 'Konto löschen');

Der Rest wird aus lang/[language]/lang_[language].conf beigesteuert. Den Abschnitt [account] ergänzen wir:

text_delete = 'Konto löschen'

Und den Abschnitt fügen wir komplett neu hinzu:

	[account_delete]
	heading_delete_account = 'Konto löschen'
	heading_account_deleted = 'Konto gelöscht'
	delete_account = 'Mit einem Klick auf den Weiter-Button l&ouml;schen Sie Ihr Konto bei uns. Dadurch werden alle mit diesem Konto verkn&uuml;pften personenbezogenen Daten gem&auml;&szlig; den gesetzlichen Vorgaben unwiederbringlich gel&ouml;scht bzw. gesperrt.<p>Bitte beachten Sie, dass sie nach dem L&ouml;schen des Kontos daher auch keinerlei Zugriff mehr auf ihre get&auml;tigten Bestellungen haben!</p><p>Sie k&ouml;nnen nat&uuml;rlich jederzeit wieder ein neues Konto erstellen.'
	account_deleted = 'Ihr Konto wurde erfolgreich gel&ouml;scht.'
</p>

In includes/filenames.php definieren wir noch einen Dateinamen für unsere Datei:

define('FILENAME_ACCOUNT_DELETE', 'account_delete.php');

In account.php bauen wir uns einen Link zur Löschfunktion, nach

$smarty->assign('LINK_PASSWORD', xtc_href_link(FILENAME_ACCOUNT_PASSWORD, '', 'SSL'));

fügen wir

$smarty->assign('LINK_DELETE', xtc_href_link(FILENAME_ACCOUNT_DELETE, '', 'SSL'));

ein.

Die Variable {$LINK_DELETE} steht somit im Template templates/[template]/module/account.html zur Verfügung und kann dort an passender Stelle, beispielsweise unter dem Link zur Passwortänderung, platziert werden.

Auch diese Änderungen finden sich der Übersicht halber nochmal in der Textdatei, account_delete.php und das zugehörige Template stehen ebenfalls zum Download bereit.

Wichtiger Hinweis: Derzeit sieht die “Account löschen”-Funktionalität keine weiteren Sicherheitsabfragen vor! Wer das braucht muss es selbst implementieren! Da xt:Commerce sämtliche Informationen bei einer Bestellung in die order-Tabelle kopiert sind durch das Löschen eines Benutzeraccounts weiterhin alle Rechnungen im vollen Umfang abrufbar.

[tags]xtc, xt:commerce, datenschutz, privacy[/tags]

Der ein oder andere Template-Schrauber für xt:Commerce sollte sich das mal dringend durchlesen – und beherzigen:

The easiest way to achieve simplicity in your markup is to remove everything that’s inappropriate or not necessary. This includes, among other things, tables for layout, font elements, inline style attributes, and inline JavaScript. There’s no place in present-day markup for any of these.

via WebdevBits.

[tags]xhtml, css, markup, xtc, xtcommerce[/tags]

Das spart jede Menge Sucharbeit. Kleiner Tipp noch von mir: Die nicht zugänglichen Javascript-Popups auch gleich noch rausschmeißen und beispielsweise durch JsPopUp von Dirk Ginader ersetzen.

update: Ich musste feststellen, dass das ändern des &-Zeichens zumindest dann zu Problemen führt, wenn man die suchmaschinenfreundlichen URLs aktiviert hat. Man kann sich anschließend weder einloggen noch Artikel in den Warenkorb legen. Vorher also gegebenenfalls mal testen. Da die SEF URLs ja ohne ? und & auskommen, besteht das Validierungsproblem an dieser Stelle ohnehin nicht.

Angefangen hat alles mit einem Besuch des Biathlon-Weltcups in Oberhof, bei dem die Kurzfassung „Scheiß Wetter, gutes Eventâ€? lautet, danach kam Jobs nächster Coup, wie die c’t titelte, nämlich das lang erwartete iPhone und das schnell noch umbenannte Apple TV. Kurztripp in die Schweiz, ein etwas längerer nach Hause und schließlich und endlich die Freigabe von Worpress 2.1.

Hier wird das Feld von hinten aufgeräumt, WordPress 2.1 ist bereits installiert. Zu den anderen Punkten gibt es möglicherweise in Kürze hier noch mehr zu lesen, nur zu den neuen Apple-Produkten nicht. Da haben so viele andere schon genug dazu geschrieben, da brauch ich nicht auch noch mitgackern.

Apropos gackern: Der Shop nimmt langsam endgültige Formen an und die Kritik an xt:Commerce würde mittlerweile wohl ein ganzes Buch füllen. Aber auch dazu ein anderes mal mehr.

xtc_draw_hidden_field('trx_paymenttyp', 'cc')

der folgende Code einzufügen:

.xtc_draw_hidden_field('trx_typ', 'preauth')

Ab sofort wird die Karte nur noch authentifiziert, die Abbuchung kann man dann über die iPayment-Administration auf Knopfdruck veranlassen, sobald die Waren wirklich auf die Reise gehen.

[tags]xtc, xtcommerce, ipayment, creditcard, kreditkarte, preauth, zahlungspufferung, zahlung puffern[/tags]

//don’t know why, but this happens sometimes and new user becomes admin

create_account.php

[tags]xtc, xtcommerce, pfusch, kommentar, comment[/tags]

In the real world, a degree of common sense is required

Andy Budd, CSS Mastery, Seite 9

Was dabei herauskommt, wenn man Dinge umsetzt, ohne zu hinterfragen, ob das, was man tut, auch vernünftig ist, zeigt das neuste Template, das sich im Shop von xt:Commerce findet.

Neben vielen anderen bei GreenVelvet, welches ebenfalls von bluegate erstellt wurde, bemängelten Punkten hatte ich vor allem auf die fehlende semantische Relevanz der verwendeten Tags hingewiesen, um mir daraufhin im Forum sagen lassen zu müssen, dass man beispielsweise die Boxüberschriften nicht unbedingt als Ãœberschriften auszeichnen müsse, weil sie ja keinerlei contentspezifische Information enthalten. Ich habe auf eine Antwort verzichtet, primär weil mir die Art und Weise, wie man bei xt:Commerce (nicht) mit Kritik umgehen kann, zuwider läuft. Aber auch, weil man so etwas nicht mehr auf rationeller Ebene diskutieren kann, zum einen ist es ja gar keine Ãœberschrift, zum anderen bekommt sie aber eine CSS-Klasse zugewiesen, die ‘Heading’ im Namen trägt.

Schaut man sich jetzt aber RedRiver an, dann findet man bereits auf der Startseite zahlreiche Überschriften. Bei genauerem Hinsehen fällt auf, dass die Boxüberschriften jetzt in den Genuss einer semantisch korrekten Auszeichnung kommen, was denen von GreenVelvet ja noch vehement verwehrt wurde.
Und was noch auffällt: Alle Boxüberschriften sind Überschriften erster Ordnung. Wenn das mal kein Sturz die Karrierleiter hinauf ist. Aus der absoluten Bedeutungslosigkeit der Tagsuppe direkt zur wichtigsten aller Überschriften. Aber sind sie das wirklich? Gibt es keine wichtigeren Überschriften auf der Seite? Natürlich gibt es die und hier schließt sich der Kreis zum eingangs erwähnten Zitat von Andy Budd: Man sollte, bevor man etwas tut, nachdenken, ob es so, wie man es zu tun gedenkt, auch Sinn macht. Denn nicht umsonst gibt es sechs verschiedene Gewichtungsstufen für Überschriften. Und die sollte man dann auch passend einsetzen.

[tags]xtc, xtcommerce, markup[/tags]

$data_products = '<table width="100%" border="0" cellspacing="0" cellpadding="0">';
for ($i = 0, $n = sizeof($order->products); $i < $n; $i++) {
 
        $data_products .= '<tr>' . "\n" . '            <td class="main" align="left" valign="top">' . $order->products[$i]['qty'] . ' x ' . $order->products[$i]['name'] . '</td>' . "\n" . '                <td class="main" align="right" valign="top">' . $xtPrice->xtcFormat($order->products[$i]['final_price'], true) . '</td>' . "\n";
        if (ACTIVATE_SHIPPING_STATUS == 'true') {
 
                $data_products .= '<tr>
                                                        <td class="main" align="left" valign="top">
                                                        <nobr><small>' . SHIPPING_TIME . $order->products[$i]['shipping_time'] . '
                                                        </small></nobr><nobr></nobr></td>
                                                        <td class="main" align="right" valign="top"> </td></tr>';
 
        }
        if ((isset ($order->products[$i]['attributes'])) && (sizeof($order->products[$i]['attributes']) > 0)) {
                for ($j = 0, $n2 = sizeof($order->products[$i]['attributes']); $j < $n2; $j++) {
                        $data_products .= '<tr>
                                                                <td class="main" align="left" valign="top">
                                                                <nobr><small> <i> - ' . $order->products[$i]['attributes'][$j]['option'] . ': ' . $order->products[$i]['attributes'][$j]['value'] . '
                                                                </i></small></nobr><nobr></nobr></td>
                                                                <td class="main" align="right" valign="top"> </td>';
                }
        }
 
        $data_products .= '' . "\n";
 
        if ($_SESSION['customers_status']['customers_status_show_price_tax'] == 0 && $_SESSION['customers_status']['customers_status_add_tax_ot'] == 1) {
                if (sizeof($order->info['tax_groups']) > 1)
                        $data_products .= '            <td class="main" valign="top" align="right">' . xtc_display_tax_value($order->products[$i]['tax']) . '%</td>' . "\n";
        }
        $data_products .= '' . "\n";
}
$data_products .= '</table>';
$smarty->assign('PRODUCTS_BLOCK', $data_products);

Ich habe mich für eine Kombination aus einer unsortierten Liste (ein Punkt pro Produkt) und einer Definitionsliste für die einzelnen Produktoptionen entschieden. Das ganze sieht dann so aus:

$data_produtcs = '';
for ($i = 0, $n = sizeof($order->products); $i < $n; $i++) {
 
        $data_products .= '<li><dl><dt>' . $order->products[$i]['qty'] . ' x ' . $order->products[$i]['name'] . '</dt>' . "\n" . '                <dd>' . $xtPrice->xtcFormat($order->products[$i]['final_price'], true) . '</dd>' . "\n";
        if (ACTIVATE_SHIPPING_STATUS == 'true') {
 
                $data_products .= '
                                                        <dd class="shipping_time">' . SHIPPING_TIME . $order->products[$i]['shipping_time'].'</dd>';
 
        }
        if ((isset ($order->products[$i]['attributes'])) && (sizeof($order->products[$i]['attributes']) > 0)) {
                for ($j = 0, $n2 = sizeof($order->products[$i]['attributes']); $j < $n2; $j++) {
                        $data_products .= '<dd class="product_attribute">
                                                                <em>' . $order->products[$i]['attributes'][$j]['option'] . ': ' . $order->products[$i]['attributes'][$j]['value'] . '</em>';
                }
        }
 
        $data_products .= '' . "\n";
 
        if ($_SESSION['customers_status']['customers_status_show_price_tax'] == 0 && $_SESSION['customers_status']['customers_status_add_tax_ot'] == 1) {
                if (sizeof($order->info['tax_groups']) > 1)
                        $data_products .= '            <dd class="tax_group">' . xtc_display_tax_value($order->products[$i]['tax']) . '%</dd>' . "\n";
        }
        $data_products .= '</dl>' . "\n";
}
$smarty->assign('PRODUCTS_BLOCK', $data_products);

Durch das Zuweisen einzelner Klassen lassen sich die einzelnen dd‘s explizit ansprechen. Die öffnende unsortierte Liste befindet sich bei mir im Template – weil ich ursprünglich dachte, da würden vernünftige Codeteile ankommen und nicht gleich ein ganzer Block grausamsten HTMLs.

Besser versteckt ist die Tabelle für die Gesamtsummation. In checkout_confirmation.php findet sich da nur die Tabellenhülle:

$total_block = '<table>';
if (MODULE_ORDER_TOTAL_INSTALLED) {
        $order_total_modules->process();
        $total_block .= $order_total_modules->output();
}
$total_block .= '</table>';
$smarty->assign('TOTAL_BLOCK', $total_block);

Das eigentlich Chaos fabriziert eine Klasse, order_total(), um genau zu sein. Die findet sich in includes/classes/order_total.php.
Dort ist der Bandwurm

$output_string .= '              <tr>'."\n".'                <td align="right" class="main">'.$GLOBALS[$class]->output[$i]['title'].'</td>'."\n".'                <td align="right" class="main">'.$GLOBALS[$class]->output[$i]['text'].'</td>'."\n".'              </tr>';

durch

$output_string .= '<dt>'.$GLOBALS[$class]->output[$i]['title'].'</dt>'."\n".'<dd>'.$GLOBALS[$class]->output[$i]['text'].'</dd>';

zu ersetzen.
In checkout_confirmation.php muss anschließend noch die Tabelle raus, weil die kein Mensch braucht:

if (MODULE_ORDER_TOTAL_INSTALLED) {
        $total_block = '<dl id="total_block">';
        $order_total_modules->process();
        $total_block .= $order_total_modules->output();
        $total_block .= "</dl>";
        $smarty->assign('TOTAL_BLOCK', $total_block);
}

Bei der Gelegenheit kann man dann auch gleich alles in die if-Anweisung packen. Beim Originalcode hätte man nämlich, sollte das Modul nicht installiert sein, einen leeren Tabellencontainer im Markup stehen:

<table></table>

[tags]xtcommerce, xtc, template, markup[/tags]

define('DATE_FORMAT_SHORT', '%d.%m.%Y');  // this is used for strftime()
define('DATE_FORMAT_LONG', '%A, %d. %B %Y'); // this is used for strftime()
define('DATE_FORMAT', 'd.m.Y');  // this is used for strftime()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');
define('DOB_FORMAT_STRING', 'dd.mm.jjjj');
 
function xtc_date_raw($date, $reverse = false) {
  if ($reverse) {
    return substr($date, 0, 2) . substr($date, 3, 2) . substr($date, 6, 4);
  } else {
    return substr($date, 6, 4) . substr($date, 3, 2) . substr($date, 0, 2);
  }
}

wird geändert in

define('DATE_FORMAT_SHORT', '%m/%d/%Y');  // this is used for strftime()
define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
define('DATE_FORMAT', 'm/d/Y');  // this is used for strftime()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');
define('DOB_FORMAT_STRING', 'mm/dd/jjjj');
 
function xtc_date_raw($date, $reverse = false) {
  if ($reverse) {
    return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
  } else {
    return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
  }
}

Um bei der Anlage eines Kundenkontos (sofern das Geburtsdatum abgefragt wird) dann auch die richtigen Hinweise und Fehlermeldungen zu geben, müssen noch die Konstanten ENTRY_DATE_OF_BIRTH_ERROR und ENTRY_DATE_OF_BIRTH_TEXT angepasst werden:

define('ENTRY_DATE_OF_BIRTH_ERROR', 'Your date of birth has to be entered in the following form MM/DD/YYYY (e.g. 05/21/1970) ');
define('ENTRY_DATE_OF_BIRTH_TEXT', '* (e.g. 05/21/1970)');

[tags]xtcommerce, xtc, language[/tags]

Die Liste wird ständig erweitert, also ab damit in die Bookmarks.

[tags]xtcommerce, xtc, lopsta[/tags]

Ab sofort zahlen auch Bulgaren und Rumänen Mehrwertsteuer, wenn sie in Deutschland bestellen. Und damit der xt:Commerce-Shop das auch brav richtig macht, muss man die Tabellen anpassen:

UPDATE zones_to_geo_zones SET geo_zone_id= 5 WHERE zone_country_id IN (33,175);

Das Land mit der ID 33 ist Bulgarien, das mit 175 Rumänien. Zumindest bei 3.04 SP2.1. Vorher also gegebenenfalls überprüfen und wie immer gilt: Ausführen auf eigene Gefahr und nur mit Backup in der Hinterhand!

[tags]xtc, xtcommerce, eu, erweiterung[/tags]

Aus dem Werbeversprechen von xt:Commerce:

Maximale Flexibilität durch ein Templatesystem (Smarty)

Nur falls das jemand sucht: Das Markup für die Darstellung der Adressen aus dem Adressbuch (beim Checkout) befindet sich in checkout_shipping_address.php.

$address_content = '<table border="0" width="100%" cellspacing="0" cellpadding="0">';
$radio_buttons = 0;
 
$addresses_query = xtc_db_query("select address_book_id, entry_firstname as firstname, entry_lastname as lastname, entry_company as company, entry_street_address as street_address, entry_suburb as suburb, entry_city as city, entry_postcode as postcode, entry_state as state, entry_zone_id as zone_id, entry_country_id as country_id from ".TABLE_ADDRESS_BOOK." where customers_id = '".$_SESSION['customer_id']."'");
while ($addresses = xtc_db_fetch_array($addresses_query)) {
	$format_id = xtc_get_address_format_id($address['country_id']);
 
	$address_content .= ' <tr>
	                <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                <td colspan="2"><table border="0" width="100%" cellspacing="0" cellpadding="2">
	                ';
 
	if ($addresses['address_book_id'] == $_SESSION['sendto']) {
		$address_content .= '                  <tr id="defaultSelected" class="moduleRowSelected" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)" onclick="selectRowEffect(this, '.$radio_buttons.')">'."\n";
	} else {
		$address_content .= '                  </tr><tr class="moduleRow" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)" onclick="selectRowEffect(this, '.$radio_buttons.')">'."\n";
	}
	$address_content .= '
	                    <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                    <td class="main" colspan="2"><strong>'.$addresses['firstname'].' '.$addresses['lastname'].'</strong></td>
	                    <td class="main" align="right">'.xtc_draw_radio_field('address', $addresses['address_book_id'], ($addresses['address_book_id'] == $_SESSION['sendto'])).'</td>
	                    <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                  </tr>
	                  <tr>
	                    <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                    <td colspan="3"><table border="0" cellspacing="0" cellpadding="2">
	                      <tr>
	                        <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                        <td class="main">'.xtc_address_format($format_id, $addresses, true, ' ', ', ').'</td>
	                        <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                      </tr>
	                    </table></td>
	                    <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	                  </tr>
	                </table></td>
	                <td>'.xtc_draw_separator('pixel_trans.gif', '10', '1').'</td>
	              </tr>';
 
	$radio_buttons ++;
}
$address_content .= '</table>';
$smarty->assign('BLOCK_ADDRESS', $address_content);

Hier eine sinvollere und dreimal so kurze Alternative:

		$address_content = '<ul id="address_block">';
		$radio_buttons = 0;
 
		$addresses_query = xtc_db_query("select address_book_id, entry_firstname as firstname, entry_lastname as lastname, entry_company as company, entry_street_address as street_address, entry_suburb as suburb, entry_city as city, entry_postcode as postcode, entry_state as state, entry_zone_id as zone_id, entry_country_id as country_id from ".TABLE_ADDRESS_BOOK." where customers_id = '".$_SESSION['customer_id']."'");
		while ($addresses = xtc_db_fetch_array($addresses_query)) {
			$format_id = xtc_get_address_format_id($address['country_id']);
 
			$address_content .= sprintf('<li>%s<label for="field_addresses_%s">%s %s</label><br /><span class="address">%s</span></li>', xtc_draw_radio_field('address', $addresses['address_book_id'], ($addresses['address_book_id'] == $_SESSION['sendto'])), $addresses['address_book_id'], $addresses['firstname'], $addresses['lastname'],xtc_address_format($format_id, $addresses, true, ' ', ', '));
			$radio_buttons ++;
		}
		$address_content .= '</ul>';
		$smarty->assign('BLOCK_ADDRESS', $address_content);

Auch wenn mich dieses vermischen von php-Code und Markup nicht wirklich begeistert.

Wenn wir gerade dabei sind können wir auch noch die Abkürzungen für die Bundesländer aktualisieren, oder wer assoziiert Hamburg mit HAM und Rheinland-Pfalz mit RHE? Um einer Standardinstallation die Abkürzungen gemäß ISO-3166-2 zu spendieren, ist der Datenbank folgendes mitzuteilen:

update zones set zone_code = 'NI' where zone_id = 79;
update zones set zone_code = 'BW' where zone_id = 80;
update zones set zone_code = 'BY' where zone_id = 81;
update zones set zone_code = 'BE' where zone_id = 82;
update zones set zone_code = 'BR' where zone_id = 83;
update zones set zone_code = 'HB' where zone_id = 84;
update zones set zone_code = 'HH' where zone_id = 85;
update zones set zone_code = 'HE' where zone_id = 86;
update zones set zone_code = 'MV' where zone_id = 87;
update zones set zone_code = 'NW' where zone_id = 88;
update zones set zone_code = 'RP' where zone_id = 89;
update zones set zone_code = 'SL' where zone_id = 90;
update zones set zone_code = 'SN' where zone_id = 91;
update zones set zone_code = 'ST' where zone_id = 92;
update zones set zone_code = 'SH' where zone_id = 93;
update zones set zone_code = 'TH' where zone_id = 94;

[tags]xt:commerce, xtc, templates, statecode[/tags]

Es befindet sich derzeit in der Überarbeitung und das einzige derzeit im Shop erhältliche Template verzichtet bereits auf die bemängelten tabellenlosen Tabellen und hat auch sonst einiges an codetechnischen Verbesserungen an Bord.
Das ist mal eine wirklich schnelle Reaktion und bestätigt den eingeschlagenen Weg der Veröffentlichung, auch wenn der im xt:Commerce-Forum teilweise heftige Kritik ausgelöst hat.

[tags]xhtml, css, xt:commerce, template[/tags]

Im Shop von xt:Commerce gibt es neuerdings ein CSS-basiertes Template, darauf aufmerksam geworden bin ich aber durch ein Posting im Sponsorenbereich (deshalb auch keinen Link dorthin), wo auch noch zwei Alternativen präsentiert werden.

Leider haben alle drei Templates respektive deren Designer eines gemein: Sie haben es nicht verstanden. Man hat irgendwo mal was aufgeschnappt, dass man Layouts mit Tabellen nicht mehr machen würde und stattdessen CSS das Mittel der Wahl wäre und macht es halt jetzt so, weil es hip ist. Ansonsten hat sich an der Arbeitsweise nichts geändert, der Quellcode ist weiterhin völlig unnötig aufgeblasen, nur die Tags haben sich geändert.

Die beiden kommerziell erhältlichen Templates habe ich mir mal näher angesehen:

• GreenVelvet: Anpassungen mit Samthandschuhen
• i24-cssblau: TABLElos sinnlos

Anpassungen mit Samthandschuhen

Beispiel GreenVelvet, das angesprochene, im xt:Commerce-Shop angebotene Template. Die Zitate sind aus dem xt:Commerce-Shop. Die Rechtschreibfehler auch.

Nahezu tabellebloses (CSS basiertes) Template für den xt:Commerce Shop v3.0.4 SP2! Dieses Template basiert (im Gegensatz zu den Standard-Templates des xt:Commerce Shops) auf der Stylesheet Technologie (CSS)

Die Aussage ist per se schon mal falsch. Auch das Standardtemplate von xt:Commerce nutzt CSS. Davon ab: xt:Commerce wirklich von seinen vielen Layout-Tabellen zu entkernen ist eine Lebensaufgabe. Definitiv. Deshalb nehme ich es auch keinem Designer übel, wenn er die ein oder andere Tabelle, die sich in den Untiefen des php-Codes versteckt und einem eben nicht die Flexibilität gibt, die man sich durch den Einsatz einer Template-Engine verspricht und die einem auch durch entsprechende Werbeversprechen suggeriert wird, nicht rausbekommt.
Aber, nehmen wir als Beispiel die Login-Box, auf deren komplettes Markup in boxes/box_login.html problemlos Einfluss genommen werden kann. Nur Tabellenverschachtelungen aufzulösen, um dann doch Tabellen für Layoutzwecke zu mißbrauchen, ist definitiv am Ziel vorbeigeschossen.

Bis zu 70% weniger HTML Quelltext

Ohne das anhand irgendwelcher Berechnungen belegen zu können: Bei konsequenter Vorgehensweise hätten wir wahrscheinlich 90% weniger Quelltext. Vielleicht sogar noch mehr. Ich hab auch keine Ahnung, auf was sich die Zahl bezieht. Auf das Gesamtprodukt wahrscheinlich nicht, denn dann könnte man da was verbindliches hinschreiben. Kein ‘bis zu’. Die Info-Boxen sind damit jedenfalls nicht gemeint.

Große Töne spucken kann jeder, deshalb hier Handfestes:

Das ist der Originalcode aus dem Demoshop.

<table width="100%" border="0" cellpadding="2" cellspacing="0">
	<tr>
		<td class="infoBoxHeading_right"><table width="100%"  border="0" cellpadding="0" cellspacing="0">
			<tr>
				<td class="infoBoxHeading_right">Willkommen zurück! </td>
				<td> </td>
			</tr>
		</table></td>
		</tr>
		<tr>
			<td class="infoBox_right" align="left"> <table width="95%"  border="0" cellpadding="2" cellspacing="0">
		<tr>
			<td class="boxText"><form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
			<table width="100%"  border="0" cellpadding="0" cellspacing="0">
				<tr>
					<td class="main">eMail-Adresse:</td>
				</tr>
				<tr>
					<td><input type="text" name="email_address" size="25" maxlength="50" /></td>
				</tr>
				<tr>
					<td class="main">Passwort:</td>
				</tr>
				<tr>
					<td><table width="100%"  border="0" cellpadding="2" cellspacing="0">
						<tr>
							<td><input type="password" name="password" size="10" maxlength="30" /> </td>
							<td><input type="image" src="templates/xtc4/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /></td>
						</tr>
					</table></td>
				</tr>
			</table></form></td>
		</tr>
		</table></td>
	</tr>
	<tr>
		<td class="infoBox_right" align="right"><a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a></td>
	</tr>
</table>

Ãœbel. Aber soll ja eh nur als abschreckendes Beispiel dienen.

In GreenVelvet sieht das jetzt so aus:

<div class="boxVarianteZweiHeader">Willkommen zurück!</div>
<div class="boxVarianteZweiBody" style="margin-bottom:15px;">
<form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
<table width="100%"  border="0" cellpadding="0" cellspacing="0">
	<tr>
		<td>eMail-Adresse:</td>
	</tr>
	<tr>
		<td><input type="text" name="email_address" size="25" maxlength="50" /></td>
	</tr>
	<tr>
		<td style="padding-top:6px;">Passwort:</td>
	</tr>
	<tr>
		<td><table width="100%"  border="0" cellpadding="0" cellspacing="0">
			<tr>
				<td style="padding-right:4px;"><input type="password" name="password" size="10" maxlength="30" /> </td>
				<td width="100%"><input type="image" src="templates/GreenValvet/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /></td>
			</tr>
		</table></td>
	</tr>
	<tr>
		<td style="padding-top:8px;"><hr /><a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a></td>
	</tr>
</table>
</form>
</div>

Ich bin Brillenträger seit Geburt. Es könnte durchaus sein, dass ich den Vorteil des ganzen rein optisch nicht sofort erfasse. Aber was zum Geier will ich mit dem Inline-CSS, das mir bei späteren Designanpassungen nur unnötig Arbeit und Probleme verursacht? Und mit dem unnötigen Blocklevel-Element, mit dem ein anderes Blocklevel-Element eingeschlossen wird? Und was will ich mit dieser Tabelle? Von der nicht vorhandenen semantischen Relevanz der eingesetzten Tags mal ganz zu schweigen.

<form id="loginbox" method="post" action="http://www.xtc-demo.de/login.php/action/process/"><input type="hidden" name="XTCsid" value="" />
	<fieldset>
		<legend>Willkommen zurück!</legend>
		<p>
			<label for="field_email">eMail-Adresse:</label>
			<input type="text" name="email_address" size="25" id="field_email" maxlength="50" />
		</p>
		<p>
			<label for="field_password">Passwort:</label>
			<input type="password" name="password" size="10" id="field_password" maxlength="30" />
		</p>
		<p>
			<input type="image" src="templates/GreenValvet/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " />
		</p>
		<p>
			<a href="http://www.xtc-demo.de/password_double_opt.php/">Passwort vergessen?</a>
		</p>
	</fieldset>
</form>

Man kann jetzt darüber streiten, ob man unter semantischen Gesichtspunkten eine sortiere Liste anstatt der <p>-Tags einsetzt. Aber man kann es auch übertreiben mit Listen.
Den Submit-Button lassen wir mal so. Um mit <button> weitreichendere Gestaltungsmöglichkeiten zu haben und nicht zwanghaft das Bild im Markup platzieren müßten, würde weitreichende Änderungen in der Shopsoftware erfordern.
Die Formatierung wird komplett per CSS geregelt, um aber z.B. den Submit-Button rechts vom Passwort-Feld zu haben, müsste man noch ein paar Klassen zuweisen.

Kommen wir jetzt aber zum Schwanzvergleich:

Der Originalcode liegt bei 1434 Byte, die GreenVelvet-Variante schafft es immer noch auf 1055 Bytes, was π mal Daumen 73,5% der Originalgröße sind (damit liegt das Einsparpotential bei weniger als 30%!). Mein Code kommt auf 756 Bytes. Damit habe ich den kleinsten. Code, wohlgemerkt. Und gleichzeitig mit fast 50% das größte Einsparpotential (47,3% für die Nietenzähler). Und das ist nur ein Beispiel von vielen.

Alle Menüpunkte sind in Listenform abgebildet und können mit wenigen Schritten im Stylesheet angepasst werden

<div id="submenu" style="margin-bottom:15px;">
	<a class="header">Kategorien</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c4_Onlineshops.html/">Onlineshops</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c1_Shopsoftware.html/">Shopsoftware</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c2_Shopsysteme.html/">Shopsysteme</a>
	<a class="level1" href="http://www.xtc-demo.de/index.php/cat/c3_E-commerce.html/">E-commerce</a>
</div>

Hat jemand die Liste gesehen? Die muss irgendwo auf dem Weg abhanden gekommen sein. Das gilt analog für so ziemlich alle übrigen Navigationen auch. /boxes/box_content.html, /boxes/box_information.html, /boxes/box_best_sellers.html, alles keine Listen, aber optisch auf Liste getrimmt. Die einzige wirkliche Liste ist die Top-Navigation. Aber entweder muss ich das unter Lernresistenz verbuchen oder einfach unter Unwissen.

Das ganze soll, wenn es fertig ist, mal so aussehen:

<ul id="horizontalmenu">
	<li class="link"><a href="http://www.xtc-demo.de/shopping_cart.php">Warenkorb</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
	<li class="link"><a href="http://www.xtc-demo.de/account.php">Ihr Konto</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
	<li class="link"><a href="http://www.xtc-demo.de/checkout_shipping.php">Kasse</a></li>
	<li><img src="img/menuspacer.gif" alt="Menabstand" width="2" height="36" style="border:none; padding:0px; margin:0px; line-height:0px; display:block;"/></li>
</ul>

Unnötige Klassenzuweisungen, Inline-CSS und sinnlose Alternativtexte für Platzhalter, bei denen ich mir gar nicht vorstellen will, wie sie ein Screenreader artikuliert. Ich hatte nicht erwartet, heutzutage noch so viel Blödsinn auf so wenig Raum zu sehen…
Dazu kommen dann noch 41 Zeilen CSS, die den Rest der Formatierung übernehmen.

Horizontales Menü mit Originalcode

Man kann das ganze aber auch mit fünf Zeilen Markup und ohne Inline-CSS oder irgendwelche Spacer-Einträgen realisieren:

Modifiziertes Horizontales Menü (aka Horizontales Menü reloaded)

Ich habe die in Pixeln definierte Schriftgröße mal dringelassen, der Vergleichbarkeit wegen. Und ja, ich benutze line-height, um eine vertikal zentrierte Ausrichtung von Text zu erreichen. Denn die vertikale Ausrichtung ist nach wie vor eine der (Kinder-)Krankheiten von CSS.

Inklusive sämtlicher Darstellungs- Bugfixes für den Internet Explorer!

Alle im einen globalen Stylesheet. Realisiert durch den Underscore-Hack. Damit auch die Browser, die diese Hacks nicht brauchen, genötigt werden, sie mit zu laden. Mit Conditional Comments wär’ das nicht passiert.
Und die Hacks hätte man sich wahrscheinlich sogar sparen können, wenn man gleich zu Beginn die Standardwerte der Browser für paddings, margins und borders zurückgesetzt hätte:

* {
	margin: 0;
	padding: 0;
	border: 0;
}

Da hat sich einer wirklich Mühe gegeben. Die hätte er sich aber auch sparen können. So ist das Template um keinen Deut besser als das standardmäßig beiliegende…

TABLElos sinnlos

(Ja, die Ãœberschrift ist geklaut)

Die Idee, die Layout-Tabellen aus xt:Commerce zu verbannen ist ja nicht neu. Auf die YAML-Implementierung für xt:C hatte ich ja schon hingewiesen. Und natürlich haben auch andere Anbieter fertiger xt:C-Templates entsprechende Pferde im Stall. i24-cssblau ist so eines.

Vom Ansatz her wirkt das ganze vielversprechend. Die Überschriften der Boxen sind dank <h3>-Auszeichnung auch als solche zu erkennen, Navigationselemente in den Boxen sind beispielsweise als Liste ausgezeichnet und die notwendigen Styles für den Internet Explorer werden über Conditional Comments eingebunden. Die Benamung und der Aufbau der Stylesheets legt den Schluss nahe, dass das ganze auf YAML basiert, steht nur nirgends. Sollte es aber, wenn es denn so ist.

Schaut man gezielt unter die Haube, fallen dann aber doch einige Ungereimtheiten ins Auge.

Das fängt mit der zentrierten Ausrichtung des Layouts an, die mit einem

<div align="center">
</div>

direkt nach dem Body erreicht wird, im CSS findet sich für #hauptrahmen aber auch die übliche Vorgehensweise mittels

#hauptrahmen {
	margin: 0 auto;
}

Doppelt gemoppelt hält besser…

Auch die Überschriften sind nicht wirklich logisch aufgebaut. So sind zwar die Boxen-Überschriften als </h3> ausgezeichnet, Überschriften erster Ordnung werden mehrfach verwendet (was zumindest vom Validator nicht bemängelt wird, der prüft ja aber auch auf Syntax, nicht auf Logik), dafür fehlen Überschriften zweiter Ordnung gänzlich.

Die Navigation in den Boxen ist, wie schon erwähnt, mit Listen gelöst. Allerdings werden die Unterkategorien nur optisch eingerückt, die Listen sind nicht korrekt ineinander verschachtelt. Wie das geht, steht hier. Die Top-Navigation wurde dabei glatt vergessen:

<div id="topmenu">
<a href="http://www.shop.xtc-services.de/account.php">Ihr Konto</a> | <a href="http://www.shop.xtc-services.de/shopping_cart.php">Warenkorb</a> | <a href="http://www.shop.xtc-services.de/checkout_shipping.php">Kasse</a>
</div>

Bis zu 70% weniger HTML Quelltext, dadurch sind Wesentlich geringere Ladezeiten der Shopseiten möglich.

Wieder die Loginbox als Vorlage nehmend kommen wir hier nur noch auf 718 Bytes, was in etwa 50% der originalen Größe sind (das hidden-Feld wurde für die Vergleichbarkeit hinzugefügt). Ich bin geschlagen, kann damit aber leben.

<div class="box_header_right"><h3>Willkommen zurück!</h3></div>
<div class="box_center_right">
	<form id="loginbox" method="post" action="http://www.shop.xtc-services.de/login.php?action=process"><input type="hidden" name="XTCsid" value="" />
		eMail-Adresse:<br />
		<input type="text" name="email_address" size="25" maxlength="50" /><br />
		Passwort:<br />
		<input type="password" name="password" size="10" maxlength="30" /><br />
		<input type="image" src="templates/i24-cssblau/buttons/german/button_login_small.gif" alt="Anmelden" title=" Anmelden " /><br />
		<span style="text-align: right;"><a href="http://www.shop.xtc-services.de/password_double_opt.php">Passwort vergessen?</a></span>
	</form>
</div>

Es wird keinerlei Zuordnung der Label-Texte zu den zugehörigen Feldern vorgenommen, Inline-CSS sorgt für eine rechtsbündige Ausrichtung des Textes und das Blocklevel-Element <form> steht nach wie vor in einem <div>-Container und auch die Überschrift ist unsinnigerweise in einem solchen eingeschlossen. Dieses zwanghafte Verschachteln erinnert an Tabellenlayouts, ist unnötig und zieht sich konsequent durch das gesamte Design.

Apropos Tabellen, die sucht man in der Tat vergebens.

Das Template ist ein reines CSS Template ohne eine Tabelle.
Es wurden aus allen Template Dateien alle Tabellen entfernt.

Das kann man wörtlich nehmen. Es wurden rigoros und ohne Rücksicht auf Verluste alle Tabellen entfernt. Auch dort, wo sie durchaus Sinn machen. Wir erinnern uns: Tabellen nutzt man zum Darstellen tabellarischer Inhalte. Und die gibt es beispielsweise im Warenkorb. Ohne Tabellen sieht das dann so aus:

<span style="width:10%; display: block; float:left;"><strong>Anzahl</strong></span>
<span style="width:44%; display: block; float:left;"><strong>Artikel</strong></span>
<span style="width:20%;  display: block;float:left;"><strong>Einzelpreis</strong></span>
<span style="width:20%;display:block;float:left; "><strong>Summe</strong></span>
<span style="width:5%;display:block; float:left;"><strong>X</strong></span>
<span style="clear: both;"></span>
<br />
 
<div class="cartbg1">
	<span style="width:10%; display: block; float:left;"><input type="text" name="cart_quantity[]" value="1" size="2" /><input type="hidden" name="products_id[]" value="1" /><input type="hidden" name="old_qty[]" value="1" /></span>
	<span style="width:44%; display: block; float:left; ">
		<strong><a href="http://www.shop.xtc-services.de/Individual-Designs/Individual-XTC-Template-Light::1.html">Individual XTC Template Light</a></strong>
		<br />
 
	</span>
 
	<span style="width:20%;  display: block;float:left;"> 95,00 EUR</span>
	<span style="width:20%;display:block;float:left; "> 95,00 EUR</span>
	<span style="width:5%;display:block;float:left; "><input type="checkbox" name="cart_delete[]" value="1" /></span>
	<span style="clear: both;"></span>
	<br />
 
</div>

Das ist, gelinde gesagt, der größte Schwachsinn, der mir in 10 Jahren CSS je untergekommen ist.

Und als ob das noch nicht genug wäre kommen unverzeihliche Usability-Fehler hinzu. So lassen sich die Produktbeschreibungen und zusätzliche Bilder erst durch einen Klick einsehen, über Javascript wird dabei das jeweilige Element auf sichtbar geschalten. Bei deaktiviertem Javascript schaut man in die Röhre. Darüber hinaus ist die angedeutete Tabnavigation mit Bildern gelöst. Warum sich der Mauszeiger beim Überfahren eben dieser in einen Hilfe-Cursor wandelt, erschließt sich auch nicht.

Dabei ist eine Tabnavigation mit CSS wirklich kein Hexenwerk, zumal wenn es um stinknormale, eckige Tabs geht.

Wenn das die Antwort auf tabellenbasierte Layouts sein soll, dann wollen wir hoffen, das sie möglichst schnell ungehört verhallt. Auf der anderen Seite zeigt es auch, das Seiten wie Webkrauts, Vorsprung durch Webstandards und alle anderen weiter machen müssen mit ihrer Aufklärungsarbeit, um allen Beteiligten nahezubringen, das eine Website nicht zwangsläufig deshalb eine bessere Website ist, weil sie keine Tabellen mehr verwendet. Selbst die Tatsache, das eine Website validiert, ist schließlich kein Qualitätsmerkmal, wie das Beispiel iWeb deutlich zeigt. Zu modernem Webdesign gehört definitiv mehr als Tags in einen Editor zu tippen, die nicht mit <t beginnen.

Ich bin zwar etwas früh dran, aber wenn es etwas gibt, das ich mir 2007 wünsche, dann sind es Webdeveloper, welche die ihnen an die Hand gegebenen Werkzeuge vernünftig einzusetzen wissen und nicht, weil sie irgendwo was aufgeschnappt haben, das alte Chaos mit neuen Tags und Attributen versehen.

[tags]xhtml, css, webdevelopment, webstandards, accessibility[/tags]

Da ich ungern größere Abhandlungen am Monitor lese kommt das Buch gerade recht. Gerrit hat seines als Rezensionsexemplar bekommen, ich muss sehen, wo ich bleibe, aber Amazon will ja auch von was leben.

Ebenfalls interessant in dem Zusammenhang: Es gibt bereits ein (fast) fertiges, auf YAML basierendes Template für xt:Commerce. Allerdings habe ich in das meinige schon sehr viel Energie und Zeit investiert, ein Umstieg erscheint da nicht wirklich sinnvoll. Vielleicht mal für einen zukünftigen Shop. Aber dann wohl auch nur als Grundlage. Denn das fertige Template gleicht eher einer div-Suppe…

[tags]yaml, framework, css, xhtml[/tags]

Ich habe mir den gerade mal installiert, vor allem wegen dem tabellenlosen Layoutansatz. Ich bin jetzt nicht so aus dem Häuschen vor Begeisterung. Aber erstmal zu den Fakten:

• 100% Template driven
  Ein wichtiger Punkt. Und keine leere Worthülse wie „Komplettes Layout über HTML Templates zb mit Dreamwaever etc editierbar� (xt:Commerce).
• Valides HTML und CSS
  Auch richtig. Auch wichtig. Leider divitis. Listen werden zwar dort eingesetzt, wo sie sinnvoll sind, aber alles andere wird über div-Tags realisiert, was dann doch wieder Nacharbeit erfordert.
• Sprachvielfalt
  CubeCart bringt von Haus aus schonmal zwölf Sprachen mit. Das kann sich sehen lassen.
• Aufgeräumtes Backend
  Wirkt wesentlich übersichtlicher als das von xt:Commerce, wo ich meistens über die Suchen-Funktion des Browsers „navigiere�, weil durch die endlos lange Liste keiner durchblickt.
• Intelligentere Verwaltung der Sprachen
  Fünf Sprachen in xt:Commerce? Das heißt fünf Textfelder für die Produktbeschreibung, klickt man auf ein Produkt zum bearbeiten. Lädt ewig und führt in Safari zu Fehlermeldungen, weil man keinen vernünftigen Fallback für den WYSIWYG-Editor eingebaut hat. CubeCart listet Sprachvarianten auf einer eigenen Seite, man ruft also nur die auf, die man aktuell auch bearbeiten will.

Hört sich alles sehr gut an. Aber keine Medaille ohne Rückseite.

• Navigation nur auf einer Ebene
  Die Kategorien-Navigation zeigt immer nur die Hauptkategorien. Alle Unterkategorien erscheinen nur im Content-Bereich. Aber so spart man sich natürlich das Problem, korrekt geschachtelte Listen für die Navigation zu generieren.
• Inkonsistente Navigation
  Im Warenkorb ist die Kategoriennavigation plötzlich weg. Zurück geht es nur über den Homepage-Link.
• Hakelige Zuweisung von Produkten zu mehreren Kategorien
  Dass das nur über ein Popup geht, mag noch angehen. Das man aber auch nur im Popup sieht, welchen zusätzliche Kategorien das Produkt zugewiesen ist, ist nicht wirklich benutzerfreundlich.
• Kein Im-/Export
  Mag jetzt für jemanden mit 20 Produkten nicht das K.O.-Kriterium sein, wenn ich dem Kollegen aber erzähle, das er doch bitte nochmal alle 2500 Produkte in CubeCart einpflegen möge, weil ich mir nicht sicher bin, ob das nicht möglicherweise die bessere Shoplösung ist, dann reißt der mir mit Sicherheit den Kopf ab…
• Keine SEO-optimierten URLs
  Suchmaschinenfreundlichkeit gibt es nur mit Hilfe eines externen Mods. Wobei offensichtlich eine recht starke Community hinten dran steht.
• Die Sache mit der Steuer
  Da besteht offensichtlich starker Handlungsbedarf. Ich habe es nicht geschafft, den Shop zur Anzeige der Steuer zu überreden. Weder in der Produktübersicht, noch im Warenkorb. Obwohl sowohl Steuerwerte hinterlegt, den Produkten zugewiesen und auch in der globalen Konfiguration die Anzeige der Steuer aktiviert ist, wird keine angezeigt. Die Ausrichtung auf den US-amerikanischen Binnenmarkt ist hier überdeutlich zu erkennen. Auch die Angabe des Gewichts in Pfund spricht nicht unbedingt für einen internationalen Ansatz.
• To PEAR or not to PEAR?
  CubeCart nutzt einige Pakete aus dem PEAR, unter anderem PEAR::Log und PEAR::Net_Socket. Leider ist man da nicht konsequent, ich hätte es begrüßt, wenn für die Datenbank PEAR::DB respektive der Nachfolger PEAR::MDB2 und für die Template PEAR::HTML_Template_IT zum Einsatz kommen würde. Stattdessen setzt man für die Datenbankanbindung offensichtlich auf was selbstgestricktes und für die Templates auf XTemplate.
• Sprachfiles
  Sprachfiles sind leider sowas von Web 1.0. IMHO. Sie bieten nämlich keinen Fallback. Fehlt in der aktiven Sprache ein Eintrag im Sprachfile, dann steht da gar nichts. Deshalb setze ich für Mehrsprachigkeit auf gettext(). Ein Shop mit dieser Lösung ist mir aber bislang noch nicht untergekommen.

Fazit

Die Tabellenfreiheit erkauft man sich mit zahlreichen Haken und Ösen, vor allem in Bezug auf Navigation und Steuer, die sich aber mit etwas Nacharbeit durchaus lösen lassen (sollten). Wer aber bereits eine xt:Commerce-Lösung am Start hat, dürfte sich mit einer möglichen Umstellung allein aufgrund des fehlenden Imports schwer tun. Auch sonst sind im Admin-Tool manche Sachen sehr schön gelöst, während anderes nur ein Kopfschütteln hervorruft. Derzeit stelle, so traurig das ist, CubeCart keine wirkliche Konkurrenz für xt:Commerce dar, zumindest nicht für den europäischen Markt. Im Auge behalten sollte man die Lösung aber auf jeden Fall.

[tags]xtc, xt:commerce, cubecart, alternative, shop, online-shop[/tags]

This post is password protected. To view it please enter your password below:

Password:

Ein besonderes Übel stellt die Kategorien-Navigation dar. Verschachtelte Tabellen, über Non-Breaking-Spaces erreichte Einrückungen, Hover-Effekte mittels Javascript, Web-Design aus der Steinzeit quasi.

<table width="100%" border="0" cellspacing="0" cellpadding="2">
<tr>
<td class="infoBoxHeading">
<table width="100%" border="0" cellspacing="0" cellpadding="0" >
<tr>
<td class="infoBoxHeading">Kategorien</td>
<td width="10"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="infoBox" align="right">
<table width="95%" border="0" cellspacing="0" cellpadding="2" >
<tr>
<td class="boxText">
<table width="100%">
<tr>
<td class="moduleRow" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)"><img src="templates/xtc4/img/icon_arrow.jpg"/> <b><a href="#"><b>Kategorie I</b></a></b><br />
 -   <a href="#">Unterkat I</a><br />
 -   <a href="#">Unterkat II</a><br />
</td>
</tr>
</table>
<table width="100%">
<tr>
<td class="moduleRow" onmouseover="rowOverEffect(this)" onmouseout="rowOutEffect(this)"><img src="templates/xtc4/img/icon_arrow.jpg"/> <b><a href="#">Kategorie II</a></b><br />
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>

Zum Glück haben das auch schon andere erkannt und so musste ich nicht alles neu schreiben, bei gunnART findet sich dankenswerterweise bereits eine geänderte xtc_show_category.inc.php. Die hat nur einen Schönheitsfehler: Die Listen sind nicht ineinander verschachtelt, wenn es gilt, tiefere Ebenen darzustellen, wird das ganze lediglich durch CSS und damit nur optisch erreicht:

<ul>
   <li class="maincat submenue"><a class="gewaehlt" href="#">Kategorie I</a></li>
   <li class="subcat level1"><a href="#">Unterkat I</a></li>
   <li class="subcat level1"><a href="#">Unterkat II</a></li>
   <li class="maincat"><a href="#">Kategorie II</a></li>
</ul>

Sicherlich schon ein riesiger Fortschritt, wenn man sich es mit dem ursprünglichen Tabellenchaos vergleicht, aber noch nicht der Weisheit letzter Schluß. Das ist mein php-Code möglicherweise auch nicht, der auf der Version von gunnART basiert, aber er erzeugt das, was man haben will: Listen, die korrekt ineinander verschachtelt sind, um so auch denen, die ohne oder mit deaktivierten Stylesheets durch das Web surfen, die Möglichkeit zu geben, Unterkategorien problemlos zu erkennen.

<ul>
   <li><a href="#">Kategorie I</a>
    <ul>
         <li><a href="#">Unterkat I</a></li>
         <li><a href="#">Unterkat II</a></li>
      </ul>
   </li>
   <li><a href="#">Kategorie II</a></li>
</ul>

Die angepasste Version von xtc_show_category.inc.php gibt es zum Download:

xtc_show_category.inc.phps.

Speichern, in das Verzeichnis /source/inc/ des verwendeten Templates legen, nach xtc_show_category.inc.php umbenennen, fertig.

[tags]xtc, xt:commerce, xtcommerce, semantic code, css, html, unordered lists, nested[/tags]

Der xt:Commerce Shop legt ein besonderes Augenmerk auf Sicherheitsrelevante Aspekte,Usability und ist durch einen neuen professionellen Aufbau gekennzeichnet.

Ist nicht von mir, sondern, inklusive aller Fehler, aus der Info-Datei zu xt:Commerce.

Während ich bei meinen Projekten, wie etwa dem neuesten Werk zur Online-Abmahnung von Falschparkern und Parkplatzblockierern, peinlichst darauf achte, sauberen Code zu schreiben, Programm- und Darstellungsschicht über Templates zu trennen und natürlich valides und semantisch sinnvolles (X)HTML und CSS zu produzieren, sind das für xt:Commerce alles Fremdwörter.

Code-Teile finden sich über die komplette Struktur verteilt. Ein bißchen was im inc/-Ordner, ein bißchen was anderes im includes/-Ordner und die Template-Ordner sollte man bei der Suche nach den Codebestandteilen auch nicht vernachlässigen. Nicht nur, das sich hier die ein oder andere Funktion in den verschachtelten Ordnerstrukturen versteckt, auch in den Templates selbst wird noch eifrig PHP-Code ausgeführt. Smarty macht’s möglich und läuft damit meiner Meinung nach dem Template-Konzept vollkommen zuwider, auch wenn Smarty an und für sich vielleicht die bessere Template-Engine ist. Wer dann wenigstens hofft, alle für die Darstellung relevanten HTML-Inhalte in den Templates vorzufinden, wird auch schnell eines besseren belehrt. Viele Funktionen liefern nur den kompletten Codeblock zurück, inklusive aller Tags. Änderungen müssen also am PHP-Code vorgenommen werden und, mangels Plugin-Konzept, bei jedem Update wieder mühsam integriert werden.

Was bleibt ist die Erkenntnis für den ambitionierten Webdeveloper, dass jede Menge Arbeit in xt:Commerce zu investieren ist, wenn er den eigenen Vorstellungen von Code-Usability und einem professionellen Aufbau genügen soll. Zumindest was den am Ende ausgelieferten Quelltext angeht. An der Grundstruktur Änderungen vorzunehmen würde bedeuten, den Shop komplett neu zu schreiben. Und das will ich mir (noch) verkneifen.

Das wird der Beginn einer Serie, denn wir haben für Wibros nicht nur Parkplatzabmahnung im Programm, sondern auch den ein oder anderen Online-Shop. Und die Entscheidung ist am Ende auf xt:Commerce gefallen, weil wie gesagt eine komplette Eigenentwicklung nicht sinnvoll erschien. Mal sehen, ob sich das am Ende rechnet.

Wer derweil schon mal ein paar Denkanstöße braucht, der kann sich im xt:C-Blog von nutzhosting.de umschauen, viele Tipps&Tricks hin zu semantischem und validem Code finden sich auch bei gunnART. Die Arbeit schon hinter sich haben die Macher vom Overkill Shop, auch wenn da unter semantischen Gesichtspunkten noch einiges verbesserungswürdig erscheint.

[tags]xtc, xt:commerce, xtcommerce, nightmare, standards, xhtml, css, choas[/tags]