D3 Oxidmodule Blog

Für unser Modul "Unzer (Heidelpay)" gibt es ab sofort einen neuen Patch für die Shopversionen ab 6.0.1

Folgende Änderungen sind enthalten:

• Dokumentation für Schnittstellenwechsel ergänzt
• Preauthorisation Transaktionen werden nach erfolgreichem Abschluss mit Status "OK" markiert.
• fehlende Zahlungsarten-Templates im Admin ergänzt

Erwerben können Sie das Modul wie gewohnt über unseren Moduleshop.

Die E-Payment Komplettlösung

Posted by Daniela Biewald

Für unser Modul "Unzer (Heidelpay)" gibt es ab sofort ein neues Update für die Shopversionen ab 6.0.1 Folgende Bugfixes sind enthalten:

• Bestellungen mit Nicht-EUR-Währungen konnten fehlerhaft sein


• Bestellabschluss bei aktivem PHP Error Log schlug fehl


• Requirements für die Installation aus private Repository für OXID 6.3 aktualisiert

Erwerben können Sie das Modul wie gewohnt über unseren Moduleshop.

Die E-Payment Komplettlösung

Posted by Daniela Biewald

Für unser Modul "Auftragsmanager" gibt es ab sofort einen neuen Patch für die Shopversionen 6.2.x.

Mit dieser Version wurde ein fehlender OXID-Service im no-dev-Modus nachgerüstet.

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen

Posted by Daniela Biewald

Für unser Modul "Kundenmanager" gibt es ab sofort einen neuen Patch für die Shopversionen 6.2.x

Mit dieser Version wurde ein fehlender OXID-Service im no-dev-Modus nachgerüstet.

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen

Posted by Daniela Biewald

Für unser Modul "Kundenmanager" gibt es ab sofort einen neuen Patch für die Shopversionen 6.2.x

Folgende Änderungen sind enthalten:

• installierbar in OXID 6.2.4
• D3 Methoden in öffentlichen Klassen mit individuellen Namen versehen
• Syntaxfehler in Wochentagsbedingungsprüfung korrigiert
• erweiterte Methoden für Kompatibilität mit Elternmethoden angepasst
• Warnung bei Verwendung der Standardsprache bei CLI-Aufrufen entfernt
• Fehler bei undefinierter STDOUT Konstante behoben
• Verwendung leerer Tasklisten optimiert
• Einstellungszuordnungen optimiert

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen

Posted by Daniela Biewald

Für unser Modul "Auftragsmanager" gibt es ab sofort einen neuen Patch für die Shopversionen 6.2.x.

Folgende neue Funktionen sind enthalten:

• Warnung bei Verwendung der Standardsprache bei CLI-Aufrufen entfernt
• Fehler bei undefinierter STDOUT Konstante behoben
• Verwendung leerer Tasklisten optimiert
• Einstellungszuordnungen optimiert

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Lassen Sie wiederkehrende Aufgaben automatisch nach frei definierbaren Regeln ausführen

Posted by Daniela Biewald

Sehr geehrte Kunden,

am Freitag, dem 14.05.2021, ist unser Büro nicht besetzt.
In dringenden Fällen senden Sie bitte eine E-Mail an

Ihr D3 Team

Posted by Daniela Biewald

Für unser Modul "Importer" gibt es ab sofort ein neues Update für die Shopversionen ab 6.0.0. Folgende Änderungen sind enthalten:

• installierbar in OXID 6.2.4 und 6.3


• Adminmenüeintrag um Icon ergänzt


• fügt nur die konfigurierte Anzahl Importbilderfelder und -indizes zur Datenbank hinzu

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Modul für den Import großer Artikelmengen aus einer Excel Datei

Posted by Daniela Biewald

Für unser Modul "Login as Customer" gibt es ab sofort ein neues Update für die Shopversionen 6.2. - 6.3.

Folgende Änderungen sind enthalten:

• installierbar in OXID 6.2.4 und 6.3.0
• Analysemodus eingefügt (belässt die Berechtigungen wie bei der Originalanmeldung)

Erwerben können Sie das Modul wie gewohnt in unserem Moduleshop.

Bestellungen im Namen des Kunden ausführen

Posted by Daniela Biewald

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