Letzte Aktualisierung: 23.09.2010

Dieser Artikel bezieht sich im wesentlichen auf die umfangreichen technischen Neuerungen in Shopware 3.5.0.

Für eine Übersicht über die weiteren geplanten Funktionen und Bugfixes besuchen Sie die Roadmap-Seite zum Release.

• Migration Guide 3.0.x > 3.5.0
• Preview 3.5.0
• Standard Komponenten 3.5.0
• Roadmap / Hauptseite 3.5.0
• Informationen zur 3.5.0 Preview-Version (ab 01.10.2010)

Shopware 3.5 wird mit einem komplett neuen Standard-Frontend ausgeliefert, welches neue Maßstäbe im Bereich Usability setzen wird und auf die derzeit modernsten, verfügbaren Webstandards setzt. Insgesamt wird es im Auslieferungszustand 10 Themes des Standardtemplates geben. Die technischen Neuerungen werden auf den nachfolgenden Seiten genauer erklärt.

Alle Screenshots lassen sich per Mausklick vergrößern

Shopware 3.5.0 wird als letztes von insgesamt 10 Minor-Releases die Entwicklungslinie 3.x abschließen. Um die spätere Migration auf die in 2011 erscheinende Shopware 4 zu erleichtern, werden bereits wesentliche technische Bestandteile der neuen Version integriert.

Der Hauptfokus bei der Entwicklung von 3.5.0 ist das neue Plugin-System. Dadurch wird es möglich, den Kern der Applikation schnell und effizient zu halten und zusätzliche Funktionalität in Form einfach integrierbarer Plugins bereitzustellen. Zum Deployment eigener Plugins steht in Kürze unserer CommunityStore bereit. Hier wird man auf zahlreiche Erweiterungen aus allen eCommerce-Bereichen zugreifen können, die sich einfach per One-Click-Install installieren lassen.

Shopware setzt ab Version 3.5.0 auf Enlight bzw. das Zend-Framework als technische Basis, das ermöglicht allen Entwicklern, die bereits mit Magento oder dem Zend-Framework gearbeitet haben einen einfachen Einstieg in die Programmierung mit Shopware.

Der Kern des Zend-Frameworks wurde hierbei in Form von "Enlight" vollständig neu entwickelt, dadurch bieten wir in Vergleich zu anderen ZF basierenden eCommerce-Lösungen einen sehr schnellen und ressourcensparenenden Kern und ein äußert flexibles Plugin-System. Getreu dem Motto "Convention over configuration" verzichten wir weitestgehend auf die umständliche Konfiguration von Template- und Plugin-Parametern in XML-Dateien. Durch die gute Dokumentation, die flache Lernkurve und den logischen und intuitiven Aufbau, ist die Einarbeitung in die Shopware-Entwicklung schnell umgesetzt.

Vorteile die sich durch das neue System ergeben:

• Features können unabhängig von den Release-Zyklen, in Form von Plugins, jederzeit zur Verfügung gestellt werden
• Individuelle Anpassungen lassen sich komplett updatefähig integrieren
• Template-Änderungen sind schneller und einfacher umzusetzen
• Mehrere Plugins können die selbe Funktionalität erweitern
• Der eigentliche Core wird wesentlich schneller und einfacher zu warten, da Zusatzfunktionen ausgelagert werden
• Flache Lernkurve durch ZF konforme Syntax
• "Best practice" Orientierung und State of the art Technologie

Weitere Informationen zu den Änderungen finden Sie auf den nachfolgenden Seiten

Enlight ist Teil der technischen Neu-Ausrichtung der shopware AG. Mit diesem hochperformanten Framework wird die Entwicklung moderner Web-Applikationen deutlich vereinfacht. Die grundlegende Syntax orientiert sich am Zend-Framework, so dass ZF-Entwickler problemlos auch in die Shopware Entwicklung einsteigen können. Außerdem können alle bestehenden Zend-Framework Komponenten in Shopware genutzt werden.

Klicken Sie hier für weitere Informationen zu Enlight.

Das sogenannte "MVC-Prinzip" oder auch "Model-View-Controller-Prinzip" ist ein Architekturmuster zur Separierung von Software in drei Programmschichten. Ziel dieses Musters ist es flexiblen Programmcode zu erstellen, welcher spätere

Änderungen oder Erweiterungen erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten der Software zulässt.

"Model" - das Datenmodell' Das Model enthält die darzustellen Daten und gegebenenfalls auch Teile der Geschäftslogik der Applikation. Es ist komplett unabhängig von der Präsentation ("View") und der Steuerung ("Controller"),

'"View" - die Präsentation Die Präsentationsschicht ist für die Darstellung der benötigten Daten aus dem Modell und der Entgegennahme der Benutzerinteraktionen zuständig. Die View kennt sowohl den Controller als auch das Model, ist aber nicht für die Weiterverarbeitung der vom Benutzer eingegebenen Daten zuständig.

"Steuerung" - Der Controller Die Steuerung verwaltet die allgemeine Geschäftslogik der Applikation und nimmt die Benutzerinteraktionen aus dem View entgegen. Die Verarbeitung der Daten übernimmt hier aber nicht die Steuerung, sondern das Model.

Mit der neuen Version sind die beiden Ordner "Enlight" und "Shopware" im Ordner "engine" hinzugekommen. Im Enlight-Ordner liegen die verwendeten Frameworks und die genutzten Dritt-Bibliotheken. Im Shopware-Ordner liegen alle neuen Klassen und Ordner, die Shopware ab Version 3.5.0 verwendet. Die Controller, die die alten Viewports ersetzen, befinden sich beispielsweise im Ordner "engine/Shopware/Controller". Mit Erscheinen von Shopware 4.0, wird die alte Ordner-Struktur im Engine-Verzeichnis vollständig durch das Verzeichnis "Shopware" ersetzt.

engine/Enlight /
|-- Collection > Object / Array Mapper wird z.B. in der Konfiguration benutzt
|-- Controller > Controller Library (Front-Controller / Dispatcher / Request / Response / Router)
|-- Components > Enlight Komponenten (Aufbauend auf ZF)
|-- Event > Event-Manager 
|-- Helper > Helper-Klassen für Template - Objekte (Bereitstellung von $this-> im Template)
|-- Hook > Überschreiben von Core/Applikationsklassen und einzelner Methoden (Teil des Plugin-Systems)
|-- Plugin > Plugin-Manager
|-- Template > Smarty - Erweiterungen
|-- View > Standardmäßig bereitgestellte View-Objekte
|-- Zend > Eigene Zend-Framework Erweiterungen

