May '21 4
Heute haben wir eine Empfehlung aus der Technik, die wir in unseren Projekten umsetzen und sicher auch für Andere interessant ist.

Der Shop speichert seine Einstellungen (Zugangsdaten und Konfigurationen) in der Datei config.inc.php. Darin sind sensible Daten enthalten (z.B. Zugangsdaten zur Datenbank). Deshalb soll diese Datei normalerweise nicht in die Versionsverwaltung aufgenommen werden. Nun können darin aber auch Konfigurationseinstellungen enthalten sein können, die aus diversen Gründen gesichert werden sollten.

Um diesen Konflikt zu lösen, sollten sensible projektspezifische Daten nur dynamisch in die config.inc.php eingefügt werden. Ein möglicher Weg hierfür sind die Environment-Variablen. Diese werden global oder projektspezifisch auf dem Server gesetzt und können über $_ENV['…'] in die Shopkonfiguration eingebunden werden.

Für das Setzen der ENV-Variablen gibt es folgende Wege:
  • über $ set systemweit
  • über EXPORT command z.B. in der .bashrc
  • als SetEnv in .htaccess
  • mit putenv() in PHP-Scripten
  • als .env-Datei und Einbindung über ein PHP-Paket

Die meisten Möglichkeiten haben Vor- und Nachteile. So müssen die ENV-Variablen bei Aufrufen über den Webserver sowie auch bei Aufrufen über CLI (Terminal oder auch Cron-Aufrufe) verfügbar sein. Als unkomplizierte Lösung zeigt sich bislang die Verwendung der .env-Datei in Verbindung mit phpDotEnv.

Für die Einrichtung ist Folgendes auszuführen:

Dem Shopprojekt ist dieses Paket hinzuzufügen (Alternativen mit geänderten Aufrufen sind ebenfalls verfügbar):

composer require vlucas/phpdotenv

Im Shoproot wird die Datei .env mit diesem Inhalt angelegt. Diese Datei (und auch nur diese) wird Sammelbecken solcher sensiblen Daten werden:

### important notes
# use integer 0 or 1 for boolean values instead of false or true

### required
## Database
OXID_CONF_DBHOST="127.0.0.1"
OXID_CONF_DBPORT="3306"
OXID_CONF_DBNAME=""
OXID_CONF_DBUSER="${OXID_CONF_DBNAME}"
OXID_CONF_DBPWD=""

## URL and Paths
OXID_CONF_SHOPURL="https://www.myshop.com"
OXID_CONF_SSLSHOPURL="${OXID_CONF_SHOPURL}"
OXID_CONF_SHOPDIR="/www/htdocs/www.myshop.com.com/source"
OXID_CONF_COMPILEDIR="${OXID_CONF_SHOPDIR}/tmp"

### optional (disable, if unused)
## URL and Paths
OXID_CONF_ADMINSSLURL=""

## MISC
OXID_CONF_DEBUG=0
OXID_CONF_LOGERRORS=1
OXID_CONF_ERRORREPORTING=1
OXID_CONF_DISPLAYERRORS=0
# OXID_CONF_SKIPVIEWUSAGE=0


Die config.inc.php wird gleich in den ersten Zeilen wie folgt erweitert:

require_once __DIR__.DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'vendor'.DIRECTORY_SEPARATOR.'autoload.php';
$dotenv = \Dotenv\Dotenv::createImmutable(__DIR__.'/..');
$dotenv->load();
$dotenv->required([
'OXID_CONF_DBHOST', 'OXID_CONF_DBPORT', 'OXID_CONF_DBNAME',
'OXID_CONF_DBUSER', 'OXID_CONF_DBPWD', 'OXID_CONF_SHOPURL',
'OXID_CONF_SHOPDIR', 'OXID_CONF_COMPILEDIR'
])->notEmpty();


Alle weiteren Zeilen, die sensible oder installationsabhängige Daten enthalten, werden beispielhaft so umgebaut. Dies sollte für alle oben genannten Variablen durchgeführt werden:

// Database connection information
$this->dbType = 'pdo_mysql';
$this->dbHost = $_ENV['OXID_CONF_DBHOST']; // database host name
$this->dbPort = $_ENV['OXID_CONF_DBPORT']; // tcp port to which the database is bound
$this->dbName = $_ENV['OXID_CONF_DBNAME']; // database name
$this->dbUser = $_ENV['OXID_CONF_DBUSER']; // database user name
$this->dbPwd = $_ENV['OXID_CONF_DBPWD']; // database user password
$this->sShopURL = $_ENV['OXID_CONF_SHOPURL']; // eShop base url, required
$this->sSSLShopURL = $_ENV['OXID_CONF_SSLSHOPURL']; // eShop SSL url, optional
$this->sAdminSSLURL = $_ENV['OXID_CONF_ADMINSSLURL']; // eShop Admin SSL url, optional
$this->sShopDir = $_ENV['OXID_CONF_SHOPDIR'];
$this->sCompileDir = $_ENV['OXID_CONF_COMPILEDIR'];


