Neues von der CeBIT 2013

Vergangenen Samstag ging wieder einmal die CeBIT in Hannover zu Ende. Ich hatte das Glück, dass ich dieses Jahr selbst dabei sein durfte.
Neben vielen neuen Technologien und Produkten wie z.B. der Vorstellung des neuen Microsoft Surface oder der De-Mail der Deutschen Post ging es bei der CeBIT dieses Jahr um das Leitthema „Shareconomy“. Neues von der CeBIT 2013 weiterlesen

VEYTON-Plugins mit eigenen Style-Dateien

In einem früheren Artikel habe ich bereits beschrieben, wie man VEYTON-Plugins mit eigenen Templates individuell anpassen kann. Heute soll es um ein paar Gedankenanstöße gehen, wie man das ebenfalls mit CSS-Dateien hinbekommen kann.

Leider ist das hier beschriebene Vorgehen nicht VEYTON-Standard für bereits existierende Plugins. Es geht vielmehr darum, wie man seine selbst entwickelten Plugins anpassbar machen kann. Um die im oben verlinkten Artikel beschriebene Funktionalität mit den individualisierbaren Template-Dateien zu erhalten, muss man nichts weiter tun, außer die Plugin-Templatedateien mit den VEYTON-Bordmitteln in das selbst entwickelte Plugin einzubinden …

Das Problem

… allerdings gehört meiner Meinung nach zu einem HTML-Template eben auch immer eine CSS-Datei. Wenn ich ein Plugin entwickle, habe ich zwei Anforderungen an das Layout:

  1. muss das Layout auch ohne größere Anpassungen funktionieren. Das Plugin muss sofort nach der Installation mit der integrierten Standard-Optik im Shop verwendbar sein.
  2. muss das Layout individuell an alle Anforderungen anpassbar sein. Wenn das Plugin in einem grafisch besonders anspruchsvollen Shop eingesetzt wird, muss es über HTML und CSS individuell anpassbar sein, ohne dabei seine Updatebarkeit zu verlieren.

Um dem ersten Punkt gerecht zu werden, ist es erforderliche, dass das Plugin von Haus aus ein HTML-Template und, bei Bedarf, ebenfalls eine CSS-Datei mit bringt. Doch was ist, wenn das HTML-Template individualisiert werden kann, die CSS-Datei aber nicht?
Das würde durchaus ein Problem darstellen. Stylesheet-Informationen, die keiner mehr braucht und niemand mehr zuordnen kann, zerstören evtl. unkontrolliert das Layout. Deshalb ist es wichtig, nicht nur die Standard-HTML-Datei, sondern ebenfalls die Standard-CSS-Datei des Plugins überschreiben zu können.

Die Lösung

Die von VEYTON standardmäßig integrierte Möglichkeit, VEYTON-Plugins mit eigenen Templates individuell anzupassen habe ich bereits mehrfach angesprochen. Und genau diese Variante wollen wir jetzt auch für die mitgelieferte CSS-Datei realisieren. Die Umsetzung ist ausgesprochen einfach und lässt sich mit nur einem einzigen Hook in der Installer-XML bewerkstelligen:

<?xml version="1.0" encoding="utf-8"?>
<xtcommerceplugin>
  <plugin_code>
    <code>
      <hook>styles.php:bottom</hook>
      <phpcode><![CDATA[
      if(file_exists($_SERVER['DOCUMENT_ROOT']._SRV_WEB._SRV_WEB_TEMPLATES._STORE_TEMPLATE.'/plugins/my_plugin/my_plugin.css')) {
        $cssfile = _SYSTEM_BASE_URL._SRV_WEB._SRV_WEB_TEMPLATES._STORE_TEMPLATE.'/plugins/my_plugin/my_plugin.css';
      }
      else {
        $cssfile = _SYSTEM_BASE_URL._SRV_WEB.'plugins/my_plugin/templates/my_plugin.css';
      }

      echo '<link rel="stylesheet" type="text/css" href="'.$cssfile.'" />';
      ]]></phpcode>
      <order>1</order>
      <active>1</active>
    </code>
  </plugin_code>
</xtcommerceplugin>

Wichtig ist, dass der Hookpoint styles.php:bottom verwendet wird. Dadurch wird gewährleistet, dass der erzeugte Code an der korrekten Stelle ins HTML geschrieben wird.