engine/Shopware /
|-- Controllers > Hier werden die Standard-Controller hinterlegt (Ersetzen Viewports)
|   |-- Frontend > Frontend-Controller
|   |-- Backend > Backend-Controller
|-- Components > Systemkomponenten (z.B. Konfiguration, Textbausteine etc.)
|-- Models > Daten-Modelle
|-- Plugins
|   |-- Default - Standard Core - Plugins von Shopware
|   |-- Community - Plugins aus dem Community-Store
|   |-- Local - Plugins aus dem lokalen Namespace (Eigene Erweiterungen)
|-- Proxies > Ordner der Proxy-Klassen für das Hook-System 
|-- Bootstrap.php > Klasse zum Verwalten der Ressourcen
|-- Shopware.php
|-- Subscriber.php > Klasse zum Verwalten von Hooks, Events und Blöcken

engine/backend / Enthält die Backend-Dateien / Module |-- ajax - Helper-Scripte für Ajax-Aufrufe im Backend |-- css - CSS-Styles des Backends |-- elements - Template für Backend-Fenster |-- img - Grafiken Backend |-- js - Javascript Backend |-- modules - Backend Module |-- php - Backend - Klassen / Hilfsscripte |-- plugins - Ältere Mootools Erweiterungen

Der engine\backend Ordner enthält größtenteils veraltete Module, die mit Shopware 4.0 vollständig neu umgesetzt werden. Die bereits umgesetzten, neuen Backend-Module findet man unter Shopware\Controllers\Backend.

Shopware 3.5.0 wird eine komplett neue Template-Basis auf Basis von Smarty 3, 960gs und jQuery 1.4.2 als Javascript Bibliothek enthalten. Designer und Entwickler profitieren von den vielen neuen technischen Möglichkeiten und der übersichtlicheren Struktur der neuen Template-Basis. Alle Shopbetreiber profitieren von einer investionssicheren, soliden Basis - die konsequent, alle derzeit zur Verfügung stehenden, technischen Möglichkeiten ausnutzt.

Die Namensgebung der Templates hat sich im Vergleich zu früheren Versionen geändert. Die einzelnen Templates sind nicht mehr numerisch per ID benannt sondern mit einem eindeutigen Namen. Das Standardtemplate, welches wir mit Shopware 3.5.0 ausliefern, hat beispielsweise den Ordernamen "default".

Der Ordner "html" wurde durch den Ordner "frontend" abgelöst, hier befinden sich nun alle Template-Dateien der Storefront. Die jeweiligen Unterordner sind nach den Controllern benannt, die das Template verwenden bzw. aufrufen. Um eine Kompatibilität zur alten Template-Basis herzustellen, haben wir ja einen Layer integriert. Dieser sorgt dafür, dass bei der Verwendung von Templates älterer Versionen, automatisch auf die bestehenden Viewports zurückgegriffen wird.

Beispiel Controller / Template - Verknüpfung Die Artikeldetailseite wird über den Controller "detail" aufgerufen. Somit befindet sich die Template-Datei im Verzeichnis /templates/frontend/detail/index.tpl

Einen Sonderfall stellt der Ordner "widgets" da. In diesem Ordner befinden sich zum Beispiel die Boxen der Zahlungsarten und andere Template-Bestandteile die universell und unabhängig von einem bestimmten Controller eingesetzt werden. Hierzu zählen zum Beispiel die Tagcloud, die Topseller, das Trusted Shops Logo usw.

Im neuen Template wurde der Ordner "media" durch den neuen Ordner "resources" abgelöst. Hier werden nun zentral alle Scripts und Stylesheets der Anwendung gespeichert. In den Ordnern "styles" und "javascript" befindet sich jeweils ein zusätzlicher Ordner mit der Bezeichnung "plugins". Hier können Sie Ihre eigenen Script- und Stylesheet Erweiterungen unterbringen.

In Shopware 3.5.0 haben wir MooTools durch jQuery ersetzt. jQuery ist eine von John Resig entwickelte, frei verfügbare Javascript Bibliothek.

Durch die Verwendung von jQuery bieten wir Ihnen im Vergleich zu MooTools eine flachere Lernkurve und eine intuitivere Syntax an, wodurch Sie schneller und effizienter Anpassungen umsetzen können. Durch die hohe Beliebtheit von jQuery stehen Ihnen tausende frei verfügbare Plugins zur Verfügung, auf die Sie bei der Anpassung Ihres Shops zurückgreifen können.

Auch als erfahrener Entwickler bietet Ihnen jQuery wesentliche Vorteile. D urch die verwendete Selektor-Engine Sizzle steht Ihnen ein mächtiges Werkzeug zur DOM-Manipulation zur Verfügung, welches jetzt schon die kommenden CSS3-Selektoren unterstützt.

Merkmale

• Elementselektion im DOM mittels Sizzle
• Intuitive DOM-Manipulation
• Ein erweiterteres Event-System
• Hilfsfunktionen wie hasClass() oder die each-Funktion
• Konfigurierbare Effekte und Animationen
• Umfangreiche Ajax-Funktionalität
• Tausende frei verfügbare Plugins
• Eine beliebige Erweiterbarkeit durch das jQuery Plugin-System

Shopware Plugins für jQuery

Wir haben die gesamte Javascript Funktionalität der Shopware Storefront von MooTools nach jQuery adaptiert und in Plugin-Form umgesetzt. Dadurch können Sie die Standard Shopware-Komponenten, wie z.B. die Suggest-Suche nun sehr einfach und updatekompatibel erweitern.

Sind meine bestehenden MooTools Erweiterungen auch noch mit jQuery kompatibel?

jQuery bietet Ihnen speziell für diesen Fall einen sogenannten "No Conflict"-Modus, der es Ihnen erlaubt jQuery in Verbindungen mit jeder anderen Javascript Bibliothek zu nutzen. Um jQuery mit MooTools zu nutzen inkludieren Sie erst MooTools und dann jQuery. Jetzt müssen Sie nur noch folgenden Code-Block in Ihr Template integrieren:

 
$.noConflict();
jQuery.(document).ready(function($) {})
 

So können Sie Ihre bestehenden Mootools-Erweiterungen problemlos weiter verwenden.