Damit ist die Config-Datei ausreichend bereinigt und kann so nun ins Repository übernommen werden. Die .env-Datei sollte die Berechtigung 400 erhalten und darf nicht in die Versionsverwaltung aufgenommen werden. Dies kann durch einen Eintrag in der .gitignore sichergestellt werden. Als Kopiervorlage empfiehlt sich, statt dessen eine bereinigte .env.example im Repo abzulegen.

Sofern nötig, können auch für andere Fälle ENV-Variablen abgelegt werden. Denkbar ist dies z.B. für Lizenzschlüssel, die scriptbasiert im Shop hinterlegt werden.

Diese Integration ergänzt die bestehenden ENV-Variablen, sofern diese bisher nicht gesetzt wurden. Existieren diese schon aus anderen Quellen (z.B. .htaccess), bleiben diese unangetastet. Der Vorteil ergibt sich daraus, dass serverabhängig andere Einstellungen vorgegeben werden können, ohne dass die .env-Settings diese überschreiben dürfen.

Posted by Daniel Seifert

Sep '19 4
Der aktuelle OXID-Shop besteht, im Gegensatz zu älteren Versionen, nicht aus einem großen Dateipaket, welches den gesamten Shop enthält. Vielmehr setzt sich die Shopinstallation heute aus vielen Einzelpaketen zusammen. Um dessen richtige Zusammenstellung kümmert sich Composer während der Installation.

Startpunkt für die Shopinstallation ist das Paket oxid-esales/oxideshop-project welches selbst aber keine Shopdateien enthält. Dieses bringt ausschließlich Informationen über weitere erforderliche Pakete mit (Metapackage). Installiert man dieses, werden die darin benannten Packages nachgeladen, die selbst ebenfalls weitere Pakete nachfordern können. Schlussendlich ergibt dies dann einen kompletten OXID-Shop.

OXID eShop CE originale Paketstruktur

Nun werden aber die Wenigsten diesen Basisshop verwenden. Meist werden noch Module nachinstalliert. Im besten Fall kommen diese ebenfalls als über Composer installierbare Pakete.
Wenn man diese Shop- und Modulkombination häufiger benötigt oder sich die Nachinstallation sparen will, kann man sich die individuelle Zusammenstellung auch schon passend vorbereiten. Dann steht nach der Installation sofort der komplette Shop mit allen Modulen fertig zur Verfügung.

Voraussetzungen:

  • ein über Composer zu installierender Shop
  • alle einzufügenden Module ebenfalls über Composer installierbar
  • ein öffentlich erreichbares Repository (z.B. kostenfrei bei Github)
  • einfache git-Kenntnisse
  • praktischerweise ein kostenfreies Konto bei packagist.org

Umsetzung

Um diese angepasste Installation vorzubereiten, tauschen wir einfach das oberste Package des Abhängigkeitenbaums aus und verändern dieses nach unseren Erfordernissen.

Hierzu legen wir uns einen Fork des Original-Repositories https://github.com/OXID-eSales/oxideshop_project an. Das geht bei Github ganz einfach über den Button "Fork" (rechts oben).

Den neuen Fork klonen wir zur lokalen Bearbeitung auf unseren Computer.

In unserer Kopie finden wir nun mehrere Entwicklungszweige (Branches). Im Master-Zweig befindet sich die Datei `composer.json`, in der wir die ID `oxid-esales/oxideshop-project` gegen eine neue individuelle ID austauschen. Ich habe mich dazu entschieden, den ersten Teil (den Vendor) anzupassen. Meine Version sieht dann so aus:

{
"name": "d3/oxideshop-project",
"type": "project",
"description": "This file should be used as an OXID eShop project root composer.json file. Entries provided here intended to be examples and could be changed to your specific needs.",
"license": [
"GPL-3.0-only"
]
}


Diese Datei speichern wir und übertragen diese (mit "add", "commit" und "push") in unser Repository in den Master-Zweig.

Dann wechseln wir in den Zweig für unsere aktuell gewünschte Shopversion. In meinem Fall wechsel ich zu **b-6.1-ce**, da ich später die Community Edition in Version 6.1.x installieren möchte. Auch dort ändern wir in der `composer.json` die ID auf unsere neue Version ab. Wählt für andere Shopeditionen und -versionen einfach den passenden Zweig.

Im Abschnitt `require` können wir nun zusätzlich alle Module eintragen, die automatisch mit installiert werden sollen. Die erforderlichen Angaben erfahrt ihr beim jeweiligen Modulautor. In meinem Fall habe ich unter anderem die Module Internals aus der Community nachgetragen. Alle Paket-Einträge müssen mit einem Komma getrennt sein. Nur der letzte Eintrag darf nicht mit einem Komma enden.

