Update PHPMailer für ältere OXID Versionen

Hintergrund

Zum Ende des vorangegangenen Jahres wurde eine Sicherheitslücke der PHPMailer-Bibliothek bekannt gegeben. Da diese auch im OXID eShop eingesetzt wird, wurde in einem ausführlichen Beitrag seitens OXID auch eine kurze Anleitung zum Update des PHPMailers auf Version 5.2.21 veröffentlicht.
Es wird darauf hingewiesen, dass durch das OXID eShop framework die Basisinstallation trotz dieser Sicherheitslücke absolut sicher ist. Einzig durch externe Frontend-Module, welche die PHPMailer- Bibliothek direkt ansprechen, besteht ein eventuelles Sicherheitsrisiko. Um diese Möglichkeit komplett auszuschließen, wird mitgeteilt, dass die Klassen class.phpmailer.php und class.smtp.php durch die aktuellste Version ausgetauscht werden sollen.
(Quelle: https://oxidforge.org/en/phpmailer-5-2-21-remote-code-execution-oxid-eshop-is-safe.html)

Update für ältere OXID eShop Versionen (< 4.9.8)

Bei älteren Installationen bis zur Version 4.9.7 reicht der Austausch der beiden Klassen jedoch nicht aus. Für den Fall, dass der Mailversand über SMTP erfolgt, sind zusätzliche Anpassungen am Code notwendig. Bis zur Version 4.9.8 wurde in den OXID Core-Klassen oxEmail sowie auch oxDb jeweils nur die PHPMailer-Klasse eingebunden.

oxemail.php:

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;

oxdb.php:

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;

Bei älteren Versionen des PHPMailers ist dies auch ausreichend, da die Klasse SMTP bei Aufruf der Funktion SmtpSend() in der PHPMailer-Klasse inkludiert wird:
require_once $this->PluginDir . ‚class.smtp.php‘;
In der aktuellsten PHPMailer-Bibliothek werden jedoch die einzelnen Klassen (darunter auch SMTP) nicht mehr innerhalb von class.phpmailer.php‘, sondern über eine eigene autoloader-Klasse initialisiert (Quelle: https://github.com/PHPMailer/PHPMailer/wiki/Tutorial).
Um die Funktionalität von PHPMailer bei älteren OXID eShops komplett zu gewährleisten, ist daher eine weitere Anpassung notwendig. Zusätzlich zur beschriebenen Aktualisierung, muss in den beiden OXID Core-Klassen noch class.smtp.php eingebunden werden. Der folgende Code zeigt, wie die aktualisierte Klasse SMTP in OXID, Version 4.9.7, verwendet werden kann. Für weit ältere Installationen ist es nötig, sich an der schon bestehenden Einbindung der PHPMailer-Klasse zu orientieren und diese für class.smtp.php zu adaptieren.

Klasse oxEmail (v4.9.7):

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;
require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.smtp.php“;

Klasse oxDb (v4.9.7):

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;
include_once getShopBasePath() . ‚core/phpmailer/class.smtp.php‘;

 

OXID EE MySQL Master/Slave Setup

oxid-news

Hintergrund

Der OXID eShop unterstützt in der Enterprise Edition (EE) MySQL Master/Slave Datenbank-Setups, was für sog. „Read-/Write-Splitting“ genutzt werden kann. Dadurch ist es möglich, Datenbank-Abfragen auf mehrere Datenbank-Server zu verteilen, um damit im Idealfall an Datenbank-Performance zu gewinnen und Shops gerade zu Lastzeiten schneller zu machen.
Read-/Write-Splitting kann ebenso helfen, das Shop-Frontend performant zu halten, wenn z.B. gerade Massen-Updates über ERP- oder PIM-Schnittstellen im Shop-Backend laufen, welche mit vielen Insert-Statements nicht selten Datenbank-Locks auslösen, die sich dann auch auf das Frontend auswirken können. Im schlimmsten Fall ist der Shop zeitweise nicht mehr aufrufbar, weil gleichzeitig zu den laufenden Insert- und Update-Statements aus einer gelockten Datenbank-Tabelle gelesen werden soll.

Master/Slave Setup in OXID

Im OXID eShop ist die Konfiguration der Master-/Slave-Verteilung sehr einfach, hier genügt es, in der allgemeinen Shop-Konfigurationsdatei „config.inc.php“ die einzelnen Server einzutragen.

Hierzu gibt es zwei Variablen, die gesetzt werden müssen:

$this->aSlaveHosts = array('localhost', '192.168.0.10:3306', '192.168.0.11:3307');
$this->iMasterSlaveBalance = 0;

Im Array „aSlaveHosts“ können beliebig viele IP-Adressen (mit optionalem Port) eingetragen werden. Auch der Master wird hier als erster Wert hinterlegt.
Der zweite Parameter, „iMasterSlaveBalance“ legt fest, wie die Verteilung der Abfragen zwischen Master und Slave ist.
Ein Wert von „0“ bedeutet hier, dass alle Abfragen auf den Slaves stattfinden und auf den Master nur schreibend zugegriffen wird.

Für Shops mit regelmässig laufenden Artikeldaten-Updates über Schnittstellen zu Warenwirtschaftssystemen usw. sollte diese Einstellung verwendet werden, damit sichergestellt ist, dass auch bei Massen-Updates die Lesezugriffe aus dem Shop-Frontend nicht in Mitleidenschaft gezogen werden.

Das Setup der Datenbankserver an sich geht über den Umfang dieses Artikels hinaus, hierzu finden sich z.B. sehr gute Infos unter https://www.thomas-krenn.com/de/wiki/MySQL_Replikation

Tipps und Tricks für das MySQL Master/Slave Setup

Der OXID EE Shop selbst ist bereits sehr gut für die Master-/Slave-Aufteilung optimiert, sobald Slaves konfiguriert sind, hält sich der Shop strikt an die definierte Aufteilung und führt z.B. Lesezugriffe immer auf den Slaves aus.

Für eigene Erweiterungen des Shops sollte man sich hier am OXID Standard orientieren, hier ist es v.a. wichtig, für Lese- oder Schreibzugriffe die richtigen Methoden des OXID Datenbank-Adapters zu verwenden.

Prinzipiell gilt: für Lesezugriffe sollte man immer die „select()“-Methode der „oxDb“-Klasse nutzen, da nur diese wirklich standardmässig dezidiert auf die Slaves zugreift.

$oRs = oxDb::getDb()->select("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Slave

Man kann allerdings als dritten Parameter „false“ übergeben, um dennoch vom Master zu lesen – Standard ist jedoch „true“ und damit „Slave:

public function select($sSql, $aParams = false, $blType = true)

Auch die Methoden „getOne()“, „getArray()“, „getAssoc()“, „getRow()“ und „getAll()“ selektieren standardmässig von den Slaves, können aber ebenfalls per Parameter auf den Master „umgebogen“ werden bei Bedarf.

Nutzt man hingegen die Methoden „execute()“ oder „query()“, geht das SQL-Statement ausnahmslos an den Master-Server!

$oRs = oxDb::getDb()->query("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Master

Problematisch sind bei Master-/Slave-Setups oft SQL-Fehler, welche zu Fehlermeldungen auf Datenbank-Ebene führen. MySQL ist hier meist recht rigoros und beendet die Synchronisation zwischen Master und Slaves. Diese muss dann vom System-Administrator wieder manuell aktiviert werden.

Man sollte das System also erst auf Herz und Nieren testen und die Synchronisation im Testbetrieb beobachten, um zu entscheiden, ob es hier kritische Stellen im Shop gibt und regelmässige SQL-Fehler auftauchen.

Handelt es sich um temporäre, „unwichtigere“ Daten (z.B. Session-Einträge, Captcha-Codes o.ä.), kann man ggf. in Erwägung ziehen, die betroffenen Tabellen aus der Synchronisation herauszunehmen bzw. MySQL-Fehler für diese Tabellen bei der Synchronisation zu ignorieren, siehe z.B. https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_slave-skip-errors
Ausserdem kann helfen, die Slaves explizit als „read_only“ zu konfigurieren, damit es keine „versehentlichen“ Schreibversuche auf die Slaves gibt.

MySQL Master/Slave in OXID – Fazit

Mit der Option für Master-/Slave-Setups bietet OXID gerade für große Shops mit regelmässigen, umfangreichen Datenänderungen über Drittsysteme einen erheblichen Performance-Hebel.
Weiss man um die technischen Hintergründe des OXID-Datenbankadapters und kennt die möglichen Fehlerquellen auf Seiten der MySQL-Datenbank-Synchronisation, spricht nichts dagegen, dieses Feature im produktiven Einsatz zu nutzen.
Hat man dann noch einen technisch versierten Hoster an seiner Seite, kann eigentlich nichts mehr schiefgehen :)

Hoffentlich hat dieser Artikel dazu beigetragen, die technischen Hintergründe in Bezug auf OXID EE und das Mysql Master-/Slave-Setup zu erhellen!

OXID EE MySQL Master/Slave Setup

oxid-news

Hintergrund

Der OXID eShop unterstützt in der Enterprise Edition (EE) MySQL Master/Slave Datenbank-Setups, was für sog. „Read-/Write-Splitting“ genutzt werden kann. Dadurch ist es möglich, Datenbank-Abfragen auf mehrere Datenbank-Server zu verteilen, um damit im Idealfall an Datenbank-Performance zu gewinnen und Shops gerade zu Lastzeiten schneller zu machen.
Read-/Write-Splitting kann ebenso helfen, das Shop-Frontend performant zu halten, wenn z.B. gerade Massen-Updates über ERP- oder PIM-Schnittstellen im Shop-Backend laufen, welche mit vielen Insert-Statements nicht selten Datenbank-Locks auslösen, die sich dann auch auf das Frontend auswirken können. Im schlimmsten Fall ist der Shop zeitweise nicht mehr aufrufbar, weil gleichzeitig zu den laufenden Insert- und Update-Statements aus einer gelockten Datenbank-Tabelle gelesen werden soll.

Master/Slave Setup in OXID

Im OXID eShop ist die Konfiguration der Master-/Slave-Verteilung sehr einfach, hier genügt es, in der allgemeinen Shop-Konfigurationsdatei „config.inc.php“ die einzelnen Server einzutragen.

Hierzu gibt es zwei Variablen, die gesetzt werden müssen:

$this->aSlaveHosts = array('localhost', '192.168.0.10:3306', '192.168.0.11:3307');
$this->iMasterSlaveBalance = 0;

Im Array „aSlaveHosts“ können beliebig viele IP-Adressen (mit optionalem Port) eingetragen werden. Auch der Master wird hier als erster Wert hinterlegt.
Der zweite Parameter, „iMasterSlaveBalance“ legt fest, wie die Verteilung der Abfragen zwischen Master und Slave ist.
Ein Wert von „0“ bedeutet hier, dass alle Abfragen auf den Slaves stattfinden und auf den Master nur schreibend zugegriffen wird.

Für Shops mit regelmässig laufenden Artikeldaten-Updates über Schnittstellen zu Warenwirtschaftssystemen usw. sollte diese Einstellung verwendet werden, damit sichergestellt ist, dass auch bei Massen-Updates die Lesezugriffe aus dem Shop-Frontend nicht in Mitleidenschaft gezogen werden.

Das Setup der Datenbankserver an sich geht über den Umfang dieses Artikels hinaus, hierzu finden sich z.B. sehr gute Infos unter https://www.thomas-krenn.com/de/wiki/MySQL_Replikation

Tipps und Tricks für das MySQL Master/Slave Setup

Der OXID EE Shop selbst ist bereits sehr gut für die Master-/Slave-Aufteilung optimiert, sobald Slaves konfiguriert sind, hält sich der Shop strikt an die definierte Aufteilung und führt z.B. Lesezugriffe immer auf den Slaves aus.

Für eigene Erweiterungen des Shops sollte man sich hier am OXID Standard orientieren, hier ist es v.a. wichtig, für Lese- oder Schreibzugriffe die richtigen Methoden des OXID Datenbank-Adapters zu verwenden.

Prinzipiell gilt: für Lesezugriffe sollte man immer die „select()“-Methode der „oxDb“-Klasse nutzen, da nur diese wirklich standardmässig dezidiert auf die Slaves zugreift.

$oRs = oxDb::getDb()->select("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Slave

Man kann allerdings als dritten Parameter „false“ übergeben, um dennoch vom Master zu lesen – Standard ist jedoch „true“ und damit „Slave:

public function select($sSql, $aParams = false, $blType = true)

Auch die Methoden „getOne()“, „getArray()“, „getAssoc()“, „getRow()“ und „getAll()“ selektieren standardmässig von den Slaves, können aber ebenfalls per Parameter auf den Master „umgebogen“ werden bei Bedarf.

Nutzt man hingegen die Methoden „execute()“ oder „query()“, geht das SQL-Statement ausnahmslos an den Master-Server!

$oRs = oxDb::getDb()->query("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Master

Problematisch sind bei Master-/Slave-Setups oft SQL-Fehler, welche zu Fehlermeldungen auf Datenbank-Ebene führen. MySQL ist hier meist recht rigoros und beendet die Synchronisation zwischen Master und Slaves. Diese muss dann vom System-Administrator wieder manuell aktiviert werden.

Man sollte das System also erst auf Herz und Nieren testen und die Synchronisation im Testbetrieb beobachten, um zu entscheiden, ob es hier kritische Stellen im Shop gibt und regelmässige SQL-Fehler auftauchen.

Handelt es sich um temporäre, „unwichtigere“ Daten (z.B. Session-Einträge, Captcha-Codes o.ä.), kann man ggf. in Erwägung ziehen, die betroffenen Tabellen aus der Synchronisation herauszunehmen bzw. MySQL-Fehler für diese Tabellen bei der Synchronisation zu ignorieren, siehe z.B. https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_slave-skip-errors
Ausserdem kann helfen, die Slaves explizit als „read_only“ zu konfigurieren, damit es keine „versehentlichen“ Schreibversuche auf die Slaves gibt.

MySQL Master/Slave in OXID – Fazit

Mit der Option für Master-/Slave-Setups bietet OXID gerade für große Shops mit regelmässigen, umfangreichen Datenänderungen über Drittsysteme einen erheblichen Performance-Hebel.
Weiss man um die technischen Hintergründe des OXID-Datenbankadapters und kennt die möglichen Fehlerquellen auf Seiten der MySQL-Datenbank-Synchronisation, spricht nichts dagegen, dieses Feature im produktiven Einsatz zu nutzen.
Hat man dann noch einen technisch versierten Hoster an seiner Seite, kann eigentlich nichts mehr schiefgehen :)

Hoffentlich hat dieser Artikel dazu beigetragen, die technischen Hintergründe in Bezug auf OXID EE und das Mysql Master-/Slave-Setup zu erhellen!

 

shoptimax und OXID veröffentlichen neue PIM-Schnittstelle: Reibungsloser Import von Produktdaten aus mediaSolution3 in OXID eSales

shoptimax hat in enger Zusammenarbeit mit OXID eSales und Stämpfli eine neue PIM-Schnittstelle entwickelt. Dank dieser ist die tiefe Integration der PIM-Software mediaSolution3 in OXID eSales Shopsysteme möglich.

smx-schnittstelle_2

Bei der Umsetzung von Webshops ist es wichtig, immer das große Ganze im Auge zu behalten – allein mit der Installation eines Shopsystems ist es nicht getan. Detaillierte, vollständige und für die Kaufentscheidung ausschlaggebende Informationen sind das A und O, um Shopkunden von den angebotenen Produkten und letztlich vom Kauf zu überzeugen. „Um erfolgreich im E-Commerce agieren zu können, benötigen unsere Kunden perfekte Schnittstellen zu ihren PIM-Backendsystemen. Erst dadurch können Produktdaten in Shops entsprechend angereichert und deren bestmögliche Qualität gewährleistet werden“, so Friedrich Schreieck, Geschäftsführer der shoptimax GmbH. „Dank der von Stämpfli, OXID und uns gemeinsam neu entwickelten Schnittstelle können hochwertige Produktdaten aus dem PIM-System mediaSolution3 nun mühelos in OXID eShops importiert werden“, so Schreieck weiter.

Drei Partner für einen gemeinsamen Kundenerfolg

Ein Schwerpunkt der Arbeit von shoptimax liegt seit Gründung des Unternehmens in der Konzeption und Umsetzung intelligenter Module, die für die Prozess- und Erfolgsoptimierung von Onlineshops unerlässlich sind – erfolgreich darin ist shoptimax auch dank seiner zahlreichen langjährigen Kooperationen und Partner.

„Als erfahrener OXID Solution Partner – Enterprise Level entwickelt das Team des E-Commerce Spezialisten shoptimax bereits seit dem Jahr 2004 gemeinsam mit uns innovative und einzigartige Lösungen rund um OXID“ bekräftigt Markus Baars, Partnermanager bei OXID eSales. Auch Hansjörg B. Gutensohn, Geschäftsführer der Stämpfli GmbH, und Friedrich Schreieck, Geschäftsführer der shoptimax GmbH, sind vom Motto „Gemecinsam stark“ überzeugt: „Die Zusammenarbeit zwischen shoptimax, Stämpfli und OXID hat für alle Seiten positive Effekte, da jeder vom Know-how des anderen profitieren und sich so auch selbst weiterentwickeln kann. Gewinner sind in jedem Fall unser aller Kunden.“ Die von OXID zertifizierte Schnittstelle steht ab sofort allen OXID-Solution Partnern zur Verfügung.

Die mediaSolution3 – OXID Schnittstelle

Die neue Schnittstelle sorgt für eine schnelle und komfortable Anbindung von OXID an die PIM-Software mediaSolution3 des Bregenzer IT-Unternehmens Stämpfli.

Mittels der unidirektionalen mediaSolution3 – OXID Schnittstelle werden Artikeldaten in OXID eSales Shops um relevante Daten und technische Attribute angereichert. Implementierte Anreicherungs-Optionen für OXID eSales Shop Artikel sind dabei bis zu 8 Artikelbilder, Artikel Kurz- und Langbeschreibungen, Meta Keywords, Descriptions und Meta Titles, Produktbeschreibungen sowie Artikelfarben. Hinzu kommen außerdem allgemeine technische Artikeleigenschaften / OXID Attribute, Artikel-Volumen, Videos und Media Dateien, Herstellerlogos und Kategoriezuordnungen sowie der Import von Lieferanten und Herstellern. Dank der neuen Schnittstelle ist die Qualität der in mehreren Stufen aus dem PIM-System exportierten Daten auch für größere Webshop-Lösungen geeignet. da sie hoch granular aufbereitet und transformiert werden. Das OXID Shopsystem empfängt schließlich die Produktdaten und integriert diese den Kundenanforderungen entsprechend nahtlos und effizient.

Ausbau der OXID-Kompetenzen – shoptimax Entwickler absolvieren Seminar bei der OXID Academy

Matthias Zistler und Alexander Kolinko, beide Entwickler beim Nürnberger E-Commerce-Spezialisten shoptimax, absolvierten Mitte Juni an der OXID Academy im Novotel Freiburg erfolgreich das Workshop-Seminar „OXID eShop Zertifizierung Technik Modul 1 – Modul 3“. Die grundlegende Zielsetzung des dreitägigen Technik-Seminars der OXID eSales AG war die Vermittlung von Basiswissen insbesondere im Bereich Anwendung und Anpassung anhand der OXID eShop Professional Edition, die Architektur des Shopframeworks sowie die modularen Erweiterungsmöglichkeiten. Zudem wurden die Funktionalitäten der Enterprise Edition erörtert und sich daraus ergebende Möglichkeiten vermittelt.

oxid_zertifikat_zistler_4_web oxid_zertifikat_zistler_5_web

oxid_zertifikat_kolinko_4_web oxid_zertifikat_kolinko_5_web

Drei Tage voll mit OXID-Know-how

Der erste Seminartag beinhaltete die Vermittlung grundlegenden Basiswissens mit Einblicken in die Bereiche „Anwendung“ und „einfach Anpassung“ der Shopsoftware. Als Beispiel diente die OXID eShop Professional Edition. Der zweite Tag stand dann ganz im Zeichen der Praxis. Das in der Theorie Erlernte wurde mit Fokus auf die Programmierung und der intensiven Beschäftigung mit dem Thema modulare Erweiterungen der Professional Edition umgesetzt. Am dritten Tag gab es eine Einführung in die Besonderheiten und Möglichkeiten der OXID eShop Enterprise Edition. Die workshopartige Gestaltung des dritten Moduls rief nicht nur die erworbenen Kenntnisse in Erinnerung, diese wurden auch mit dem Fokus auf ganz spezielle Anwendungsfälle in Form von praktischen Aufgaben und Beispielen erweitert.

oxid_zertifizierung_kolinko_zistler_web

Insgesamt sehr positives Fazit

Für den berufserfahrenen Matthias Zistler waren zwar viele der behandelten Themen bereits aus dem Arbeitsalltag bekannt, er zieht dennoch ein positives Fazit: „Um mein Wissen aufzufrischen und zu vertiefen war das Seminar genau der richtige Ansatz. Außerdem hat es Spaß gemacht, in Kontakt mit anderen OXID-Entwicklern zu kommen und sich über die ein oder andere Eigenheit des Systems austauschen zu können.“ Alexander Kolinko, der das Team von shoptimax seit Anfang Mai 2015 unterstützt, waren die drei Tage in Freiburg die erste Möglichkeit, sich intensiv mit der OXID-Community bekannt zu machen und einen tieferen Einblick in die Möglichkeiten des Shopsystems zu erhalten. Alexander und Matthias wurden am Ende der dreitägigen Schulung Zertifikate über ihre erfolgreiche Teilnahme ausgehändigt, wodurch sich damit nun beide offiziell „OXID eShop Certified Engineer (PE) & OXID eShop Certified Engineer (EE)“ nennen dürfen.

Ein unschlagbares Team – OXID eSales und shoptimax

shoptimax ist bereits seit 2004 OXID Partner und seit 2013 OXID Enterprise Level Partner. Unsere Entwickler nehmen regelmäßig an Seminaren und Schulungen der OXID eSales AG teil, um immer auf dem neuesten Stand zu bleiben und die bestmöglichen Lösungen aus dem Shopsystem für unsere Kunden erarbeiten zu können.
Einer der Hauptschwerpunkte unserer Arbeit liegt auf der Entwicklung von OXID Modulen für die unterschiedlichsten Anwendungsmöglichkeiten und der Implementierung des Shopsystems in die ERP- und PIM-Backendsysteme unserer Kunden.
Eine besonders aktuelle und beliebte Schnittstelle ist beispielsweise OXID2plentymarkets, die offiziell autorisierte Schnittstelle zwischen OXID und der E-Commerce-Warenwirtschaft plentymarkets. Ursprünglich für unseren Kunden Intersport Krumholz entwickelt, steht die Schnittstelle nun auch öffentlich zur Verfügung.

Eigene mehrsprachige Tabellenfelder im OXID eShop

Im OXID Wiki finden sich zwar generelle Informationen zum Sprachhandling im Shop, will man allerdings eigene Tabellen mit mehrsprachigen Feldern nutzen sind die Informationen rar gesät – deshalb hier ein kurzes „Howto“ zum Thema :)

Angenommen, wir haben eine Tabelle mit einem mehrsprachigen Feld „TITLE“:

CREATE TABLE IF NOT EXISTS `smxsurveys` (
`OXID` varchar(32) collate latin1_general_ci NOT NULL,
`TITLE` varchar(255) NOT NULL,
`TITLE_1` varchar(255) NOT NULL,
`SETCOOKIE` enum(‚0′,’1‘) NOT NULL default ‚0‘,

Wie in OXID seit Jahren üblich und z.B. in der „oxarticles“-Tabelle zu sehen, legt man die Felder mit dem Postfix „_SPRACHID“ an, z.B. für die Sprache mit ID 1 (in der Regel Englisch bzw. Deutsch) also „_1“ – in unserem Fall also das Feld „TITLE_1“.

In aktuellen OXID-Versionen reicht das aber nicht mehr aus – mehrsprachige Tabellen benötigen zwingend eigene Views für jede Sprache (z.B. „oxv_smxsurveys_de“). Um diese von OXID automatisch anlegen zu lassen, gibt es zwei Möglichkeiten:

  1. Eintrag in die config.inc.php Datei – hier muss das Array „aMultiLangTables“ gesetzt bzw. erweitert werden, z.B.
    $this->aMultiLangTables = array(’smxsurveys‘);
  2. dies kann man auch mit einem oxLang-Modul erreichen, welches die Methode getMultiLangTables() überschreibt:

class smxsurveys_oxlang extends smxsurveys_oxlang_parent {
public function getMultiLangTables()
{
return array_merge(array(’smxsurveys‘), parent::getMultiLangTables());
}
}

Prinzipiell könnte man so in der onActivate()-Methode eines Moduls zuerst per SQL die Datenbank-Tabellen anlegen, ein oxLang-Modul in der metadata.php definieren, welches die Views definiert und schliesslich mittels

$dbmetadatahandler = oxRegistry::get(‚oxDbMetaDataHandler‘);
$dbmetadatahandler->updateViews(array(’smxsurveys‘));

die Views neu erzeugen und so ohne Benutzer-Interaktion (und ohne Anpassungen in der config.inc.php-Datei) ein neues Modul mit eigenen Multilang-Tabellen aktivieren.
Allerdings greift das oxLang-Modul hier zu spät im Shop-Initialisierungsprozess und das Erzeugen der Views direkt beim Aktivieren des Moduls schlägt leider fehl. Man muss daher nach Aktivierung des Moduls unter „Service / Tools“ im Admin einmalig noch „VIEWS jetzt updaten“ durchführen, damit das Modul funktionsfähig ist.

Den kompletten Quellcode für ein Beispiel-Modul mit eigenen mehrsprachigen Tabellenfeldern und den hier beschriebenen Konzepten finden Sie übrigens auf Github.

ShOptiFind! 3.8 – viele Verbesserungen und neue Features!

Nachdem letzte Woche die Version 3.8.0 unseres auf Apache Solr basierenden Such- und Filter-Moduls für den OXID eShop erschienen ist, steht auch schon Version 3.8.1 in den Startlöchern.

sf_typeahead
Neu in Version 3.8.0. ist vor allem das neue Autocomplete, das auf der aktuellen Version von Twitter Typeahead und nicht mehr auf JQueryUI basiert. Neben einem verbesserten Layout kombiniert das Autocomplete nun Suchvorschläge, Kategorien, Hersteller und Artikel und führt je nach gewähltem Bereich optimierte Suchen aus.

Ausserdem wurde die Modulstruktur aufgeräumt und an die Oxid-Verzeichnisstruktur angepasst, die Einbindung in den Shop erfolgt nun komplett über Oxid Template Blocks, was eine manuelle Template-Anpassung für standard-nahe Shops komplett überflüssig macht.
Natürlich gibt es auch eine ganze Reihe von Optimierungen, Verbesserungen und Bugfixes.

sf_cloth_filters_ml

In Version 3.8.1. wird es v.a. für Shops aus den Bereichen Mode, Schuhe usw. interessant – erstmals ist es möglich, nicht nur die Reihenfolge der Filter zu beeinflussen, sondern auch die Sortierung der Filterwerte nach eigenen Vorgaben anzupassen. Gerade Mode-Shops wollen z.B. die Kleider- oder Schuhgrößen „manuell“ sortieren, also z.B. „XS – S – M – L – XL – XXL“ o.ä.
Dies kann nun mit ShOptiFind! 3.8.1. problemlos umgesetzt werden und man ist nicht mehr auf eine alphabetische Sortierung oder eine Sortierung nach Trefferhäufigkeit beschränkt:

 

Ein weiteres interessantes Feature (das prinzipiell schon länger verfügbar ist) ist die Nutzung von Cookie-Filtern. Per Javascript können Cookies gesetzt und gelöscht werden, die globale Filterungen auf das Sortiment anwenden, so kann z.B. kategorieübergreifend nach „Neuheiten“ oder „Sonderangeboten“ usw. gefiltert werden.

ShOptiFind! 3.8.1. bietet zum Stichwort „kategorieübergreifend“ aber noch mehr – es können nun über SEO-URLs nun auch unabhängig von Kategorien beliebige Filter aktiviert werden, so kann z.B. über eine URL wie „www.meinshop.de/Herstellername“ (Beispiel: module.shoptimax.de/shoptifind3/ION/) das komplette Sortiment nach Hersteller gefiltert werden. Das funktioniert mit beliebigen Attributen aus dem Shop, so kann z.B. über einen Filter „www.meinshop.de/Blau“ (Beispiel: module.shoptimax.de/shoptifind3/Schwarz/) das Sortiment nach Farbe „Blau“ oder z.B. auch mit einer URL wie „www.meinshop.de/[0 TO 50]“ nach Artikeln unter 50 EUR (Beispiel: Filter bis 25 EUR, http://module.shoptimax.de/shoptifind3/[0 TO 25]/) gefiltert werden!

Last but not least wird es mit ShOptiFind! 3.8.1. auch eine aktualisierte Version der Solr-Plugins sowie Beispiel-Konfigurationen für die brandneue Apache Solr Version 4.7.1 geben.

Mehr Infos unter www.shoptifind.de, Demoshop unter: module.shoptimax.de/shoptifind3/

shoptimax entwickelt OXID – plentymarkets – Schnittstelle

shoptimax veröffentlicht die offiziell autorisierte Schnittstelle zwischen dem E-Commerce Warenwirtschaftssystem plentymarkets und dem Online-Shop-System OXID eShop.

OXID2plentymarkets

Pünktlich zum plentymarkets Kongress 2014 steht endlich eine Schnittstelle zwischen dem auf E-Commerce spezialisierten Warenwirtschaftssystem und der renommierten Shop-Software von OXID eSales zur Verfügung.

Über OXID2plentymarkets werden Bestelldaten und –statusänderungen, Kundendaten, Artikeldaten und Kategoriedaten automatisch über eine SOAP-Schnittstelle zwischen plentymarkets und dem OXID eShop synchronisiert. In der Regel ist plentymarkets dabei das datenführende System. Mit dieser Schnittstelle kann der OXID eShop aber auch an andere ERP-Systeme angeschlossen sein und bedient dann plentymarkets als aktives Element.

 

Die Schnittstelle OXID2plentymarkets wurde auf Initiative von INTERSPORT Krumholz als flexible Schnittstelle zwischen dem Webshop OXID eShop und dem Warenwirtschaftssystem plentymarkets entwickelt. Sie ermöglicht es, ohne manuelle Eingriffe eine vollständige Integration beider Systeme herzustellen. Die Webshop-Schnittstelle OXID2plentymarkets ist sehr leicht erweiterbar. Auch eine individuell konfigurierte und erweiterte Warenwirtschaft plentymarkets oder ein stark angepasster OXID eShop können auf diese Weise miteinander verbunden werden.

Die Kosten für die Schnittstelle betragen 3.600,00 Euro für die Lizenz zzgl. Supportvertrag und Integrationskosten. Weitere Informationen (Features, Screenshots, etc.) finden Sie hier: OXID2plentymarkets.

OXID|Json – REST-Schnittstelle für OXID mit AngularJS Frontend

Seit gestern ist auf GitHub unsere REST-Schnittstelle OXID|Json frei verfügbar. Sie bietet ein CRUD-Interface (Create, Read, Update, Delete) für den OXID eShop an und enthält ein mit AngularJS erstelltes Frontend, mit dem die wichtigsten Funktionen getestet werden können.

oxidjson01

Das Frontend erlaubt die „Inline“-Bearbeitung aller Daten, die Daten können sortiert, gefiltert und modifiziert werden. Durch die Verwendung des Responsive-Frameworks „Twitter Bootstrap“ ist die Oberfläche auch mit mobilen Endgeräten nutzbar.

Die REST-Schnittstelle basiert auf Tonic und ist nach einem verschlüsselten Login mit Shop-Zugangsdaten je nach Rechten read-only oder mit Vollzugriff nutzbar.

ShOptiFind! News

ShOptiFind! Suche bekommt eigene Homepage

Unter http://www.shoptifind.de/ haben wir alle wichtigen Informationen zum Thema ShOptiFind!, unserer Apache Solr Integration in den OXID eShop, gebündelt. Hier können sich Interessenten umfangreich informieren und unseren Demo-Shop ausprobieren.

Neue ShOptiFind! Features

ShOptiFind! ist natürlich bereits kompatibel zu den aktuellsten OXID eShop Versionen CE / PE 4.7.5. bzw. EE 5.0.5.

In der aktuellsten Modul-Version ist es möglich, für beliebige numerische Felder oder Datumsfelder mit wenigen Zeilen Template-Code Slider zum Filtern der Suchergebnisse oder der Kategorie-Artikel zu verwenden. So kann neben dem Preis nun auch z.B. nach Lagerstand, Größen, Verfügbarkeit, Einstelldatum usw. bequem und intuitiv mittels Slidern gefiltert werden. Hier ein Beispiel:


shoptifind_slider

Ebenfalls im Screenshot zu sehen sind die Icons für die Farbwahl – in der aktuellsten ShOptiFind! Modul-Version 3.6.5 (verfügbar ab OXID 4.7.x / 5.0.x, ältere Versionen auf Anfrage) ist es möglich, mit kleinen Template-Änderungen für beliebige Filterwerte statt Text frei erstellbare Icons zu verwenden. Diese müssen dann einfach für jeden möglichen Filterwert in ein definiertes Verzeichnis abgelegt werden.