Im Hook selbst wird geprüft ob die Datei individualisierte Datei templates/myTemplate/plugins/my_plugin/my_plugin.css existiert. Ist dies der Fall, wird der Pfad zu dieser Datei in der Variable $cssfile gespeichert. Existiert die Datei nicht, wird der Pfad plugins/my_plugin/templates/my_plugin.css in der Variable gespeichert. Diese Datei ist die Standard-CSS-Datei, die das mit dem Plugin ausgeliefert wird.

Anschließend wird der <link>-Tag zum einbetten der gefunden CSS-Datei generiert und ausgegeben.

VEYTON-Plugins und individuelle Templates

Der Online-Shop VEYTON lässt sich durch Plugins erweitern und an die individuellen Anforderungen anpassen. Ebenso unterstützt VEYTON die optische Anpassung des Shops durch Template-Dateien. Hier zeige ich eine kurze Anleitung, wie sich Plugins ebenfalls über Templates optisch anpassen und verändern lassen.

Wir gehen in diesem Beispiel davon aus, dass der Shop mit dem imaginären Template myTemplate und dem imaginären Plugin my_plugin konfiguriert ist und wir jetzt die Ausgabe des Plugins an das gesamte Shop-Layout anpassen wollen.

Schritt 1
Wir legen das Verzeichnis templates/myTemplate/plugins/my_plugin im Dateisystem an.

Schritt 2
Wir öffnen das Verzeichnis plugins/my_plugin/templates auf dem Dateisystem.

Schritt 3
Wir kopieren den gesamten Inhalt des Verzeichnisses aus Schritt 2 in das bei Schritt 1 angelegte Verzeichnis.

Schritt 4
Wir passen die Dateien im Verzeichnis templates/myTemplate/plugins/my_plugin an die individuellen Bedürfnisse und das individuelle Layout des Shops an.

Wieso der Aufwand?

Evtl. fragen Sie sich jetzt, wozu der Aufwand gut sein soll, wo man doch die Plugin-Template-Dateien direkt im Verzeichnis templates/myTemplate/plugins/my_plugin bearbeiten kann und das gleiche Ergebnis erzielt.
Der große Unterschied liegt in der gewünschten Trennung von Inhalt, Layout und Funktionalität. Das ist nicht nur schlaues IT-Kauderwelsch, sondern eine sinnvolle Richtlinie bei der Umsetzung jeglicher Projekte. Durch das oben geschilderte empfohlene Vorgehen ist das Layout von der Funktionalität des Plugins getrennt. Das hat den enormen Vorteil, dass z.B. bei einem Plugin-Update das Layout innerhalb von myTemplate erhalten bleibt. Hätten wir die Änderungen direkt im Plugin vorgenommen, wären nach einer Aktualisierung alle Anpassungen wieder verschwunden und wir müssten mit unserer Arbeit von vorne beginnen.

VEYTON-Plugin „xt_coupons“ auf Zahlungsart-Seite einbinden

Das VEYTON-Plugin „xt_coupons“ bietet dem Shopkunden während des Checkouts die Möglichkeit, einen Gutschein einzugeben und somit die Möglichkeit, einen Rabatt auf die Bestellung zu aktivieren. Allerdings ist das Eingabefeld für den Gutschein-Code erst auf der letzten Seite des Checkouts sichtbar und nicht etwa, wie man es ggf. erwarten würde, auf der Seite mit den Zahlungsinformationen.

Mit wenigen Handgriffen lässt sich das Gutschein-Formular jedoch auf die Bezahl-Seite übertragen. Zunächst loggen wir uns als Administrator in den Admin-Bereich ein und navigieren zu „Inhalte > Plugin > installierte Plugins„. Dort öffen wir die Hookpoints des Plugins „Gutscheine/Kupons“ und suchen den Hookpoint „checkout_tpl_info„. Anschließend geben wir dem Hookpoint einen anderen Namen, wie z.B. „checkout_tpl_info_coupon„.

Als zweiten Schritt müssen wir den neuen Hookpoint auch noch im entsprechenden Template definieren. Dazu öffnen wir die Datei xtCore/pages/checkout/subpage_payment.html und fügen an der gewünschten Stelle den Hook-Aufruf ein. Für den oben vergebenen Hookpoint-Namen lautet der Code {hook key='checkout_tpl_info_coupon'}

Das Vorgehen hat leider einen kleinen Nachteil. Intern geht das Plugin noch immer davon aus, dass die Validierung und Verarbeitung der Eingabe auf der letzten Checkoutseite erfolgt. Gibt mal also einen Gutschein-Code ein, wird man auf die letzte Checkout-Seite weiter geleitet. Hier kann es aber sein, dass noch Informationen zum Checkout, wie z.B. die Wahl eines Zahlungsmoduls fehlen. Folglich wird man mit einer Meldung wieder auf die Zahlungs-Seite zurück geschickt.

