OXVM für die Entwicklung mit OXID eShop verwenden

Dieser Artikel soll Entwickler an die OXVM heranführen und zeigen, wie sie als Grundlage für Projekte genutzt werden kann, um schnell mit der wichtigen Arbeit, der Entwicklung eigener Anpassungen für OXID eShop beginnen zu können. Eine vorkonfigurierte VM, die erst auf dem Zielcomputer generiert und hochgefahren wird, bringt eine hohe Flexibilität ins Projekt, weil Entwickler binnen weniger Minuten ein funktionierendes Setup in Betrieb nehmen können, das zugleich auch noch einheitlich und plattformunabhängig ist.

Vorwort

Ende Oktober 2015 hat OXID die OXVM vorgestellt, eine virtuelle Maschine, die mit Vagrant und dem Provisioner Ansible erstellt wird und auf die Verwendung mit OXID eShop zugeschnitten ist.

Oberstes Ziel bei der Entwicklung dieser VM war die Schaffung einer einheitlichen und repräsentationsfähigen Umgebung für Entwicklungsarbeiten an OXID eShop. Hierfür wird die VM mit bestimmten Softwarepaketen und Erweiterungen ausgestattet. Darunter gehören neben der obligatorischen LAMP-Installation (Linux, Apache, MySQL und PHP) solche Bestandteile wie Composer, Xdebug und Varnish sowie die per Konfigurationsparameter installierbaren Testwerkzeuge und das OXID-SDK. Mit letzteren können etwa die mitgelieferten Shop-Tests ausgeführt oder aber auch eigene Module während der Entwicklung auf Einhaltung der Richtlinien und Erfüllung selbst geschriebener Unit- und Integrationstests geprüft werden.

OXVM bekommen

Die OXVM können Sie bei GitHub herunterladen. Das Projekt enthält als Unterprojekt das Paket oxvm_base (im Verzeichnis base_vm). Wenn Sie einen GIT-Client verwenden, wird dieses Paket gleich mit ausgecheckt. Hierzu gibt es übrigens noch mehr zu erzählen – später mehr.


Mit der OXVM verfolgt OXID einen sauberen Ansatz für die Trennung von anwendungsspezifischen und generischen Paketbestandteilen. So setzt sich die VM aus einer Konfiguration zusammen, die allgemein eingesetzt werden kann. Alles, was dann noch OXID-spezifisch ist, wird mit “oxvm_eshop” nachgeliefert und quasi obendrauf gebaut.

Bevor man mit der Arbeit an der VM beginnt, sollte man sich die Repository-Inhalte in ein neues Projektverzeichnis kopieren. Weil die VM projektspezifische Einstellungen enthalten wird und Zubehör wie beispielsweise ein Datenbankdump zum Projekt gehören, ist es empfehlenswert, das Ganze als Projekt aufzufassen und auch so in der IDE zu verwalten.

Eine eigene Konfiguration für die VM erstellen

Zwar kann die VM gleich nach dem Herunterladen von GitHub in Betrieb genommen werden, es ist jedoch empfehlenswert, sich mit einigen ihren Konfigurationsmöglichkeiten vertraut zu machen und ein paar Einstellungen anzupassen.

Die Einstellungen werden dem Provisioner mittels Yaml-Datei mitgeteilt. Eine Platzhalterdatei mit dem Namen personal.yml.dist befindet sich im Wurzelverzeichnis. Aus dem Dateinamen wird nun das “.dist” entfernt und die Datei geöffnet. In der ersten Zeile befindet sich ein Hinweis auf eine weitere Yaml-Datei. Gemeint ist /base_vm/ansible/vars/default.yml. Diese Datei legt allgemeingültige Einstellungen für die VM fest (vgl. oben). Der Definition nach müsste es also noch eine Datei geben, in der sich die OXID-spezifischen Einstellungen befinden; diese ist /ansible/vars/oxideshop.yml. Beide Dateien sollen uns als Vorlage zur Erstellung einer projektspezifischen personal.yml dienen.