Im Lieferumfang von Shopware 3.5.0 befindet sich ein vollständiges CSS-Framework, welches Ihnen viele Vorteile im Vergleich zur Vorgängerversion von Shopware bietet. Hierzu zählt die Verwendung eines Grid-/Rastersystems, eines Resets sowie zahlreiche vordefinierte Klassen, welche Sie für Ihr eigenes Template verwenden können.

Als Basis verwenden wir eine angepasste Version des CSS-Frameworks "960gs". Dieses Framework führt eine Reihe von Rastern und Positionierungsklassen ein, die eine einfache Ausrichtung der Content-Elemente im Browser ermöglichen. Ein Rastersystem können Sie sich wie eine Überlagerung von mehreren Spalten über die gesamten Seite vorstellen, womit Sie die einzelnen HTML-Elemente nach diesem Raster ausrichten können.

Das in Shopware verwendete Raster basiert auf insgesamt 20 Spalten, wobei jede Spalte eine Breite von 30 Pixeln hat. So erreichen wir eine Gesamtbreite von 1000 Pixeln, mit einem nutzbaren Content-Bereich von 980 Pixeln Die jeweiligen Breiten Ihrer Container wird über die Klasse "grid_n" gesteuert.

Eine komplette Liste der verschiedenen Breiten finden Sie im folgenden Bild:

Das Rastersystem bietet Ihnen weiterhin den Vorteil dass Sie Container per push_n nach links oder pull_n nach rechts verschieben können und einen Abstand nach links per prefix_n oder einen Abstand nach rechts per suffix_n umsetzen können.

Informationen:

• Spalten: 20
• Spaltenbreite: 30 Pixel
• Abstand zwischen den Spalten: 10 Pixel
• Komplette Breite: 1000 Pixel
• Content Breite: 980 Pixel

Verfügbare Klassen:

• grid_n - Breite der jeweiligen div-Box
• push_n - div-Box Verschiebung nach links
• pull_n - div-Box Verschiebung nach rechts
• prefix_n - div-Box Abstand nach links
• suffix_n - div-Box Abstand nach rechts
• first - Hebt den Freiraum der div-Box nach links auf
• last - Hebt den Freiraum der div-Box nach rechts auf

Verfügbare Breiten

• 1 - 30 Pixel
• 2 - 80 Pixel
• 3 - 130 Pixel
• 4 - 180 Pixel
• 5 - 230 Pixel
• 6 - 280 Pixel
• 7 - 330 Pixel
• 8 - 380 Pixel
• 9 - 430 Pixel
• 10 - 480 Pixel
• 11 - 530 Pixel
• 12 - 580 Pixel
• 13 - 630 Pixel
• 14 - 680 Pixel
• 15 - 730 Pixel
• 16 - 780 Pixel
• 17 - 830 Pixel
• 18 - 880 Pixel
• 19 - 930 Pixel
• 20 - 980 Pixel

Zusammenfassung

1. Verwenden Sie die container_20 Klasse als Container bzw. Elternelement für alle anderen Elemente in Ihrem Layout. Diese Klasse ist die Grundlage des Rasters.

2. Nutzen Sie die Klassen grid_1, grid_2, grid_3, etc. um die Spaltenbreiten festzulegen. Möchten Sie die gesamte Breite nutzen verwenden Sie bitte grid_20

3. Verwenden Sie die push und pull Klassen um Elemente unabhängig auf Ihrer Seite zu positionieren, egal an welcher Stelle das Element im HTML-Markup hinterlegt ist.

4. Nutzen Sie die Klassen first und last um den Spaltenabstand bei verschachtelten Elementen aufzuheben.

Weitere Informationen zum 960 Gridsystem finden Sie auf der Projekthomepage -

http://960.gs/

Ein altbekanntes Problem ist die unterschiedliche Behandlung von CSS-Formatierungen in verschiedenen Browsern. Dies liegt hauptsächlich an den Standard-Formatierungen, die in den Browser-Engines für die verschiedenen HTML-Elemente definiert worden sind. Bei kleineren Seiten führt dies nicht zwangsläufig zu einem Problem. Problematisch wird dieses Verhalten aber, wenn Sie komplexere, modular aufgebaute CSS-Designs verwenden, welche möglicherweise verschiedene externe CSS-Dateien miteinander kombinieren. Abhilfe schafft hier ein CSS-Reset, welcher alle Standardeinstellungen der jeweiligen Browser komplett zurücksetzt. Shopware beeinhaltet in der Version 3.5.0 einen CSS-Reset mit, der Ihnen bei der Gestaltung und Programmierung von Browser unabhängigen Designs zur Verfügung steht. Der CSS-Reset basiert auf dem beliebten YUI 2: Reset CSS von Yahoo!. Um bereits perfekt für HTML 5 gerüstet zu sein, beachten wir bei dem Reset auch die neuen, kommenden HTML5-Elemente.

Folgende HTML5-Elemente sind enthalten:

• article
• aside
• canvas
• details
• figcaption
• figure
• footer
• header
• hgroup
• menu
• nav
• section
• summary
• time
• mark
• audio
• video

Um Ihnen eine Grundlage für Ihr Shopware Storefront Design zu geben, stellen wir Ihnen ein CSS-Framework zur Verfügung, welches fast allen HTML-Elementen eine einheitliche Formatierung verpasst. Hinzu kommen sogenannte "User Response Elements", welche Sie verwenden können um bestimmte Informationen im Shop (z.B. erfolgter Logout) deutlich hervorzuheben.

Durch die vordefinierten Stile haben Sie die Möglichkeit neue Designs und Layouts zu erstellen, ohne weitere Änderungen am eigentliche CSS-Code vorzunehmen. Hier eine Liste der wichtigsten HTML-Elemente mit vordefinierten

Formatierungen:

Vordefinierte HTML-Elemente

• p - Paragraph
• a, a:hover, a:focus - Hyperlinks mit deren Pseudoklassen
• ul, ol , li - unsortierte und sortierte Listen
• table, thead, tbody, tfoot, tr, td, th - Tabellen und deren Elemente
• input, button, textarea, fieldset, legend - Formularelemente
• hr - Horizontale Linie
• h1, h2, h3, h4, h5, h6 - Überschriften
• dl, dd, dt - Definitionslisten
• pre, code - Codeteile
• blockquote - Zitate
• strong, em - Textformatierung

Hierzu kommen folgende weitere Klassen die Sie auf HTML-Elemente anwenden können um die Formatierung direkt im HTML-Markup zu steuern.

Weitere Klassen für die Formatierung