Der erste Eintrag (hier `oxideshop-metapackage-ce`) muss erhalten bleiben.

"require": {
"oxid-esales/oxideshop-metapackage-ce": "v6.1.3",
"oxid-community/moduleinternals": "^2.0"
}


Auch diese Änderung speichern wir und übertragen diese ins Repository.
Für andere Shopeditionen und -versionen könnt ihr die anderen Zweige ebenfalls noch anpassen.

Nun machen wir unser neues Paket der Öffentlichkeit noch bekannt.
Dazu melden wir uns auf packagist.org an und rufen "Submit" auf. Dort tragen wir die URL unseres Repositories ein. Dann wird geprüft, ob unsere vergebene ID eindeutig ist. Wenn diese schon verwendet wird, tauscht ihr die ID an den oben beschriebenen Stellen bitte noch einmal aus.
Nach einer kurzen Wartezeit könnt ihr die Shopinstallation mit diesem neuen Befehl gleich komplett ausführen:

composer create-project --no-dev d3/oxideshop-project my_oxid_eshop_project dev-b-6.1-ce

Verwendet darin natürlich eure eigene Paket-ID.

Wenn eine neue Shopversion veröffentlicht wird, gibt es auch Änderungen am oxidproject-Package. Übernehmt dann diese Änderung bitte in eure angepasste Datei, wenn ihr dorthin aktualisieren wollt.

Sonderfall "Pakete entfernen"

Über den beschriebenen Weg könnt ihr Pakete einfach hinzufügen. Etwas schwieriger wird es, wenn ihr Pakete entfernen wollt, die der Shop selbst mitbringt. Manch einer benötigt z.B. die Demodaten nicht oder möchte auf eines der Zahlartenmodule verzichten, die der Shop im Standard enthält.

Da sich diese Pakete mitten im Abhängigkeitsbaum befinden, wäre es sehr aufwändig, diese komplett aus der Installation zu lösen. Composer bietet jedoch die Möglichkeit, solche Pakete einfach zu ersetzen. Wir können dann stattdessen leere Pakete mitgeben, die sich wie zusätzliche Module installieren lassen.

Diese Ersatzpakete werden für jedes zu ersetzende Modul separat erstellt. Für die üblichen Fälle haben wir diese schon fertiggestellt:


Diese Pakete könnt ihr genauso in eure composer.json aufnehmen, wie neue Module. In unserem Installationsprojekt sieht dies dann beispielsweise so aus:

"require": {
"oxid-esales/oxideshop-metapackage-ce": "v6.1.3",
"oxid-community/moduleinternals": "^2.0",
"d3/oxideshop-demodata-ce-replacement": "*"
},


So verzichten wir in unserer Beispielinstallation auf die Demodaten.

Natürlich könnt ihr diese Ersetzungen auch jederzeit manuell in einem schon bestehenden Shop installieren.

Die Ersetzung lassen sich genauso jederzeit wieder entfernen, wenn ihr die originalen Module dennoch später einsetzen wollt.

Ersetzungen müssen natürlich nicht grundlegend leer sein. Damit könnt ihr theoretisch auch alternative Inhalte (z.B. temporäre Bugfixes o.ä.) für ein bestehendes Paket ausliefern.

Fazit

Unsere neue Paketstruktur sieht nun so aus:

OXID eShop CE angepasste Paketstruktur

Die eShop-Zusammenstellung muss nicht in Stein gemeiselt sein. Mit überschaubarem Aufwand lassen sich angepasste Installationpakete erstellen.

Die Replace-Funktion von Composer ist ein wenig dokumentiertes, aber mächtiges Werkzeug, um bestehende Paketzusammenstellungen und -inhalte zu ändern.

Das hier eben beschriebene Projekt findet ihr installationsfähig unter d3/oxideshop-project.

Wir wünschen euch viel Spaß beim Ausprobieren.

Euer Team von D3

Posted by Max Buhe

