Das Open-Source-Shop-System individuell anpassen

Bisher gab es den Oxid eShop als Professional- und Enterprise-Edition. Beide Versionen waren kostenpflichtig und wurden mit weitgehend verschlüsseltem Quellcode ausgeliefert. Daran hat sich prinzipiell nichts geändert – allerdings gibt es nun zusätzlich noch die sogenannte „Community Edition“ (CE). Diese ist kostenlos und als Open-Source-Software unter der GPL v3 lizenziert. Oxid eShop CE eignet sich gut für einen kostengünstigen Einstieg in die Welt des E-Commerce und kann relativ leicht individuell angepasst werden. Die CE hat aktuell gegenüber der kostenpflichtigen Professional Edition nur wenige Einschränkungen: Aus lizenztechnischen Gründen ist bei der Pflege von Langtexten kein WYSIWYG-Editor eingebunden. Im Oxid-Community-Forum steht hierzu aber bereits ein entsprechendes Modul zum kostenlosen Download bereit.

Außerdem ist für die CE der SOAP-ERP-Connector nicht erhältlich, der für die Anbindung von Warenwirtschaftssystemen genutzt werden kann. Aufgrund der guten Plugin-Schnittstelle ist es jedoch vergleichsweise leicht möglich, eigene Schnittstellen zu entwickeln. Einen guten Überblick über die Unterschiede zwischen den einzelnen Oxid-Versionen bietet die offizielle Feature-Liste.

Systemvoraussetzungen
  • Apache ab 1.3 mit mod_rewrite
  • PHP ab 5.2.0 – empfohlen: PHP 5.2.6
  • MySQL ab 5.0.33

Für den Apache Server müssen die Variablen „REQUEST_URI“ oder „SCRIPT_URI“ vorhanden sein.

Erforderliche PHP-Erweiterungen:
GDlib-Version 2.x, MySQL Modul für MySQL 5, bcmath, php-xml, libxml2, iconv-extension. PHP4-Kompatibilitätsmodus muss ausgeschaltet sein (php.ini: zend.ze1_compatibility_mod = OFF). allow_url_fopen oder fsockopen auf Port 80 müssen möglich sein.

Installation

Dank eines Assistenten ist die Erstinstallation schnell erledigt: Schieben sie einfach den Inhalt des entpackten Installationsarchivs in ein per Webbrowser erreichbares Verzeichnis (z. B. /oxid/), legen Sie eine MySQL-Datenbank an und halten Sie die Zugangsdaten griffbereit.

Das gerade angelegte Verzeichnis muss nun per Browser über die URL „http://[URL]/oxid/“ aufgerufen werden, worauf sich der Installationsassistent öffnet. Hier wählen Sie die Sprache für die Installationsmenüs sowie den eigenen Standort aus. Diesen können Sie nachträglich im Administrationsbereich unter „Stammdaten -> Grundeinstellungen -> System“ ändern.

Nach dem Akzeptieren der Lizenzbedingungen in Schritt 2 geht es weiter zu Schritt 3, wo Sie die Datenbankzugangsdaten eintragen müssen. In Schritt 4 können Sie die Installationspfade noch einmal kontrollieren und gegebenenfalls korrigieren. Bestätigen Sie anschließend mit „Daten jetzt speichern“.

Der Installationsassistent unterstützt den Shop-Betreiber bei der Einrichtung von Oxid eShop.

Der Installationsassistent unterstützt den Shop-Betreiber bei der Einrichtung von Oxid eShop.

Abschließend erscheint Schritt 5, der die erfolgreiche Installation bestätigt. Den Shop und Adminbereich erreichen Sie über die dort erscheinenden Links. Benutzername und Passwort für den Adminbereich lauten standardmäßig „admin“ und „admin“, beide können und sollten Sie in der Benutzerverwaltung ändern.

Backend-Einstellungen

Die zahlreichen Optionen im Adminbereich des Oxid eShops können im Rahmen dieses Artikels nicht umfassend erläutert werden. In vielen Fällen hilft aber ein Klick auf den Link „Hilfe starten“ am unteren Fensterrand. Auch das Forum und das offizielle Handbuch liefern bei Bedarf gute Hilfe. Einige Optionen aus dem Bereich „Stammdaten“ werden in der folgenden Tabelle kurz erläutert, da sie für die Entwicklung eigener Oxid-Module von Bedeutung sein können:

