Getting Started mit OXID eShop

Wenn Du erst seit Kurzem mit dem OXID eShop entwickelst, möchtest Du wahrscheinlich ein paar grundlegende Prinzipien erfahren, um Dein System updatefähig und konsistent zu halten. Bitte schau Dir die hier gelisteten Themen an, um einen Überblick darüber zu erhalten. Falls Du Fragen dazu oder auch Vorschläge für neue Themen, die hier aufgenommen werden sollten hast, wende Dich gern ans Forum oder die dev-general Mailingliste.

OXID eShop installieren

OXID eShop ist Websoftware, die größtenteils in PHP geschrieben wurde. Die Installation ist einfach und kann auf jedem Webserver durchgeführt werden, solange die Systemvoraussetzungen passen. In diesem Dokument findest Du noch detailliertere Informationen zu den Einstellungen.

Generell kann sicher gestellt werden, dass die Installation und der Betrieb eines OXID eShop perfekt bei einem der OXID-Hosting-Partner funktioniert. Bitte folge der Installationsanleitung für ein sauberes Setup.

Schnellanleitung:

  • OXID eShop herunterladen, entpacken und Daten per FTP auf den Webserver Deiner Wahl laden.
  • Eine Datenbank anlegen.
  • URL für die soeben hochgeladenen Dateien in die Adresszeile des Browsers eingeben und den Schritten der Setup-Routine folgen.

Für die Installation von Updates lest bitte im Handbuch OXID eShop aktualisieren.

Funktionalität mit Modulen ändern

Wenn Du die Standardfunktionalität einer OXID-eShop-Installation ändern willst, solltest Du Dir zunächst existierende Module (AKA Plugins oder Extensions) anschauen, denn das kann Dir eine Menge Zeit sparen. Falls keines der Module Deinen Anforderungen genügt, bietet Dir die OXID API die Möglichkeit, eigene Module zu schreiben. Das Modulsystem ist so aufgebaut, dass die Kern-Funktionalität des OXID eShop nicht angefaßt werden muss – schliesslich willst Du erreichen, dass Dein System immer leicht aktualisiert werden kann und dennoch stabil weiter läuft.

Bitte schau Dir die folgenden Anleitungen an, die beschreiben, wie OXID-eShop-Erweiterungen geschrieben werden können:

Mit Themes arbeiten

Themes bestehen aus einem Set von verschachtelten Template-Dateien (*.tpl) und legen das Layout und Design Deines OXID eShop fest. Als Template-Engine wir dafür SMARTY2 benutzt.

Die Installationsdateien werden mit dem Standardtheme „Azure“ ausgeliefert. Im Grunde gibt es zwei Wege, ein eigenes Design zu kreieren: Ein Child-Theme von „Azure“ anzulegen oder ein eigenes Template von Grund auf neu zu generieren.

Bitte entscheide Dich unbedingt für eine dieser Optionen; die originalen Template-Dateien sollten niemals verändert werden!

Das Override-System funktioniert wirklich sehr einfach: Es benutzt alle Dateien des Eltern-Ordners ausser denen, die Du in Deinem Custom-Ordner abgelegt hast. Also lege bitte alle modifizierten Dateien in einen Child-Ordner, so dass weitere Updates Deine Änderungen nicht überschreiben können.

Die andere Möglichkeit wäre, ein komplett eigenes Template-Set anzulegen und im Shop zu integrieren. Die Override-Funktionalität funktioniert auch damit gut.

Schau Dir mal diesen Blog Post über das Theme Management im OXID-eShop an.

Template debugging

Seit OXID eShop Version 4.6.0 gibt es einen einfachen Weg um herauszufinden, welches Template für welche Ansicht im Frontend verantwortlich ist. Setz einfach den Wert

$this->iDebug=8

in der config.inc.php, damit der Name der Template-Datei mit Pfad im Frontend ausgegeben werden.

Release-Vorgaben

Für den OXID eShop gibt es Major Releases (z.B. x.9.0), Minor Releases (z.B. 4.x.0) und Patches (z.B. 4.9.x). Alle diese Releases gehören jeweils zu einer Serie (z.B. 4.9 oder 4.8)

Zur Beachtung: Aktuell sind die Serien für OXID eShop Enterprise Edition (5.x) und Professional/Community Edition (4.x) unterschiedlich.

Major und Minor Releases können Änderungen in der Architektur, Datenbank, in den Core- und Sprach-Dateien, sowie in Templates (Frontend wie auch Admin) enthalten. Update Scripts dafür wie auch Beta-Versionen werden – unabhängig von der Edition –  in etwa einmal pro Jahr herausgebracht.