VEYTON-Hooks: Shop oder Adminbereich?

Der Online-Shop VEYTON lässt sich durch das Hook-Konzept wunderbar erweitern. Doch die Hooks sind nicht sauber in Frontend- und Backend-Hooks getrennt. Einige Hooks werden sowohl vom Shop, als auch vom Adminbereich benutzt. Will man unterschiedliche Funktionen für Shop und Adminbereich realisieren, lässt sich ganz leicht im PHP-Script überprüfen, von wo aus der Hook aufgerufen wird.

Die PHP-Konstante USER_POSITION wird vom Adminbereich auf den Wert admin gesetzt und vom Shop auf den Wert store. Sollen also Aktionen entweder nur im Shop oder nur im Adminbereich ausgeführt werden, lässt sich das mit einer einfachen if-Anweisung regeln.

if(USER_POSITION == 'admin') {
	// do some action
}

if(USER_POSITION == 'store') {
	// do some action
}

VEYTON: Eigene Navigationspunkte im Admin-Tool

Was in VEYTON die Flexibilität und die Anpassungsmöglichkeiten des Shop-Frontends angeht, bin ich wirklich begeistert. Die Sache mit den Hook-Points ist einfach zu verstehen und extrem flexibel. Doch wenn es an die Anpassung des Admin-Bereichs geht, hört der Spaß auf. Das ist eine extrem undurchsichtige und lästige Angelegenheit. Inzwischen habe ich durch „trial and error“ herausgefunden, wie ich einen eigenen Navigationspunkt im Admin-Backend hinzufügen kann.

Die Lösung liegt in der Tabelle, die intern über die Konstante TABLE_ADMIN_NAVIGATION angesprochen wird. Vermutlich heißt diese Tabelle bei Euch xt_acl_nav oder acl_nav. Wenn nicht, könnt Ihr sie auf jeden Fall über die interne Konstante herausfinden. Bitte beachtet außerdem, dass die Reihenfolge, wie ich auf die Felder eingehen werde, nicht der Reihenfolge in der Datenbank entspricht, sondern für ein besseres Verständnis angepasst wurde.

text
Die eindeutige Bezeichnung des Navigationspunktes. Der Text kann dann selbstverständlich über die Lokalisierungstabelle an die jeweilige Sprache des Admin-Benutzers angepasst werden.

icon
Zu jedem Navigationspunkt gibt es neben dem Text auch das kleine Icon. Der Pfad muss relativ zum Verzeichnis xtAdmin sein und die Grafik sollte 16×16 Pixel groß sein.

navtype
Gibt an, in welche Navigation der neue Punkt integriert werden soll. Mögliche Werte sind N und W. Vermutlich steht das für „North“ und „West“. Denn schließlich kann man mit N einen Button in der oberen Navigationsleiste neben „Handbuch“, „Helpdesk“, etc. ablegen, während man mit W einen Navigationspunkt in der linken Hauptnavigation erzeugt.

type
Wenn navtype=W angegeben wurde, kann der Typ auf den Wert G oder I gesetzt werden. G enthält weitere Unterpunkte und könnte von „Group“ abgeleitet worden sein. I enthält keine weitere Unterpunkte, sondern ist selbst der letzte Unterpunkt einer Gruppe, die Bezeichnung könnte von „inner“ abgeleitet worden sein.
Für navtype=N muss der Wert G eingetragen werden.

parent
Für navtype=W zeigt das Feld an, welchem Elternelement der Navigationspunkt zugeordnet worden sein. Das Elternelement muss vom type=G sein. Wird hier der Wert 0 eingetragen, wird in der Navigation ein komplett neuer Block angelegt. Um das neue Navigationselement in eine vorhandene Gruppe einzugliedern, muss deren bei text eingetragene Bezeichnung hier hinterlegt werden.
Für navtype=N muss der Wert 0 eingetragen werden.

sortorder
Ein einfacher Sortierungswert als Integer. Niedrige Werte werden zuerst dargestellt, höhere Werte danach.

Erfahrungen mit VEYTON

Seit einiger Zeit gibt es mit VEYTON den kostenpflichtigen Nachfolger des Open-Source-Shops von xt:Commerce. Inzwischen habe ich einige Erfahrung mit der Konfiguration des Shop und der Entwicklung von Erweiterungen gesammelt. Zeit für ein erstes Resümee.