Stammdaten -> Grundeinstellungen -> Stamm
Im Rahmen von Entwicklung und Tests eigener Erweiterungen sollten Sie den Produktivmodus nicht aktivieren. Sobald dieses Häkchen gesetzt wird, sind einige zusätzliche Caching-Mechanismen am Werk, die beim Testen und Debuggen eher stören. Im Live-Betrieb sollte Sie den Produktivmodus aber unbedingt aktivieren, um die Performance des Shops zu steigern.
Stammdaten -> Grundeinstellungen -> Einstell. -> Administrationsbereich -> Zusätzliche Informationen vom OXID Server laden
Wenn Sie diese Checkbox aktivieren, lädt der Shop im Adminbereich (nach erneutem Login) ein ergänzendes Menü „E-Commerce Services“. Dahinter verbergen sich zum Teil Dienste, die nur im Zusammenhang mit einer Registrierung auf der Oxid-eigenen Serviceplattform „OXID eFire“ nutzbar sind. Es erscheinen hier weitere Menüpunkte für die Einbindung von Affiliate-Programmen, des Trusted-Shops-Siegels sowie des Econda Shop Monitors.
Stammdaten -> Grundeinstellungen -> Performance
Die Performance-Einstellungen ermöglichen es, einzelne Features und Funktionen des Shops – sofern diese nicht benötigt werden – gezielt abzuschalten und so Ressourcen freizugeben

Templates

Der Oxid eShop verwendet die Template-Engine Smarty. Die zugehörigen Templates finden Sie im Verzeichnis „/out/basic/tpl“ (Frontend) und „/out/admin/tpl“ (Backend). Es handelt sich um reine HTML-Dateien, in denen mit Hilfe von Smarty-Tags die Funktionalität zum Einbinden der Inhalte integriert ist. Der optischen Anpassung sind somit keine Grenzen gesetzt, sofern die entsprechenden Smarty-Tags korrekt übernommen werden.

Architektur

Anders als Magento, das auf dem Zend Framework basiert, bringt der Oxid eShop sein eigenes Framework mit, das konsequent dem MVC-Pattern entspricht. Die zugehörigen View-Klassen finden sich im Verzeichnis „/views“, die Model-Klassen liegen im Verzeichnis „/core“. Beide Klassengruppen können in Form von Modulen überladen werden, wodurch sich nahezu unbegrenzte Anpassungs- und Erweiterungsmöglichkeiten ergeben. Beim Verständnis der Klassenstrukturen hilft die API-Dokumentation.

Oxid eShop basiert auf PHP 5, ist durchgängig objektorientiert programmiert und macht regen Gebrauch vom Konzept der Getters and Setters – Objekteigenschaften sind also in der Regel nicht direkt verfügbar (protected), sondern müssen über eine get()- bzw. set()-Methode angesprochen werden.

Modulschnittstelle

Wie bereits erwähnt, können fast alle view- und core-Klassen in Form von Modulen überladen werden. Zu diesem Zweck legt man eine eigene PHP-Datei unterhalb des Verzeichnisses „/modules“ an und definiert dort eine eigene Klasse, die als Extension einer bereits vorhandenen Klasse deklariert wird. Zusätzlich muss dann ein solches Modul noch im Adminbereich angemeldet werden, damit der Shop weiß, dass er bei der Instantiierung eines neuen Objekts gegebenenfalls auch die Extensions im „modules“-Verzeichnis berücksichtigen muss. Wie das im einzelnen funktioniert, zeigt das folgende Praxis-Beispiel.

CMS-Tuning – ein Modulbeispiel

Im Adminbereich unter „Kundeninformationen -> CMS-Seiten“ finden Sie ein kleines CMS, mit dem einzelne Content-Bausteine entweder als komplette Seite oder als Snippet in das Shop-Frontend integriert werden können. Wählt man beim Anlegen eines solchen Bausteines die Option „Hauptmenü“, so erscheint im Shop rechts oben neben AGB und Impressum ein weiterer Link. Ziel ist es nun, mehrere Ebenen von solchen CMS-Seiten zu realisieren, die jeweils per Untermenü aufeinander verweisen. Die gewählte Umsetzung ist dabei als Skizze zu verstehen, die lediglich dazu dienen soll, einige Grundprinzipien der Modulentwicklung zu demonstrieren. Es ist keine perfekte Lösung für die genannte Aufgabe. Als Basis der Code-Beispiele dient Oxid eShop CE in der Version 4.0.0.2.