• small - kleiner Text
• large - großer Text
• hide - Element ausblenden
• quiet - Kontrast des Texts verringern
• highlight - Textteile hervorheben
• alt - alternative Schriftart
• error, notice, success - User Response Klassen
• text - Setzt eine Standardgröße für Input Elemente
• top - Entfernt margin-top und padding-top
• bottom - Entfernt margin-bottom und padding-bottom

Durch die Kombination des Rastersystems, CSS-Reset und CSS-Frameworks erhalten Sie mit Shopware 3.5.0 eine perfekt aufeinander abgestimmte Template-Basis, welche Ihnen viel Zeit, Geld und Code spart.

Erstellen von User Response Elements

Die Erstellung eines User Response Elements gestaltet sich einfach. Sie haben die Wahl zwischen 3 Typen der Benachrichtigungen. Folgende Typen stehen Ihnen zur Auswahl:

• error - Fehlermeldung
• notice - Allgemeine Benachrichtigung
• success - Erfolgreiche Benachrichtigung

Wenn wir dem User beispielsweise eine positive Meldung für den erfolgreichen Logout geben wollen, dann würde der Code für die Box wie folgt aussehen:

 
<div class="success">
    <p>
        Sie wurden erfolgreich ausgeloggt.
    </p>
</div>
 

Durch die Verwendung von Smarty 3 als Templating Engine ist ab sofort eine Vererbung von Templatedateien möglich. Sie haben die Möglichkeit Blöcke in Ihren Template zu definieren, welche dann von einem übergeordneten Template überschrieben werden können. Ein Beispiel:

parent.tpl:

 
<html>
  <head>
    <title>{block name='title'}My site name{/block}</title>
  </head>
  <body>
    <h1>{block name='page-title'}Default page title{/block}</h1>
    <div id="content">
      {block name='content'}
        Default content
      {/block}
    </div>
  </body>
</html>
 

child.tpl:

 
{extends file='parent.tpl'} 
{block name='title'}
    Child title
{/block}
 

In diesen Beispiel haben wir ein Eltern-Template "parent.tpl", wo die gerade erwähnten Blöcke definiert worden sind. In diesem Fall wurden zwei Blöcke mit den Namen "title" und "content" angelegt. Um diese Blöcke im Child-Template "child.tpl" zu überschreiben veranlassen wir durch {extends file="..."} eine Vererbung des Eltern-Templates "parent.tpl". Jetzt können wir die vorher definierten Blöcke durch Aufruf von {block name="..."}…{/block} ersetzen.

Im neuen Shopware Template wurden eine Vielzahl solcher Blöcke definiert, so dass eine höchstmögliche Flexibilität gegeben ist. Die Hauptblöcke für das 3-spaltige Layout sind "content_left" für die linke Sidebar, "content" für die mittlere Hauptspalte (der eigentliche Inhaltsbereich) und der Block "content_right", welcher die rechte Sidebar repräsentiert.

Das Haupttemplate, welches das komplette Layout der Storefront widerspiegelt befindet sich im Ordner "frontend/index/index.tpl", hier können Sie alle global zur Verfügung stehenden Blöcke einsehen. Um zum Beispiel ein neues Template für einen neuen Controller zu erstellen, erben Sie einfach die Eigenschaften des Haupt-Templates (index.tpl) und ersetzen die Blöcke, die Sie modifizieren möchten, mit dem neuen Inhalt.

Beispiel: Template-Datei für Controller blog soll rechte Spalte ausblenden

Datei: /default/frontend/blog/index.tpl

 
{extends file='../index/index.tpl'}
{block name="content_right"}
{/block}
 

Darüber hinaus haben wir darauf geachtet, dass die Templates modular aufgebaut sind. Dies bietet Ihnen bei späteren Anpassungen über Plug-Ins den Vorteil, dass Sie in den eigentlichen Template-Dateien keine Änderungen vornehmen müssen, um nicht benötigte Teile auszubauen oder neue Teile einzubauen.

Das neue Block-System ist somit die ideale Ergänzung zur bestehenden Template-Vererbung und ermöglicht eine noch wesentlich filigranere Anpassung des Templates.

In diesen Beispiel sehen Sie, dass wir einen Block mit der Bezeichnung "topbar" definiert haben. Im Template "parent.tpl" wird in diesem Block eine Auswahl von Ländern und Währungen dargestellt. Wenn man jetzt auf das Template "child.tpl" wechselt, kann man den Block "topbar" in "child.tpl" überschreiben, da "child.tpl" die Properties von "parent.tpl" erbt.

So könnte man nun zum Beispiel ohne Anpassungen am Haupttemplate, mit wenigen Zeilen Code, Social-Media Bookmarks in das Template integrieren.

In der neuen Template-Basis von Shopware haben wir das Textbausteinsystem grundlegend verändert. Textbausteine sind Textteile, die mit einem eindeutigen Key und dem eigentlichen Inhalt in der Datenbank gespeichert werden. Mit der neuen "Snippet-Engine" können Sie z.B. Textbausteine direkt im Template anlegen, ohne in das Backend wechseln zu müssen. Außerdem wurde ein lokaler Namespace für alle Textbausteine definiert. Das bedeutet, dass sich die Textbausteine automatisch in den Templates organisieren, in denen sie definiert werden.

Einen neuen Textbaustein anlegen

Um einen neuen Textbaustein im Template anzulegen ist folgende Syntax relevant:

 
{s name="NAME DES TEXTBAUSTEINS"}
    INHALT DES TEXTBAUSTEIN
{/s}
 

Als Vorbereitung auf Shopware 4, können Textbausteine alternativ mit dem {se} Tag definiert werden. Hierdurch werden diese als "editable" markiert und können später Live im Frontend editiert werden.

 
{se name="NAME DES TEXTBAUSTEINS"}
    INHALT DES TEXTBAUSTEIN
{/se}
 

Sie haben auch die Möglichkeit einen neuen Textbaustein anzulegen, ohne einen eindeutigen Namen definieren zu müssen.

 
{s}INHALT DES TEXTBAUSTEIN{/s}
 

So ist der Inhalt gleichzeitig der Key des Bausteins. Besser ist es aber natürlich, wenn Sie eindeutige Keys hinterlegen.

Weitere Parameter bei der Erstellung der Textbausteine'

Es gibt eine Reihe weiterer Paramter, die Sie bei der Gestaltung Ihrer Textbausteine verwenden können. Falls Sie beispielsweise den Inhalt eines Textbausteins in einem P-Tag ausgegeben lassen wollen, können Sie folgende Syntax verwenden:

 
{s name="NAME DES TEXTBAUSTEINS" tag="TAGNAME" class="KLASSE DES TAGS"}
    INHALT DES TEXTBAUSTEIN
{/s}
 