--- # Override any variable from 'ansible/vars/oxideshop.yml' and 'base_vm/ansible/vars/default.yml' vagrant_local: vm: memory: '1024' cpus: 1 name: DemoVM hostname: ackisdemovm.dev aliases: - www.ackisdemovm.dev app_shared_folder: source: ./htdocs target: /var/www/htdocs server: timezone: Europe/Berlin locale: de_DE.UTF-8 apt_mirror: http://de.archive.ubuntu.com/ubuntu/ unattended_upgrade: true varnish: install: false eshop: config: utf_mode: 1 sdk: module_skeleton_generator: install: false module_certification_tools: install: false apache: install: true docroot: /var/www/htdocs servername: ackisdemovm.dev packages: - php5-cli - php5-intl - php5-mcrypt - php5-mysql - php5-gd - php5-curl composer: prestissimo: install: true mysql: install: true root_password: '123' database: oxid user: user password: password

php: install: true packages: - php5-cli - php5-intl - php5-mcrypt - php5-mysql - php5-gd - php5-curl phpbrew: cache: repo: 'https://github.com/OXID-eSales/oxvm_assets' ref: 'phpbrew_builds' depth: 1 update: true version: ~ composer: installer_url: https://getcomposer.org/installer install: '0' github_token: ~ prestissimo: install: false pecl_packages: ~ zendguard: install: false

Einige der hier gezeigten Möglichkeiten dienen lediglich als Hinweis darauf, dass sie geändert werden können – zum Beispiel Festlegen der Spracheinstellungen und des Updateservers auf de.archive.ubuntu.com anstelle von en.archive.ubuntu.com – sie müssen nicht übernommen werden. Die Zugangsdaten für MySQL stehen hier, damit niemand suchen muss.

Entspricht die Konfiguration den Wünschen, kann sie allmählich hochgefahren werden. Davor aber noch ein Einschub für diejenigen, die Vagrant noch nicht haben.

Software installieren und einrichten

Vagrant erzeugt auf Grundlage einer Textdatei eine virtuelle Maschine. Hierfür wird eine vorbereitete Festplattendatei verwendet, die, falls im System noch nicht existent, erst heruntergeladen werden muss. Ist das der Fall, dauert das initiale Hochfahren ca. 10 Minuten länger. Zum Zeitpunkt der Entstehung dieses Artikels dient ubuntu/trusty64 als Vorlage.

Die Software können Sie von der Website vagrantup.com herunterladen. Als Hostsystem für die virtuelle Maschine wird VirtualBox benötigt, und zwar mitsamt dem jeweils aktuellen Extension Pack. Ist alles installiert, muss eventuell das System neu gestartet werden. Danach kann durch Eingabe des Befehls

vagrant –v

überprüft werden, ob Vagrant funktioniert. Es sollte die Versionsnummer angezeigt werden. Wenn Sie Vagrant vorher noch nicht verwendet haben, müssen möglicherweise noch Plugins installiert werden. Entsprechende Warnungen werden dann beim Hochfahren der VM angezeigt („Plugin … not found“). Mit den Befehlen

vagrant plugin install vagrant-bindfs
vagrant plugin install vagrant-hostmanager
vagrant plugin install vagrant-triggers

installieren Sie fehlende Plugins.

Wichtig: Unter Windows müssen möglicherweise noch die beiden Systemvariablen %PATH% und %VAGRANT_HOME% so gesetzt werden, dass sie auf das bin-Verzeichnis der Vagrant-Installation zeigen.

OXVM bzw. BASE_VM für eigene Projekte verwenden

Das in “oxvm_eshop” verwendete Unterprojekt “base_vm” kann für Projekte eingesetzt werden, die eine andere als die automatisch installierte Shopversion und -Ausgabe und/oder für den Betrieb darüber hinaus gehender Software verwendet werden sollen; sie ist also für neue und bestehende Projekte geeignet.

Für ein solches Setup wird das Projekt “oxvm_eshop” nicht benötigt, es genügt “base_vm”. Das Wurzelverzeichnis des Projekts kann dabei so aussehen, dass Projektdateien und VM-Zubehör in getrennten Verzeichnissen verwaltet werden. Im Wurzelverzeichnis liegen dann noch die Dateien Vagrantfile und personal.yml. Dateien wie etwa index.php oder config.inc.php gehören nicht in dieses Verzeichnis, sondern in das Verzeichnis, das später in das Document Root der im Webserver konfigurierten Websites bereitgestellt wird. Um das Ganze zu veranschaulichen, hier noch ein Bild vom Projekt-Explorer, hier in Eclipse:

projektverzeichnis