Um einzelne CMS-Einträge in Form einer Elternbeziehung einander zuordnen zu können, benötigt man zunächst ein weiteres Feld in der Tabelle „oxcontents“. Dieses kann zum Beispiel via phpMyAdmin mit folgendem SQL-Befehl geschehen:

ALTER TABLE `oxcontents` ADD `MY_PARENTIDENT` VARCHAR( 32 ) NOT NULL ;

Das neue Feld soll bei Kind-Elementen die „OXLOADID“ des übergeordneten Elements aufnehmen. Zu diesem Zweck machen Sie das gerade neu angelegte Tabellenfeld nun im Admin pflegbar. Dazu ändern Sie das Admin-Template „content_main.tpl“ und fügen nach Zeile 131 (</tr>) den folgenden Block ein:

<tr>
        <td class="edittext">parent ident</td>
         <td class="edittext">
         <input type="text" class="editinput" size="28"
					maxlength="[{$edit->oxcontents__my_parentident->fldmax_length}]"
					 name="editval[oxcontents__my_parentident]"
					value="[{$edit->oxcontents__my_parentident->value}]" [{ $readonly }]>
          </td>
</tr>

Nach diesen Änderungen sollte einmal das tmp-Verzeichnis geleert werden, da hier Objektstrukturen gecached werden. Als nächstes legen Sie die beiden neuen Content-Bausteine „Test 1“ und „Test 1.1“ an und definieren sie als Hauptmenü-Bausteine. Manuell wird für den ersten Baustein als Ident (entspricht der OXLOADID) der Wert „test_1“ eingetragen und gespeichert. Beim zweiten Baustein soll in das neue Feld „parent ident“ die Ident des ersten Bausteins eingetragen werden, also „test_1“:

Einzelne CMS-Bausteine im Admin hinzufügen

Nach einer kleinen Änderung am Template können im Adminbereich einzelne CMS-Bausteine einander zugeordnet werden.

Nach dem Speichern sollten Sie kontrollieren, ob der Inhalt des Felds in der Datenbank gespeichert wurde. Wie Sie sehen, ist die Erweiterung von Tabellen sowie die Pflege und Verwendung eigener Tabellenfelder sehr einfach, sofern man sich im Template an die Standardobjektstruktur „[Objektname]->[Tabellenname]__[Feldname]->value“ des Oxid-Shops hält.

Nun brauchen Sie noch zwei Moduldateien, um zum einen dafür zu sorgen, dass der CMS-Baustein „Test 1.1“ nicht als Hauptmenüpunkt im Shop erscheint und zum anderen, dass bei der Anzeige des Bausteins „Test 1“ die Information über den vorhandenen Kind-Baustein „Test 1.1“ zur Verfügung steht, damit darauf verlinkt werden kann.

Ausblenden der CMS-Untermenüpunkte

Die Liste der als Hauptmenüpunkte angezeigten CMS-Links wird mit der Methode „_loadMenue()“ in der core-Klasse „oxcontentlist“ geladen. Diese Methode muss nun im Rahmen eines Moduls überladen werden. Dazu wird innerhalb des Verzeichnisses „modules“ ein neues Unterverzeichnis „my_cms“ erstellt und in diesem wiederum eine neue Datei namens „my_cms_oxcontentlist.php“. Der Inhalt dieser Datei sollte folgendermaßen aussehen:

<?php
class my_cms_oxContentList extends my_cms_oxContentList_parent
{
    protected function _loadMenue( $iType, $sSQLAdd = null )
    {
    	if($iType == 1) {
	    		$sSQLAdd .=" and my_parentident = ''";
        }
        parent::_loadMenue($iType, $sSQLAdd);
    }
}

Dass diese Klasse nicht direkt eine Extension von „oxContentList“ ist, hängt damit zusammen, dass der Shop automatisch transparente Klassen von Modulklassen generiert, wodurch folgende Struktur entsteht:

  • my_moduleClass extends my_moduleClass_parent
  • my_moduleClass_parent extends originalClass

Auf diese Art und Weise können beliebig viele Module zu ein und derselben Ausgangs-Klasse angelegt werden, die dann miteinander verkettet werden können. Dazu gleich mehr.