Hier ein konkretes Anwendungsbeispiel:

 
{s name="Testtext" tag="p" class="bold"}
     Ich bin der Inhalt
{/s}
 

Die Ausgabe des Beispiels wäre folgende:

 
<p class="bold">
    Ich bin der Inhalt
</p>
 

Die Textbausteine können auch mit der Smarty-Modifier Syntax verwendet werden

 
{"INHALT DES TEXTBAUSTEINS"|snippet:"NAME DES TEXTBAUSTEINS"}
 

Über den Parameter force="true" können Sie den Inhalt des Textbausteins in der Datenbank überschreiben, ohne in das Backend wechseln zu müssen.

 
{s name="NAME DES TEXTBAUSTEINS" force=true}
    NEUER INHALT
{/s}
 

Durch den Auto-Loader werden alle benötigten Klassen automatisch in die Applikation eingebunden. Es entfallen also etwaige manuelle Require/Includes.

So werden die Klassen nur dann und nur zu dem Zeitpunkt geladen, wo diese tatsächlich benötigt werden. Der Name der Klasse entspricht hierbei immer dem Verzeichnis in dem die Klasse gespeichert ist, die Klasse "Shopware_Models_Order" liegt demnach in der Datei /Shopware/Models/Order.php.

Beispiel

Klasse: Shopware_Models_Order Dateipfad: /Shopware/Models/Order.php

$order = new Shopware_Models_Order(id); $order->_postions->getArrayCopy();

Standardmäßig werden nur Klassen aus dem Enlight-/Shopware-Ordner unterstützt. Weitere Ordner können über die Methode „registerNamespace“ hinzugefügt werden.

Beispiel für das Zend-Framework (Standardmäßig eingebunden)

 
Shopware()->Loader()->registerNamespace('Zend', Shopware()->VendorPath('Zend')); 
 

Im Bootstrap können häufiger verwendete Ressourcen definiert werden. Ressourcen sind bespielsweise die Datenbank-Verbindung, Smarty, PHPMailer oder auch Plugins wie die Shopware Api. Der Boostrap ist eine Klasse im Applikationsverzeichnis (engine/Shopware) die automatisch initialisiert wird. Sofern auf eine Ressource zugegriffen wird, wird diese automatisch eingebunden und initialisiert. Dazu wird in der Boostrap-Klasse eine Methode mit dem Namensschema „initResourcenName“ aufgerufen. Die Methode gibt entsprechend eine Referenz auf das Resources-Objekt zurück.

Beispiel für das Initialisieren mit einer Methode im Bootstrap

 
protected function initZendMailer()
{
	$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
	  'auth'     => 'login',
	  'username' => 'foo',
	  'password' => 'bar',
	  'ssl'      => 'ssl',
	  'port'     => 465,
	));
 
	$mailer = new Zend_Mail();
	$mailer->setDefaultTransport($transport);
	return $mailer;
}
 

Beispiel für das Registrieren einer Ressource

 
$mailer = new Zend_Mail();
//...
Shopware()->Boostrap()->registerResource('ZendMailer', $mailer);
 

Beispiel für Aufrufen einer Ressource

 
$mailer = Shopware()->Boostrap()->getResource('ZendMailer');
 

Oder kürzer

 
$mailer = Shopware()->ZendMailer();
 

Alle Anfragen werden ab Shopware 3.5.0 zentral über den so genannten Front-Controller abgewickelt (vormals shopware.php). Dieser delegiert die Anfragen dann an die entsprechenden Action-Controller weiter. Außerdem steuert er die Ein-/Ausgabe über die Request-/Response-Objekte.

Im Folgenden können Sie einen Auszug der Methoden der Request-/Response-Objekte sehen. Diese stammen aus dem Zend-Framework, enthalten also alle Methoden und Properties dieser Komponente.

Request

Die Anfrage eines Client an den Server. So sendet zum Beispiel der Browser eines Users einen Request an den Server, wenn der Besucher einen Download-Link anklickt. Der Server prüft danach im Filesystem, ob die angeforderte Datei vorhanden ist. Wenn dies der Fall ist, schickt er eine Kopie der Datei als Response zurück an den Browser. Ansonsten wird ein Fehlercode geliefert, der eine entsprechende Fehlermeldung des Browsers initiiert.

• setParam($spec, $value = null) - Parameter setzen
• getParam($key, $default=null) - Parameter auslesen
• setPost($spec, $value = null) - Post-Parameter setzen
• getPost($key = null, $default = null) - Post-Parameter auslesen
• isSecure() - SSL-Anfrage erkennen
• isXmlHttpRequest() - Ajax-Anfrage erkennen
• getHeader($header) - Http-Header abfragen

Response

Die Antwort des Servers an den Client zu einer Anfrage (Request).

• setHeader($name, $value, $replace = false) - Http-Header setzen
• setBody($content, $name = null) - Ausgabe setzen
• appendBody($content, $name = null) - Ausgabe hinzufügen

Beispiel für das Setzen eines Http-Headers

 
$front->Response()->setHeader('Content-Type', 'application/json', true);
 

Beispiel für das Auslesen eines Post-Parameters

 
$postID = $front->Response()->getPost('postID');
 

Der View ist die Präsentationsschicht der Anwendung. Es nimmt Daten aus dem Action-Controller entgegen und übergibt diese an das Template. Das Template erzeugt dannn die Ausgabe.

Die wichtigsten Methoden des View-Objekts:

• setTemplateDir($path) - Template-Verzeichnis einstellen
• addTemplateDir($path) - Template-Verzeichnis hinzufügen
• setTemplate($template) - Template-Datei setzen
• hasTemplate() - überprüfen ob Template-Datei gesetzt ist
• assign($spec, $value = null, $nocache = false, $scope = null) - Variablen für das Template registrieren
• clearAssign($spec = null)
• getAssign($spec = null)

Beispiel für das Zuweisen von Variablen an den View.

 
<?php
class Shopware_Controllers_Frontend_Test extends Enlight_Controller_Action
{
	public function indexAction()
	{
	$this->View()->Variable = "Inhalt";
	}
}
 

Dieser Controller würde automatisch das Template frontend\test\index.tpl laden und dort die Variable {$Variable} bereitstellen!