Meine erste Befürchtung war, ein proprietärer Shop könnte evtl. weniger anpassbar an individuelle Kundenwünsche sein, als eine Open-Source-Version. Ich war also eher skeptisch ob sich VEYTON wirklich durchsetzen kann, gerade dann wenn ein Shop nicht von der Stange kommen darf, sondern individuell an die Wünsche der Kunden angepasst werden muss.

Im alten xt:Commerce konnte (bzw. eher musste) man jede Änderung, jede Indiviudualisierung am Kern des Projekts durchführen. Selbst Module, die theoretisch nachrüstbar waren wie z.B. Versand- oder Bezahlmodule erforderten oftmals einen Eingriff in den Shop-Code.

Ganz anders verhält sich die Sache bei VEYTON. Die Entwickler haben ein cleveres System entwickelt, mit dem Plugins extrem einfach installiert und ohne großen Aufwand auch wieder deinstalliert werden können. Nicht zuletzt das Konzept der Hookpoints hat mich überzeugt. Über diese Hookpoints kann man in nahezu jeder Funktion des Shops eigenen PHP-Code einschleusen. Wird das Plugin entfernt, verschwindet auch der Zusatzcode. Auch Sprachvariablen, Konfigurationsoptionen, Admin-Tools, etc. lassen sich per Plugin nachrüsten und bei Bedarf gemeinsam mit dem Plugin wieder sauber entfernen.

Lediglich die Dokumentation der Schnittstellen, Templatefunktionen und Hookpoints lässt stark zu wünschen übrig. Oftmals hilft an dieser Stelle eine gezielte Suche im Source-Code. Da dieser aber teilweise compiliert ist, bleiben wohl einige Features und Konfigurationsmöglichkeiten vorerst unentdeckt.

Auf jeden Fall ist den VEYTON-Entwicklern eine gute Arbeit zu bescheinigen. Ich bin begeistert vom neuen Plugin-System, während die Anpassung des alten xt:Commerce-Shops oftmals qualvoll war. Und vielleicht kommt ja irgendwann auch eine ordentliche Entwickler-Dokumentation, die mir mein Leben noch weiter erleichtert.

Magento vs. xt:Commerce Enterprise

Nachdem das Shopsystem „Magento Commerce“ der Firma Varien in den vergangenen Monaten, mit einer extrem sauber programmierten Grundstruktur, dem bekannten xt:Commerce den Rang abgelaufen hat, möchte XT nicht ins Aus befördert werden und trotzt dem Angriff, mit der Ankündigung auf die neue Enterprise Serie.

Nach fast 5 Jahren wird der xt:Commerce Gemeinde nun endlich ein leistungsfähiges Pendant geboten, Magento ist im Anmarsch, momentan jedoch nur bedingt einsatzfähig, da ein gut performanter Server (virtuelle Hosts sind hier zur Zeit gänzlich ungeeignet) die Voraussetzung sein sollte. Genau hier will xt:Commerce ansetzen und kontern. Die xt:Serie „Enterprise“ wird momentan entwickelt und befindet sich in der Betaphase.

Anders als bei Magento wird die Enterprise Serie jedoch Lizenzgebühren beanspruchen, da es nicht mehr der General Public License unterliegen wird.

Vorerst wird Magento an seiner größten Schwäche gepackt – der Perfomance.  xt:Commerce möchte weiterhin seine hohe Geschwindigkeit mit einem schlanken Design sowie einem speziell entwickelten Framework, gewährleisten. So ist die Installation anders als Magento weiterhin auch bei Hosting-Paketen möglich.

Die modern gestaltete Admin-Oberfläche, die durch Verwendung des extJS Frameworks einer Desktopanwendung gleichen soll, sieht vielversprechend aus.

Zudem soll das Core System nun auch unabhängig der Plugins gehalten werden. Klarer Vorteil: Das System kann schnell und einfach auf neue Versionen geupdatet werden, da Funktionen und Klassen verändert werden können ohne die Dateien das eigentlichen System zu „verbiegen“.

Fazit: Die Zeit wird zeigen, wie schnell Magento auf die genannten Performance Probleme reagiert, bzw. wie die „Final“ -Version von xt:Commerce Enterprise aussehen wird.
http://www.xt-commerce.com/blog/xtcommerce-news/xtcommerce-enterprise-beta-test.html