Die Variable „$iType“ kann die Werte 0, 1, 2 oder 3 haben, je nachdem ob der CMS-Baustein als Snippet, Hauptmenüpunkt, Kategorie oder Manuell definiert wurde. Die if-Abfrage sorgt dafür, dass im Falle eines als Hauptmenüpunkt definierten CMS-Eintrags nur solche Datensätze geladen werden, die keine „parent id“ haben. Auf diese Weise wird der CMS-Baustein „Test 1.1“ im Hauptmenü nicht angezeigt. Damit das neue Modul auch wirksam wird, muss es noch registriert werden. Dies machen Sie im Adminbereich unter „Stammdaten -> Grundeinstellungen -> System -> Module“. In der Box „Installierte Module in Ihrem Shop“ fügen Sie folgende neue Zeile ein:

oxcontentlist => my_cms/my_cms_oxcontentlist

Links steht zunächst der Name der Original-Klasse. Nach dem Pfeil folgt der Pfad zu der Moduldatei, relativ zum Verzeichnis „modules“ und ohne die Extension „.php“. Gäbe es weitere Module zur Klasse „oxcontentlist“, so würden diese mittels des &-Zeichens einfach angehängt, also zum Beispiel so:

oxcontentlist => my_cms/my_cms_oxcontentlist&my_test/test

Anzeige eines CMS-Untermenüs

Innerhalb der angezeigten Content-Seite fehlt noch die Information, ob es zu dieser Seite Unterseiten gibt. Hierfür erstellen Sie ein Modul der View-Klasse „content.php“. Legen Sie dazu zunächst eine neue Datei namens „my_cms_content.php“ innerhalb des Verzeichnisses „/modules/my_cms“ mit folgendem Inhalt an:

<?php
class my_cms_Content extends my_cms_Content_parent
{
 public function render()
 {
 $this->_sThisTemplate = parent::render();
 $sSelect = "select oxid from oxcontents
   where my_parentident = '".$this->getContent()->oxcontents__oxloadid->value."'";
 $rs = oxDb::getDb()->Execute($sSelect);
 if($rs != false && $rs->RecordCount() > 0) {
   $aChilds = array();
     while(!$rs->EOF) {
    $oContent = oxNew("oxcontent");
    $oContent->load($rs->fields[0]);
    $aChilds[ ] = $oContent;
    $rs->MoveNext();
  }
  $this->_aViewData['aChilds'] = $aChilds;
 }
 return $this->_sThisTemplate;
 }
}

Die Datenbankabfrage erfolgt über das ADODB-Objekt, das in Form von „oxDb::getDb()“ global zur Verfügung steht. Geholt werden hier alle IDs von CMS-Einträgen, die im Feld „my_parentid“ die ID des aktuellen CMS-Bausteins haben. Anders gesagt: Es werden alle Kind-Einträge zum aktuellen Baustein geholt. Innerhalb der while-Schleife wird anhand der jeweiligen ID ein neues Content-Objekt geladen und in das Array „$aChilds“ geschrieben. Mittels „$this->_aViewData[‚aChilds‘] = $aChilds;“ wird dieses Array als Template-Variable verfügbar gemacht.

Ausgabe im Template

Es fehlt nun noch die Anzeige des Untermenüpunktes im Template „content.tpl“. Dafür öffenet man die entsprechende Templatedatei mit dem Editor und fügt unmittelbar unter der Zeile „<div class=“box“>“ (Zeile 6) folgenden Block ein:

[{if $aChilds}]
 <div style="border:1px solid #ccc">
  Untermen&uuml:<br />
  [{foreach from=$aChilds item=oContent}]
  <a href="[{ $oViewConf->getSelfLink() }]cl=content&amp;tpl=[{$oContent->oxcontents__oxid->value}]">
 - [{$oContent->oxcontents__oxtitle->value}]</a><br />
 [{/foreach}]
 </div>
 <br />
[{/if}]

Jetzt werden, sofern vorhanden, auf jeder Content-Seite oben die zugeordneten Unterseiten als Links angezeigt. Auch wenn vielleicht nicht alle Einzelheiten dieses Modulbeispiels sofort verständlich sind, so sollte das Grundprinzip der Modulentwicklung für den OXID eShop deutlich geworden sein. Für ein tiefer gehendes Verständnis der verwendeten Objekte und Methoden empfiehlt sich in erster Linie das genaue Studium der originalen view- und core-Klassen der Software.



0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.