Mit dem im View-Objekt integriertem Caching können sehr einfach zwischengespeicherte Versionen der verschiedenen Shop-Views erzeugt werden. So kann die Server-Last durch oft aufgerufene Seiten stark reduziert werden. Zum Steuern des Caches werden folgende Methoden bereitgestellt.

• setCaching($value=true) - Caching ein-/ausstellen
• isCached() - Überprüfen ob eine gecachte Version vorhanden ist
• setCacheID($cache_id = null) - CacheID ändern/setzten
• clearCache($template = null, $cache_id = null, $compile_id = null, $exp_time = null, $type = null) - Cache leeren

Beispiel

 
public function indexAction()
{
	$this->View()->setCaching(true);
	$this->View()->setCacheID(array('detail', 311));
	if(!$this->View()->isCached())
	{
		$this->View()->assign('article', array('id'=>12,'name'=>'test'));
	}
}
 

Folgende Ressourcen stehen standardmäßig im Bootstrap zur Verfügung.

• Front > Front-Controller
• Template > Template-Manager
• Db > Datenbankverbindung
• Session > Zend_Session Objekt
• System > Altes Shopware sSystem-Objekt
• Modules > Alte Shopware sModules-Objekte
• Config > Konfigurationen

Beispiele

 
$front = Shopware()->Front();
 

 
$sql = 'SELECT COUNT(*) as c FROM s_articles';
$count = Shopware()->Db()->GetOne($sql);
 
$articles = Shopware()->Modules()->Articles();
$charts = $articles->sGetArticleCharts();
 

Mit dem neuen Shopware Plugin-System können natürlich auch Zahlungsmodule realisiert werden. Hier wurde die Syntax und der Integrationsaufwand im Vergleich zu vorherigen Versionen deutlich vereinfacht. Natürlich funktionieren die alten Zahlungssysteme auch weiterhin, dies gilt auch für Schnittstellen die Sie selbst entwickelt haben.

Mit Enlight haben wir das Zend-Framework um einen neuen Applikationskern erweitert. Dieser stellt unter anderem ein äußerst flexibles und leistungsfähiges Plugin-System zur Verfügung, mit dem Shopware in allen Bereichen flexibel angepasst werden kann.

Screenshot Verzeichnis-Struktur / Standard-Plugins Die Plugins werden zentral in folgender Verzeichnisstruktur abgebildet

Shopware\Plugins
|-- Community - Plugins aus dem Shopware CommunityStore
|--- Unterverzeichnisse analog zu "Default"
|-- Default - Standard Plugins der shopware AG
|--- Backend - Backend Plugins
|--- Core - System Plugins
|--- Frontend - Template / Frontend Plugins
|-- Local - Lokale Anpassungen
|--- Unterverzeichnisse analog zu "Default"

Die Plugins können bequem im Backend installiert und verwaltet werden. Natürlich lassen sich Plugins, die nicht benötigt werden, auch einfach deaktivieren.

Der Subscriber ist eine Schnittstelle zum Registrieren von Listenern bei Hooks, Events und Template-Blöcken. Listener sind Methoden die unter bestimmten Bedingungen, zum Beispiel beim Aufruf eines Events aufgerufen werden. Damit beim Start nicht alle Plugins erneut geladen und registriert werden müssen, werden alle Registrierungen in einem Plugin-Cache in der Datenbank zwischengespeichert. Die Listener müssen also nur bei der Installation der Plugins registert werden.

Beispiel für einen Event

Um einen Event zu registieren wird eine neue Instanz des Enlight_Core_Event_EventHandler erzeugt. Diese Instanz wird dann an den Subscriber übergeben.

 
$handler = new Enlight_Core_Event_EventHandler ($event, $listener);
Shopware()->Subscriber()->subscribeEvent($handler);
 

Die Listener-Methoden werden mit einem Collection-Objekt aufgerufen. Dieser enthällt Informationen zum Hook, Event oder Template-Block. Durch dieses Collection-Objekt wird sichergestellt, dass der Zugriff auf die Daten einheitlich erfolgt.

Hier folgt eine Auflistung der Collection-Objekte

Event-Argumente: "Enlight_Core_Event_EventArgs"

• stop() - weitere Ausführung stoppen
• getName() - gibt den Namen des Events zurück
• setReturn($return) - ändert das Ergebnis
• getReturn() - gibt das Ergebnis zurück

Event-Argumente: "Enlight_Core_Hook_HookArgs"

• getSubject() - gibt das Objekt zurück
• getMethod() - gibt den Namen der Methode zurück
• getArgs() - gibt die Parameter der Methode zurück
• getName() - gibt den Namen der Klasse zurück
• setReturn($return) - ändert das Ergebnis
• getReturn() - gibt das Ergebnis zurück
• get($key) - gibt ein bestimmten Parameter zurück
• set($key, $value) - ändern eines bestimmten Parameters

Event-Argumente: "Enlight_Core_Template_BlockArgs"

• stop() - weitere Ausführung stoppen
• getName() - gibt den Namen des Blocks zurück
• setReturn($return) - ändert das Ergebnis
• getReturn() - gibt das Ergebnis zurück

Die alten Hookpoints, die auf "eval" basieren und Code aus der Datenbank an definierten Stellen im Programmcode einfügen, werden mit Shopware 4.0 entfernt. Sie sollten daher mit Release von Shopware 3.5.0 Ihre Plugins auf die neue Struktur umstellen. Die Hookpoints aus der shopware.php und den Viewports entfallen aufgrund von Umstellungen schon mit der Version 3.5.0.

Mit Events können bei Ereignissen im Programmfluss sogenannte „Listeners“ aufgerufen werden. Diese Ereignisse müssen im Programm definiert werden. Die Listeners müssen vor dem Aufruf des Events registriert worden sein. Es gibt drei unterschiedliche Methoden zum Abfeuern eines Events. Diese unterscheiden sich vor allem bei der Behandlung der Rückgabe des Listeners.

• notify($event, $eventArgs = null): keine Behandlung der Rückgabe
• notifyUntil($event, $eventArgs = null): Wenn “true” zurückgeben wurde, werden keine weiteren Listeners aufgerufen.
• filter($name, $value): Die Rückgabe des Listeners wird gespeichert und zum Schluss zurückgegeben. Über den Parameter „$value“ kann ein Startwert definiert werden.

Beispiel für das Abfeuern eines Events

 
Enlight()->Events()->notify(' Enlight_Core_Controller_ControllerSale_OrderFinished', array($this));
 