Apr '15 9
Jeder Onlineshop benötigt lt. §13 Telemediengesetz eine Datenschutzerklärung. Sicher haben Sie diese auch auf Ihrer Seite hinterlegt. Im aktuellen Magazin für Computertechnik (c't - Ausgabe 09/2015) werden in der FAQ Die wichtigsten Fragen hierzu beantwortet:

  • Was sollte die Datenschutzerklärung beinhalten?
  • Muss ich Hinweise auf Cookieverwendung angeben?
  • Was muss ich bei der Nutzung von Google Analytics beachten?
  • Gibt es Besonderheiten bei der Nutzung von Social Media-Button?
  • - ...
Den Fragenkatalog mit den dazugehörigen Antworten finden Sie unter diesem Link.

Prüfen Sie Ihre Datenschutzerklärung auch nach der Erstellung bitte regelmäßig auf Aktualität und passen Sie diese gegebenfalls an. So vermeiden Sie die Gefahr von Abmahnungen.

Posted by Daniel Seifert

Aug '14 27
Seit dem 13.07. ist die deutsche Umsetzung der EU-Verbraucherrechte-Richtlinie in Kraft. Diese verpflichtet Händler, ihre Kunden vor dem Kauf besser und umfangreicher zu informieren. Hierbei spielen besonders die Allgemeinen Geschäftsbedingungen (AGB) eine wichtige Rolle.

Was hierbei zu beachten ist und wie sich dies technisch umsetzen lässt, erklärt der Beitrag "Unwiderruflich" in der aktuellen Ausgabe der c't (19/2014) umfangreich.

Details zum Artikel inkl. Bezugsmöglichkeit finden Sie unter diesem Link.

Posted by Daniel Seifert

May '14 26
Wie Sie sicher schon der Presse entnommen haben, tritt zum (Freitag dem) 13.06.2014 das Gesetz zur Umsetzung der Verbraucherrechterichtlinie in Kraft. Dies beinhaltet ein Reihe zusätzlicher Informationspflichten im Rahmen des Onlinebestellprozesses. Details zum neuen Gesetz veröffentlichte Trusted Shops in entsprechenden Checklisten. Auch der Handelsverband Südbaden e.V. informiert in einem Merkblatt zur Umsetzung.

Posted by Daniel Seifert

Oct '11 28
OXID Buch: Titel
Lang genug bestand der Wunsch vieler Shopbetreiber nach einer umfangreichen Dokumentation und hilfreichem Nachschlagewerk für den OXID eShop.

Roman Zenner arbeitet mit Jürgen Busch nun schon eine ganze Weile am Manuskript für das erste OXID-Buch. Vor Kurzem wurde nun auch das Titelmotiv veröffentlicht.

Der bekannte Sachbuchverlag O'Reilly wird das Werk verlegen. Als Veröffentlichungstermin ist der 28. Januar 2012 geplant.

Interessenten können das Buch schon bei Amazon vorbestellen. Dort wird es dann wohl zum Preis von 34,90 Euro zu haben sein.

Posted by Daniel Seifert

Mar '11 17
Seit längerer Zeit macht die neue Shopversion 4.5 von sich Reden. Noch nicht veröffentlicht (bislang nur eine für Testzwecke veröffentlichte Beta-Fassung), warten schon viele ungeduldig auf die Veröffentlichung dieser Version. Neben einem großen Aufräumen fügt Oxid in diese Shopversion erstmalig eine neue Oberfläche für das Frontend ein, welche nun viele dynamischen Elemente enthält, die mit dem JavaScript Framework jQuery erstellt wurden.

Ich möchte es gleich vorweg nehmen: Einen Veröffentlichungstermin für die kommende Shopversion gibt es noch nicht!

Neben der Vollversion für die frische Einrichtung wird es auch wieder eine Updateversion geben, um bestehende 4er Shops auf den neuen Stand zu bringen. Dennoch muss bedacht werden, dass mit großer Wahrscheinlichkeit Ihre Templates nachgearbeitet werden müssen.

Genau dies betrifft auch unsere Module, die dann noch einmal überarbeitet werden müssen. Derzeit führen wir erste Modul-Tests mit der uns vorliegenden Vorabversion des Shops durch. Solang die neue Shopversion jedoch noch nicht endgültig veröffentlicht ist, können sich darin noch immer Änderungen ergeben. Unsere Module können wir somit leider auch erst für die neue Shopversion freigeben, wenn wir diese im finalen Oxid Shop 4.5 testen konnten.

Posted by Daniel Seifert

Dec '10 21
Alles neu macht der Dezember.

So haben wir unsere FAQ auf einen aktuellen Stand gebracht. Darin finden Sie neben Tipps und Tricks für den Shopbetrieb auch die brennendsten Fragen zu unseren Modulen und Bibliotheken beantwortet.

Die FAQ finden Sie unter http://faq.oxidmodule.com/.

Bitte unterstützen Sie uns, diese FAQ weiter zu füllen. Schreiben Sie uns Fragen zum Shop oder dessen Modulen, die dort beantwortet werden sollten.

Posted by Daniel Seifert

Oct '10 12
Version 2.3

- Varianten werden per Ajax-Technologie aktualisiert
- Nicht-JS-Fallbacklösung aktualisiert

Posted by Kristin Dartsch

Sep '10 17
neue Version 2.2:

- Punktevergabe für Kundenbewertungen eingebaut
- manuelle Punkte können nun über ein Langtextfeld im Admin kommentiert werden

Posted by Kristin Dartsch