Das Projekt wird hierbei mit den Inhalten des Verzeichnisses “base_vm” aufgebaut, das Verzeichnis selbst wird nicht übernommen. So wird “ansible” zum Verzeichnis, in dem Vagrant bzw. Ansible später die VM-Konfiguration vorfinden werden. Daneben muss mindestens das eigentliche Projekt platziert werden, bei mir heißt es – anders als in der OXVM – htdocs. Darin befindet sich dann auch der Shop und wenn gewünscht, weitere Pakete.

Die für Projekte verwendbare personal.yml kann dann zum Beispiel so aussehen:

---
# Override any variable from 'ansible/vars/oxideshop.yml' and 'base_vm/ansible/vars/default.yml'
vagrant_local:
  vm:
    memory: '2048'
    cpus: 2
    name: DemoVM
    hostname: ackisdemovm.dev
    aliases:
      - www.ackisdemovm.dev
    app_shared_folder:
      source: ./htdocs
      target: /var/www/htdocs
server:
  timezone: Europe/Berlin
  locale: de_DE.UTF-8
  apt_mirror: http://de.archive.ubuntu.com/ubuntu/
  unattended_upgrade: true
varnish:
  install: false
eshop:
  config:
    utf_mode: 1
  sdk:
    module_skeleton_generator:
      install: false
    module_certification_tools:
      install: false
apache:
  install: true
  docroot: /var/www/htdocs
  servername: ackisdemovm.dev
  packages:
    - php5-cli
    - php5-intl
    - php5-mcrypt
    - php5-mysql
    - php5-gd
    - php5-curl
  composer:
    prestissimo:
      install: true
mysql:
  install: true
  root_password: '123'
  database: oxid
  user: user
  password: password
  dump: 'sql/db.sql'
php:
  install: true
  packages:
    - php5-cli
    - php5-intl
    - php5-mcrypt
    - php5-mysql
    - php5-gd
    - php5-curl
  phpbrew:
    cache:
      repo: 'https://github.com/OXID-eSales/oxvm_assets'
      ref: 'phpbrew_builds'
      depth: 1
      update: true
  version: ~
  composer:
    installer_url: https://getcomposer.org/installer
    install: '0'
    github_token: ~
    prestissimo:
      install: false
  pecl_packages: ~
  zendguard:
    install: false

Als nennenswerte Abweichung gegenüber der zuvor gezeigten Datei sei hier die Angabe eines Datenbankdumps genannt, welches sich im Projekt unterhalb von sql/ befindet. Dieses Dump wird beim ersten Start der VM automatisch in die vorkonfigurierte Datenbank eingespielt — so kann das Projekt schnell aufgesetzt werden und erleichtert neu eingestiegenen Entwicklern den Start. Diese Datei kann in leicht modifizierter Form auch heruntergeladen werden. Verwenden erwünscht, Feedback ebenso. Die gezeigte Datei ist bei mir übrigens im alltäglichen Einsatz.

VM hochfahren

Wenn Sie bereit sind, öffnen Sie die Eingabeaufforderung (CMD, Bash oder Terminal) und wechseln Sie zum Projektverzeichnis, sodass Sie sich in dem Pfad befinden, in dem auch die Datei Vagrantfile liegt. Geben Sie nun ein:

vagrant up

Vagrant beginnt mit dem Generieren der VM, danach übernimmt der Provisioner Ansible das Installieren von Software innerhalb der VM. Dabei wird der Hostmanager verwendet, um die eingestellte IP-Adresse und den Hostnamen sowie die Aliasse in die hosts-Datei des Betriebssystems einzutragen. Gegebenenfalls muss die Rückfrage – Windows-Nutzer, nicht erschrecken! – des Betriebssystems bestätigt werden.

Wenn Sie die OXVM mit Unterprojekt (also nicht im “Projektmodus”) verwenden, wird im letzten Schritt der OXID eShop (CE) aus GitHub abgerufen und installiert.

Hat alles geklappt, wird in der abschließenden Zusammenfassung failed=“0″ angezeigt.

image