Beispiel für das Abfeuern eines Filter-Events

 
$new_source = Enlight()->Events()->filter(' Enlight_Core_Controller_ControllerFront_FilterRender', $old_source);
 

Beispiel eines Listener der die Ausgabe des Template filtert

 
public static function filterOutput(Enlight_Core_Event_EventArgs $args)
{
	$output = $args->getReturn();
	$output = str_replace('  ', '', $output);
	return $output;
}
 

Mit Hooks können Methoden einer Klasse überschrieben oder erweitert werden. Es können mehrere Hooks für eine Methode definiert werden. Dazu muss die Klassen ein spezielles Interface eingebunden haben und über einen Proxy aufgerufen werden.

Der Proxy der Klasse wird automatisch anhand der registrieren Hooks erstellt.

Aufbau einer Klasse zur Unterstützung von Hooks

 
class Enlight_Core_Controller_ControllerFront implements Enlight_Core_Hook
{
 ...
}
 

Initialisieren einer Hook-Klasse

 
$front = Enlight_Core_ClassPattern::Instance('Enlight_Core_Controller_ControllerFront');
 

Hook-Typen

• TypeReplace: Hook wird statt der eigentlichen Methode aufgerufen
• TypeBefore: Hook wird vor der eigentlichen Methode aufgerufen
• TypeAfter: Hook wird nach der eigentlichen Methode aufgerufen

Beispiel um ein altes Modul zu erweitertern

 
public function install()
{
	$type = Enlight_Core_Hook_HookHandler::TypeAfter;
	$handler = new Enlight_Core_Hook_HookHandler('sArticles', 'sGetPromotionbyID', __CLASS__.'::myGetPromotionbyID', $type);
	Shopware()->Subscriber()->subscribeHook($handler);
}
 
public static function myGetPromotionbyID(Enlight_Core_Event_EventArgs $args)
{
	$article = $args->getReturn();
	$article['attr11'] = explode(',', $article['attr11']);
	return $article;
}
 

Mit Blöcken können sehr einfach Änderungen am Template vorgenommen werden. Dazu wurden eine Vielzahl von Blöcken vordefiniert. Alle Blöcke haben einen eindeutigen Namen. Die Blöcke können nun über diesen Namen überschrieben oder bearbeitet werden. Über das Subscriber-Objekt kann eine Methode für einen Block registriert werden. Die Methode wird dann bei der Kompilierung des Templates aufgerufen. Die Rückgabe der Methode wird an den Block übergeben.

Block-Typen

• TypeReplace: Rückgabe wird statt des eigentlichen Blocks ausgegeben
• TypeBefore: Rückgabe wird vor des eigentlichen Blocks ausgegeben
• TypeAfter: Rückgabe wird nach des eigentlichen Blocks ausgegeben

Beispiel für die Registrierung eines Block-Listeners

 
$name = 'index_header_meta_tags'; // Name des Template-Blocks
$listener = 'Shopware_Plugins_Facebook::getMetaTags'; // Listener der aufgerufen werden soll
$type = Enlight_Core_Template_BlockHandler::TypeReplace; // Typ der Ersetzung
 
$handler = new Enlight_Core_Template_BlockHandler ($name, $listener, $type);
Shopware()->Subscriber()->subscribeBlock($handler);
 

Beispiele für Block-Listener'

 
public static function getMetaTags(Enlight_Core_Event_BlockArgs $args)
{
	return file_get_contents(dirname(__FILE__).'/frontend/widgets/facebook/meta_tags.tpl');
}
public static function getLikeButton(Enlight_Core_Event_BlockArgs $args)
{
	return file_get_contents(dirname(__FILE__).'/frontend/widgets/facebook/button_like.tpl');
}
 

Über das Plugin-System können neue Backend-Modulen angelegt werden oder bestehende Module ersetzt werden. Dadurch können auch im Backend die Vorteile des neuen Plugin-Systems genutzt werden. So können z.B. Templates und Events auch in Backend-Modulen verwendet werden. Hier werden folgende Funkionen unterstützt:

• Menü-Eintrag im Backend hinzufügen
• Neues Modul im Backend registrieren
• Bestehendes Modul aus dem Backend mit Plugin-Verzeichnis ersetzen

In folgenden Beispiel möchten wir Ihnen ein PlugIn vorstellen, welches einen "Facebook-Like"-Button auf der Artikel-Detailseite einbindet.

Um einen "Facebook-Like"-Button mit Informationen zu befüllen, müssen im Head-Bereich der Seite spezielle Meta-Tags für das zu verwendene Bild und die Beschreibung hinterlegt werden.

Für weitere Informationen besuchen Sie bitte das Developer Wiki von Facebook

Im ersten Teil der Funktion install() setzen wir diese Meta-Tags in den Template-Block "index_header_meta_tags" und definieren das dieser Block, mit dem Inhalt des Listeners "getMetaTags()" , ersetzt werden soll.

 
$name = 'index_header_meta_tags'; // Name des Template-Blocks
$listener = 'Shopware_Plugins_Facebook::getMetaTags'; // Listener der aufgerufen werden soll
$type = Enlight_Core_Template_BlockHandler::TypeReplace; // Typ der Ersetzung
 

Danach registrieren wir diese Änderungen über den Subscriber mit folgendem Aufruf:

 
$handler = new Enlight_Core_Template_BlockHandler ($name, $listener, $type);
Shopware()->Subscriber()->subscribeBlock($handler);
 

Im zweiten Teil der Funktioninstall() setzen wir den eigentlichen "Facebook-Like"-Button. Hierzu verwenden wir den Template-Block "detail_links" und fügen den Inhalt des Listeners 'getLikeButton()' am Ende des Blocks ein, so dass der

bestehende Inhalt erhalten bleibt. Am Ende der Funktion registrieren wir diese Änderungen ebenfalls über den Subscriber.

 
$name = 'detail_links'; // Name des Template-Blocks
$listener = 'Shopware_Plugins_Facebook::getLikeButton'; // Listener der aufgerufen werden soll
$type = Enlight_Core_Template_BlockHandler::TypeAppend ; // Typ der Ersetzung
 
$handler = new Enlight_Core_Template_BlockHandler ($name, $listener, $type);
Shopware()->Subscriber()->subscribeBlock($handler);
 