Hingegen werden Patch releases üblicherweise wegen Bugfixes veröffentlicht. Es gibt hier weder Änderungen in der Software-Architektur noch in der Datenbank und in den meisten Fällen nicht mal Änderungen des Frontends oder der Sprachdateien. Lediglich oder ggf. Admin-Templates und Admin-Sprachdateien könnten geändert werden. Es gibt keine Beta-Versionen, und es gibt Update-Skripts. Die Releases von Patches – unabhängig von der Edition – werden vierteljährlich veröffentlicht.

Unterstützte Versionen und kumulative Update Pakete

Unsterstützte und weiterentwickelte Versionen sind immer die letzten Patch-Releases einer Serie und der davor. Zum Beispiel, falls die Versions 4.9.5 die aktuelle Version der 4.9-Serie ist und die Version 4.8.7 der aktuelle Patch der 4.8-Serie ist wäre das nächste Patch-Release definitiv die 4.9.6 aber es gibt eine 4.8.8 nur dann, wenn ein schwerwiegender Bug oder eine Sicherheitslücke behoben wurden. In der Serie 4.7, mit dem letzten Patch 4.7.14 würden dann definitiv nicht mehr mit einem neuen Patch-Release 4.7.15 unterstützt werden.
Im Falle, dass wir eine Minor Version 4.10 herausgeben, würden wir mit einer 4.10.0 starten. Ab diesem Punkt fällt die Serie 4.8 aus dem Support und erhält keine Patches mehr. Bitte beachtet, dass kumulative Update Patches nur die letzten Sprünge in einer Serie, wie z.B. 4.8.6 auf 4.8.7 oder den Sprung auf eine neue Serie, z.B. 4.8.7 auf 4.9.5 enthalten. Es wird auch ein Paket für das Update von 4.8.7 auf 4.9.6 geben aber niemals von 4.8.5 auf 4.9.6.

Stay informed

Neue Releases werden offiziell über die Foren, über die dev-general Maillingliste, Twitter, Facebook und über Google+ angesagt. Kunden mit einem Support- und Wartungsvertrag wie auch Partner und NDA-Inhaber werden per E-Mail informiert.

Mehr darüber könnt Ihr in diesem Blogpost über den Entwicklungsprozess lesen.

Continuous integration und automatisierte Tests

Im Core-Development arbeiten wir mit Jenkins für unser unseren Continuous Integration und Continuous Distribution Prozess wie auch für das Bauen von Paketen. Mit Jenkins können wir Tests wie PhpUnit und Selenium einbauen wie auch Nightly Builds auf verschiedenen Umgebungen (PHP-Versionen) laufen lassen. Leider ist der Server nicht öffentlich erreichbar.

Falls Du Pull-Requests über GitHub einreichst, kann Dein Code auch öffentlich über Travis geprüft werden: Wird der Build rot, überprüfe noch einmal Deinen Pull-Request oder passe die Unit-Tests für die Einreichung an.

Die OXID eShop Testing Library ist dafür gedacht, von Entwicklern für Ihre OXID-eShop-Entwicklungen und oder -Erweiterungen mit neuem PhPUnit und der Integration von Mink (Selenium) oder QUnit geprüft zu werden.

Sicherheit

OXID eSales ist Hersteller von Open-Source-Software und behandelt Sicherheitsvorkommnisse natürlicherweise sehr ernsthaft. Auf folgender Seite findet Ihr Informationen darüber, wie sicherheitsrelevante Vorkommnisse gemeldet werden sollten und wie OXID mit dieser Themik verfährt:
https://oxidforge.org/en/Security

Hilfe für Benutzer und Online-Händler

Bist Du Onlinehändler und suchst nach Hilfe, schau Dich bitte auf diesen Seiten um:
https://www.oxid-esales.com/de/support-services/dokumentation-und-hilfe/willkommen/ueber-dokumentation-und-hilfe.html

Natürlich findest Du Fragen und Antworten rund um OXID eShop immer auch im Forum.

Quellcode- und Datenbank-Dokumentation

Für den OXID eShop gibt es eine sehr genaue Quellcode-Dokumentation, die pro Version automatisiert aus den PHP-Kommentaren mittels doxygen generiert wird. Hier erhälst Du einen Überblick:
https://oxidforge.org/en/source-code-documentation-overview.

Eine andere sehr wichtige Quelle könnte das Datenbank-Schema für die unterschiedlichen Serien für Dich sein:
https://oxidforge.org/en/database-documentation-overview