Im Webbrowser lässt sich nun die Adresse (http://Hostname) aufrufen, dann sollte auch schon der Shop erscheinen.

Wer sein Projekt um weitere Helfer anreichern möchte, dem sei die OXID Console empfohlen, die mit dem Kommando

oxid fix:states –all

neu hinzugekommene Module betriebsfähig macht.

Vorschau auf OXID eShop 6 und das Flow-Theme

Für diese Woche wird das Patch-Release 4.9.8/5.2.8 des OXID eShops erwartet. Die kommende „größere“ Updateversion des Shopsystems 4.10/5.3 ist bereits seit der vergangenen Woche als Betaversion erhältlich. Letzteres Release ist deswegen etwas Besonderes, weil es das neue Theme Flow enthalten soll. Flow ist OXIDs Antwort auf die hohe Nachfrage nach einem sich responsive verhaldendes, also einem sich an das Endgerät anpassendes Theme handelt.

Flow

Mit Flow soll OXID eShop bereits demnächst moderne Anforderungen an Online-Shops erfüllen, die auf einer Vielzahl an Geräten dargestellt werden müssen. Im Repository liegt Flow für OXID eShop 4.10/5.3 sowie die noch in der Entwicklung befindliche Version 6 bereit. Flow, wie es derzeit im Repository liegt, präsentiert sich selbst als Version „1.0.0-Beta“. Die erste stabile Version wird wahrscheinlich mit OXID eShop 6 erscheinen. Bis dahin sollten sich Shop-Betreiber und Agenturen darüber im Klaren sein, dass Flow noch nicht für den produktiven Einsatz vorgesehen ist. Damit Flow in Betrieb genommen werden kann, ist für Shop-Versionen < 6.x das Einspielen der mitgelieferten Datei setup.sql erforderlich. Hierfür kann ganz einfach der Bereich Service→Tools genutzt werden. Entwickler benötigen außerdem Grunt, für das folgende Prozedur notwendig ist (unter Linux):

curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
sudo npm install -g grunt-cli
cd /var/www/htdocs/source/Application/views/flow/
sudo npm install
grunt

Dabei entspricht /var/www/htdocs/source dem Rootverzeichnis des Shops (in dem sich die Datei config.inc.php befindet).

image

Was Verzeichnisstruktur und Dateiaufbau angeht, so haben sich die Macher ganz offensichtlich stark an Azure orientiert – damit behält Flow trotz dessen, dass es ein neues Theme ist, große Teile der Kompatibilität zu Azure bei. Der Vorteil liegt auf der Hand: Modulentwickler können sich auf die bekannte Struktur verlassen und wer Azure bereits gut kennt, sucht auch bei Flow nicht lange, um Änderungen vorzunehmen (natürlich nur im Child-Theme!).

image

Im Gegensatz zu Azure fällt bei Flow auf, dass die Views weitaus mehr Kommentare enthalten, die das Verstehen der Struktur vereinfachen.

Ein wenig Arbeit müssen Modulentwickler natürlich trotzdem investieren: vorhandene Styles müssen so angepasst werden, dass sie mit beiden Themes funktionieren bzw. gut aussehen. Gegebenenfalls hilft hier eine Weiche in den Views oder in einem Getter für das Stylesheet.

Auf dem Weg zu OXID eShop 6

Wer sich die Inhalte auf GitHub ansieht, wird feststellen, dass im Gegensatz zu früheren Versionen einige Verzeichnisse mit Großbuchstaben bezeichnet sind, im Rootverzeichnis sind das Application und Core. Hintergrund ist die Annäherung an den Coding-Standard PSR-2 (PHP Standard Recommendation 2: Coding Style Guides).

Die Änderungen belaufen sich auf weitaus mehr als nur geänderte Verzeichnis- und imageKlassennamen. Unter den alten Namen sind mittlerweile nur noch “Stellvertreter” aufzufinden, z.B. dient account.php nur noch der Abwärtskompatibilität, um auf AccountController.php zu verweisen. So bleiben alte Module mit den neuen Klassennamen kompatibel.

In den neu aufgebauten Klassen fallen außerdem die zuoberst verwendeten Namespaces auf – sie beschränken die Verwendung von Objekten auf den gegebenen Namensraum.

Ein Blick in die Zweige des Repositorys verrät außerdem weitere Punkte, an denen gearbeitet wird, etwa das Austauschen von ADOdb Lite durch Doctrine oder den vollständigen Weggang von der Datenbankengine MyISAM.

Eine finale Aussage ist hier natürlich noch lange nicht zu treffen, aber wer sich dafür interessiert, kann ja einmal im öffentlichen Repository schauen, was auf den Zweigen passiert.

Der Shop-Admin wurde nach langer Zeit einer (derzeit noch) optischen Erneuerung unterzogen und kommt nun im Flat-Design daher.


image

Die Versionsbezeichnung wurde zum Zeitpunkt der Entstehung dieses Beitrags einfach nur noch nicht nachgezogen.