Das komplette Plugin

 
class Shopware_Plugins_Facebook_Bootstrap extends Enlight_Core_Plugin_Bootstrap
{
	public function install()
	{
		$name = 'index_header_meta_tags'; // Name des Template-Blocks
		$listener = 'Shopware_Plugins_Facebook::getMetaTags'; // Listener der aufgerufen werden soll
		$type = Enlight_Core_Template_BlockHandler::TypeReplace; // Typ der Ersetzung
 
		$handler = new Enlight_Core_Template_BlockHandler ($name, $listener, $type);
		Shopware()->Subscriber()->subscribeBlock($handler);
 
		$name = 'detail_links'; // Name des Template-Blocks
		$listener = 'Shopware_Plugins_Facebook::getLikeButton'; // Listener der aufgerufen werden soll
		$type = Enlight_Core_Template_BlockHandler::TypeAppend ; // Typ der Ersetzung
 
		$handler = new Enlight_Core_Template_BlockHandler ($name, $listener, $type);
		Shopware()->Subscriber()->subscribeBlock($handler);
	}
	public static function getMetaTags(Enlight_Core_Event_BlockArgs $args)
	{
		return file_get_contents(dirname(__FILE__).'/frontend/widgets/facebook/meta_tags.tpl');
	}
	public static function getLikeButton(Enlight_Core_Event_BlockArgs $args)
	{
		return file_get_contents(dirname(__FILE__).'/frontend/widgets/facebook/button_like.tpl');
	}
}
 

In Shopware 3.5 gibt es umfangreiche Debug- und Profiling-Möglichkeiten. Durch das neue Exception-Plugin lässt sich flexibel konfigurieren, wie der Shop mit Fehlern umgehen soll. Während der Entwicklungsphase können Exceptions beispielsweise direkt geworfen werden, es ist aber auch möglich, diese in der Datenbank zu protokollieren oder aber per eMail zu verschicken.

Screenshot Exception Handler Frontend

Für noch mehr Möglichkeiten, können Sie auf eine leistungsfähige FireBug Erweiterung zurückgreifen. Die bei jedem Request alle relevanten Shop-Informationen und Performance-Daten ausgibt.

Screenshot Shopware Firebug Extension

Darüber hinaus unterstützen wir standardmäßig XHProf (http://mirror.facebook.net/facebook/xhprof/doc.html), mit dieser PHP-Extension können Sie Ihre Erweiterungen schnell und einfach auf Geschwindigkeit & Skalierbarkeit hin optimieren.

Durch die Einbindung von Enlight in Shopware 3.5.0 ergeben sich natürlich auch Änderungen für benutzerdefinierte Anpassungen. Um Sie bei der Übernahme von individuellen Anpassungen zu unterstützen finden Sie jetzt einen Custom-Ordner

unterhalb des "engine"-Ordners.

Dieser Ordner hat folgende Unterordner:

• class für Klassen-Module
• modules für Backend-Module
• viewports für Viewports

Dieser Ordner fungiert als Kompatibilitätsschicht für bestehende Anpassungen. Zwar werden auch die einzelnen "inherits"-Ordner in Shopware 3.5.0 weiterhin unterstützt, doch

diese Unterstützung wird mit dem Erscheinen von Shopware 4.0 entfallen, deshalb empfehlen wir Ihre alten Anpassungen in Form von Plugins neu umzusetzen.

Wenn Sie den "custom"-Ordner nutzen möchten, müssen gewissen Änderungen an den jeweiligen Erweiterungen durchgeführt werden.

Namensgebung

Der Name der Klasse setzt sich aus dem Präfix "sCustom" und dem eigentlichen Namen des Moduls zusammen, so dass die Benennung der Dateien nach folgenden Schema durchgeführt werden sollte:

 
sCustom{Name}.php
 

Der Klassenname muss nach dem selben Schema aufgebaut werden:

 
class sCustom{Name} … {
 
    …
 
}
 

Benennung der Viewports

Die Benennung der Viewports verhält sich ähnlich der Benennung von normalen Plugins mit der Ausnahme dass das Präfix "sCustomViewport" lautet. Bitte nutzen Sie deshalb folgendes Schema für Viewports.

Dateibenennung

 
sCustomViewport{Name}.php
 

Klassenbenennung

 
class sCustomViewport{Name} … {
 
    …
 
} 
 

Bitte beachten Sie, dass durch die Verwendung des "customs"-Ordner die Pfade geändert haben. Falls Sie relative Pfade verwenden müssen diese angepasst werden.

Statt …

 
"../../core/php/check.php"
 

… sollte jetzt folgender Pfad verwendet werden

 
"../../../core/php/check.php"
 

Um Ihnen die Möglichkeit zu geben Ihre Templates, welche auf der alten Template-Basis aufbauen, weiterhin zu nutzen verfügt Shopware 3.5.0 über einen Kompabilitätslayer, welcher dafür sorgt dass die alten Template-Pfade weiterhin gefunden

und aufgerufen werden. Des Weiteren unterstützen wir die Vererbung von Templates, so dass Sie bis zum Erscheinen der neuen Shopware Version 4.0.0 erstmal Ihr altes Template weiter verwenden könnten. Wenn Sie jedoch alle Features der Shopware Version 3.5.0 nutzen möchten, ist eine komplette Migration des Templates erforderlich.

Durch das neue Plug-In System von Shopware haben wir als Anbieter den Vorteil, dass wir den Kern, die sogenannte Core, von Shopware deutlich entschlacken können und die jeweils nicht systemkritischen Bestandteile als Plugins auslagern können. So erreichen Sie in Ihrem Shop einen deutlichen Geschwindigkeitsgewinn und nutzen nur noch die Funktionen, die Sie tatsächlich benötigen.

Das hat für Sie als Shopbetreiber den Vorteil, dass Sie so nicht benötigte Funktionen / Module einfach über das Shopware Backend deaktiveren können. So können Sie selbst bestimmen welche Funktionen Sie in Ihren

Shop nutzen möchten und können so auch die Systembelastung bestimmen. Wenn Sie beispielsweise keine bzw. nur rudimentäre Statistiken in Ihrem Shop benötigen, können Sie beispielsweise das Statistik Plugin abschalten und erreichen so eine höhere Performance.

Das Zend-Framework ist jetzt standardmäßig in Shopware integriert. Auch die Klassen werden, genau wie die Shopware-/Enlight-Klassen, automatisch eingebunden.

Beispiel

 
$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', array(
  'auth'     => 'login',
  'username' => 'foo',
  'password' => 'bar',
  'ssl'      => 'ssl',
  'port'     => 465,
));
 
$mailer = new Zend_Mail();
$mailer->setDefaultTransport($transport);