Ausblick auf die neue Shopware-Version 4.2.0

Shopware unter der Lupe
Kommentare

Seit dem letzten Major-Release hat sich bei Shopware einiges getan. Wir können uns auf viele neue Funktionen freuen und wollen die Gelegenheit nutzen, einen Blick darauf zu werfen.

Neu ist zum Beispiel die verbesserte Unterstützung der Mehrsprachigkeit, neue integrierte Komponenten (Monolog, Dependency Injection Container und Composer), neue Plug-in-Hilfen (Autovervollständigung, einfacheres Erstellen von Einkaufsweltelementen und neuen Events), Shopware CLI Tools auf Basis von Symfony 2 Console Component, Unit Test für Plug-ins, SEO-Verbesserungen bei den Herstellerseiten und viele Optimierungen am REST-API. In diesem Artikel werden wir die wichtigsten Änderungen kurz beschreiben und evaluieren. Die Neuerungen beim Unit Testing für Plug-ins werden in einem separaten Artikel vorgestellt.

Neue integrierte Komponenten

Die Integration von Composer für die wichtigsten Drittanbieterprodukte in Shopware ist sehr erfreulich. Damit einhergehend hat Shopware das Zend Framework auf 1.12.3, Symfony Components auf 2.4 und Doctrine auf 2.4 aktualisiert.

Durch die Integration von Monolog gibt es nun drei verschiedene Möglichkeiten, Logausgaben zu erstellen. Die altbekannte Methode mit Shopware()->Log() ist als „deprecated“ gekennzeichnet. Die Methode Shopware()->Corelogger() ist für den Shopware-Core vorgesehen. Die Logdateien werden unter /logs/core_production-YYYY-MM-DD.log gespeichert und nach vierzehn Tagen gelöscht. In zukünftigen Shopware-Versionen wird man auch jeden beliebigen anderen Monolog-Handler verwenden können.

Die zweite Möglichkeit ist die Methode Shopware()->Pluginlogger(). Sie ist für den Einsatz in eigenen Plug-ins vorgesehen. Sie speichert, wie der Corelogger, die Logdateien unter /logs/ – nur mit einer kleinen Änderung am Dateinamen: plugin_production-YYYY-MM-DD.log. Die Datei wird wie beim Corelogger einmal täglich neu erstellt und im identischen Intervall gelöscht.

Zu guter Letzt gibt es die Methode Shopware()->Debuglogger(), die sich für den spontanen Debugging-Einsatz empfiehlt. Hier wird keine Logdatei erstellt, sondern die Information wird, wenn das Debug-Plug-in aktiv ist, direkt in der Konsole des jeweiligen Browsers ausgegeben.

Ein Plug-in, das die drei Methoden verwendet, ist im Listing 1 zu sehen.

subscribeEvent(
      'Enlight_Controller_Action_PostDispatchSecure_Frontend',
      'onPostDispatchSecure'
    );
    $this->registerController('Frontend', 'Magazin');
    return TRUE;
  }

  public function onPostDispatchSecure(Enlight_Event_EventArgs $args)
  {
    $descriptionArray = array(
      'description',
      'description2'
    );
    Shopware()->Pluginlogger()->addNotice('Pluginlogger',$descriptionArray);
    Shopware()->Debuglogger()->addNotice('Debuglogger',$descriptionArray);

    $log = new Logger(PHPMagazin);
    $log->pushHandler(new FirePHPHandler());
    $log->addWarning('warning title',$descriptionArray);
    $log->addAlert('alert title',$descriptionArray);
  }
}

Plug-in Helper

Für diese Version sind neue unterstützende Methoden für die Plug-in-Entwicklung hinzugekommen. Es ist nun noch einfacher geworden, eigene Controller im Plug-in zu erstellen. Unter der Voraussetzung, dass man im Plug-in-Verzeichnis unter /Controllers/Frontend/ die Controller-Klasse Magazin.php ablegt, kann man mit $this->registerController(‚Frontend‘,’Magazin‘); den Frontend-Controller Magazin registrieren. Man benötigt dadurch keine weitere Funktion in der Bootstrap.php mehr. Optional kann ein dritter Parameter definiert werden, um einen eigenen Event Listener anzugeben. Eigene Einkaufsweltenelemente sind nun ebenfalls bedeutend einfacher zu erstellen. Eine detaillierte Beschreibung hierfür stellt Shopware bereit.

Shopware CLI Tools

Die CLI Tools wurden auf Basis der Symfony-Konsolenkomponenten entwickelt und können auch um eigene Befehle erweitert werden. Die Tools befinden sich unter /bin/console/ im Documentroot des Shopware-Projekts. Die aktuell vorhandenen Befehle teilen sich in Database Absctraction Layer (DBAL), Object-Relations Mapper (ORM) und Shopware (SW) auf.

Im DBAL-Bereich kann man SQL-Dateien direkt importieren oder auch SQL-Befehle an die Datenbank absetzen. Das könnte zum Beispiel so aussehen:

./bin/console dbal:run-sql 'SELECT * FROM s_core_shops;'

Unter ORM besteht die Möglichkeit, diverse Caches (metadata, query und result) zu löschen und die jeweiligen Entities, Proxies und Repositories zu generieren. Des Weiteren sind dort mehrere Funktionen für das Doctrine-Schema vorhanden.

Im SW-Bereich können die Attribut-Models generiert und verschiedene Einstellungen/Operationen von Plug-ins durchgeführt werden. Außerdem ist die Verwaltung der Snippets (entfernen, laden, speichern) und die Aktualisierung der Plug-ins aus dem Community-Store möglich.

Deprecated ZF-Komponenten Integrierte Zend-Framework-Komponenten, die deprecated sind: • Zend_Amf • Zend_Application • Zend_Barcode • Zend_Cloud • Zend_CodeGenerator • Zend_Console • Zend_Gdata • Zend_Markup • Zend_Measure • Zend_Memory • Zend_Pdf • Zend_Reflection • Zend_Search • Zend_Serializer • Zend_Tag • Zend_Test • Zend_Tool

Fazit

Mit der nun erscheinenden Version 4.2.0 hat Shopware wieder einen großen Schritt nach vorne gemacht. Das angesagte Ziel „Shopware goes international“ wurde in der neuen Version konsequent umgesetzt. Das Shopware Backend und eigene Plug-ins können jetzt besser übersetzt werden. Darüber hinaus kann das REST-API nun auch Übersetzungen verarbeiten und importieren. Symfony 2 wird in Shopware immer mehr integriert und löst damit das erweiterte Zend Framework Enlight nach und nach ab. Daher ist es nur richtig, nicht mehr benötigte Module des Zend Frameworks als deprecated (Kasten: „Deprecated ZF-Komponenten“) zu markieren. Ich freue mich bereits darauf, die ersten Projekte mit Shopware 4.2.0 umsetzen zu dürfen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -