Kategorie: Module

share

OXSEARCH 3.6.0 released

Mit dem neuen Release gibt es auch eine erweiterte Dokumentation des Moduls. Diese wurde mit GitBook realisiert und steht damit tagesaktuell online zur Verfügung:

screenshotGitbookDokuOxsearch

Das ist neu im Modul:

  • Bugfixes für Promotionen
  • der Request Timeout ist konfigurierbar
  • Performanceverbesserungen
  • Vereinfachungen für das Überladen der JavaScript- und CSS-Includes
  • Codestyle PSR-2 kompatibel
  • weitere Bugfixes

Ein Dank geht an die Kollegen von DotFly, die uns neben wichtigem Feedback sogar einen Bugfix bereit gestellt haben.

share

OXSEARCH 3.4 – Suchen um zu finden


Das Modul „OXSEARCH“ verbindet ihren OXID eShop mit der Suchtechnologie Elasticsearch. Wir arbeiten stetig daran, das Modul weiter zu entwickeln. Letzte Woche haben wir die neue Version veröffentlich, die Ihre Suche noch performanter und fehlertoleranter macht:

Um die Suche in Ihrem eShop noch umfassender zu gestalten, nutzen Sie mit OXSEARCH 3.4  die verbessterte Teilbegriffsuche und die Wildcardsuche zum Auffinden verwandter Begriffe. So finden Ihre Kunden Artikel noch leichter und komfortabler.
›› weiterlesen…

share

Billsafe Zahlungsinformation auf dem OXID eShop Rechnungs-PDF angeben bei Einsatz des PayOne-Moduls

PayOne bietet mittels des fcPayOne-Moduls (von der Berliner OXID Agentur Fatchip) auch die Zahlart Billsafe an. Leider kann das Modul noch nicht die Daten für die Rechnung, die in der OXID Community & Professional Edition bequem im Backend als PDF generiert werden können ausgeben.

Im Wiki von Fatchip finden sich lediglich die Angaben, welche Felder auszulesen sind.

Hier ein Snippet, mit dem die Daten auszulesen und im PDF dargestellt werden.

Grundsätzlich empfiehlt es sich, die oxOrder zu erweitern, in der die PDF-Generierung eingehängt ist. Leider müssen wir die zwei Methoden, die wir verändern wollen aus der Originaldatei kopieren.

Zuerst blenden wir in unserem Modul in der Methode „exportStandart()“ die normalen Rechnungseinstellungen aus:


public function pdfFooter( $oPdf )
{
...
if( $this->oxorder__oxpaymenttype->value != "fcpobillsafe")
{
// hier die Bankangaben
}

Am Ende der Methode „exportStandart()“ fügen wir nun die Billsafe Daten ein:
if( $this->oxorder__oxpaymenttype->value == "fcpobillsafe")
{
$oLang = oxRegistry::getLang();
$sBrutPrice = $oLang->formatCurrency( $this->oxorder__oxtotalbrutsum->value, $this->getCurrency() ).' '.$this->getCurrency()->name;
$oPdf->MultiCell( 170, 10, $this->_getFatchipPayoneBillsafeData( 'clearing_legalnote'), 0, 'J' , 0, 1, 14, $siteH+10 );
$oPdf->SetTextColor(50, 150, 50);
$oPdf->MultiCell( 170, 10, $this->_getFatchipPayoneBillsafeData( 'clearing_instructionnote'), 0, 'J' , 0, 1, 14, $siteH+24 );
$oPdf->SetTextColor();
$oPdf->text( 15, $siteH+38, "Empfänger:" );
$oPdf->text( 55, $siteH+38, $this->_getFatchipPayoneBillsafeData( 'clearing_bankaccountholder' ) );
$oPdf->text( 15, $siteH+43, "Bank:" );
$oPdf->text( 55, $siteH+43, $this->_getFatchipPayoneBillsafeData( 'clearing_bankname' ) );
$oPdf->text( 15, $siteH+48, "IBAN:" );
$oPdf->text( 55, $siteH+48, $this->_getFatchipPayoneBillsafeData( 'clearing_bankiban' ) );
$oPdf->text( 15, $siteH+53, "BIC:" );
$oPdf->text( 55, $siteH+53, $this->_getFatchipPayoneBillsafeData( 'clearing_bankbic' ) );
$oPdf->text( 15, $siteH+58, "Betrag:" );
$oPdf->text( 55, $siteH+58, $sBrutPrice );
$oPdf->text( 15, $siteH+63, "Verwendungszweck:" );
$oPdf->text( 55, $siteH+63, $this->_getFatchipPayoneBillsafeData( 'clearing_reference' ) );
}

Bitte – wie oben bereits erwähnt – nicht die Core-Datei ändern, sondern oxOrder sauber mit einem Modul überladen. Wer nicht weiß wie das geht: Roman Zenner und ich haben ein Buch dazu geschrieben. 😉

share

Technischer Überblick und Einschätzung der veröffentlichten OXID eShop 4.9/5.2 beta

Das Team der OXID eSales AG hat diese Woche die beta Version des nächsten Minor-Releases veröffentlicht. Alle Informationen zur neuen Version finden sich im OXID Wiki.

Auf den ersten Blick hat sich nicht viel getan, was neue Features betrifft. Dies lege ich jedoch eher als Vorteil denn als Ärgernis aus: OXID arbeitet konsequent weiter an der Verbesserung der bestehenden Funktionen und dem Stabilisieren des Cores. Wie sich in den Projekten zeigt, sind alle Komponenten die bei unseren Kunden deckungsgleich, bereits heute im System enthalten. Zusatzfunktionen werden dann im Projekt umgesetzt.

Neues Handling für die Enterprise Edition Mandanten

Diese Erweiterung hatte Roland Fesenmayr bereits während der OXID Commons angekündigt – es werden quasi unlimitierte Mandanten (bis zu 1.500) unterstützt. Da unser Elasticsearch Modul „OXSEARCH“ bereits in einem Projekt mit einer solchen Anzahl an Mandanten zum Einsatz kommt, konnten wir die Partnerschaft mit OXID nutzen und das Modul bereits für den Einsatz in diesem Umfeld optimieren (die Option ist im Standard-Umfang unseres Moduls enthalten und kann von allen Kunden genutzt werden, eine entsprechende unlimited Lizenz ist dafür geschaffen worden).

Contribution

Was uns als Agentur mit einem starken Hang zur Open Source Welt besonders freut, ist, dass eine neue Contribution in den Core aufgenommen wurde: Tobias Merkl von Proudsourcing hat die Konfiguration des Versanddienstleisters bei der Angabe des Trackingcodes umgesetzt. Bisher war dieser fest auf DPD gesetzt und musste im Projekt mit einem Modul geändert werden.

Weitere Änderungen

Weggefallen ist die Funktion des dgr-Parameters, mit dem durch Klicken eines Links Benutzer einer Gruppe zugewiesen werden konnten. Durch die einfache Manipulierbarkeit war dies zuletzt negativ aufgefallen und durch einen Hotfix bereits geändert. Wer eine solche Anforderung hat, sollte vor dem Update mit seiner Agentur eine sichere Lösung dafür konzipieren.

Der Seitentitel wurde bisher im Template zusammen gesetzt. Dies, und das zusätzliche Fehlen eines entsprechenden Template-Blocks, machten es unmöglich hier einfach Änderungen vorzunehmen. Erfreulicherweise ist OXID den Weg gegangen, den wir bereits in unserem SEO-Modul umgesetzt haben: Der komplette Titel wird in der Methode oxBase::getTitle() umgesetzt. Diese lässt sich einfach überschreiben. Änderungen im Template werden überflüssig.

Mein Fazit:

OXID hat die Zeichen der Zeit weiter im Fokus: Keine großen neuen Features sondern konsequentes Stabilisieren der Architektur. Ich hoffe, dass sich diese Richtung weiter verfolgt und der Kern immer schlanker wird. Des weiteren sind wir natürlich alle gespannt, ob es denn dieses Jahr noch etwas vom neuen Admin Interface zu sehen geben wird.

share

TOXID: So können Sie Duplicate Content bei der Integration vermeiden

Sie haben erfolgreich TOXID installiert und in Ihren OXID Online-Shop integriert, dann besteht häufig noch das Problem, dass beispielsweise Ihr WordPress Blog einmal unter der URL oxid-online-shop.de/blog und unter seinem Installationspfad erreichbar ist. In der Praxis hat sich gezeigt, dass eine doppelte Indexierung im Google-Index sehr häufig vorkommt.

Nun gibt es unterschiedliche Wege um diesem Indexierungs-Problem vorzubeugen. Ich möchte hier nur einen Weg skizzieren, sicherlich gibt es auch die Möglichkeit dies mit meiner entsprechend konfigurierten robots.txt zu erreichen, aber im Folgenden stelle ich kurz den Weg über eine .htaccess-Datei vor.

Was wollen wir erreichen?
Ziel ist es das CMS nicht mehr von außen unter seinem Installationspfad erreichbar zu machen, aber man möchte natürlich noch seine redaktionelle Inhalte dort pflegen können, zu diesem Zweck benutzen wir eine .htaccess-Datei. Dort richten wir dem Redakteur einen User mit Passwort ein. Crawler oder ähnlichem bleibt aber der Zugang verborgen.
Das CMS, insbesondere schlecht gewartete und mit viele Plugins versehene WordPress-Installationen, sind anfällig für nicht freundlich gesinnte Angriffe von außen. Der Schutz des Verzeichnisses bringt hier einen zusätzlichen Sicherheits-Vorteil.

Umsetzung
Vorraussetzung: TOXID ist installiert und lauffähig, FTP- oder SSH-Zugriff auf den Webserver, Text-Editor
Im Root des CM-System liegt eine .htaccess-Datei, diese öffnet man und fügt den folgenden Code (mit seinen individuellen Ergänzungen für „/path/to/“ und „XXX.XXX.XXX.XXX“) am Anfang hinzu:

AuthType Basic
AuthName „Passwortgeschuetzter Bereich!“
AuthUserFile /path/to/.htpasswd
Require valid-user
Order deny,allow
Deny from all
Allow from XXX.XXX.XXX.XXX
Satisfy any

Nun legt man ebenfalls im Root die Datei .htpasswd an, falls noch nicht vorhanden und fügt seinen Code aus bspw. diesem .htpasswd Generator ein.
Wer den absoluten Pfad zur .htpasswd-Datei nicht kennt, kann sich eine kleine PHP-Datei erstellen, eine Anleitung ist hier zu finden.

In der Zeile „Allow from XXX.XXX.XXX.XXX“ trägt man die IP-Adresse des Shop-Servers ein. Es spielt dabei keine Rolle ob CMS und Online-Shop auf demselben Webserver liegen oder auf unterschiedlichen. Wer die IP-Adresse seines Servers nicht kennt, kann in der Administrationsoberfläche seines Servers (unter DNS-Verwaltung oder ähnlichem) fündig werden.

Hat man die entsprechenden Ersetzungen in der .htaccess-Datei gemacht und auch eine .htpasswd-Datei generiert, ist man auch schon fast fertig.

Zugriff auf Bilder freigeben
Im Ordner WORDPRESS/wp-content/uploads muss man nun noch eine .htaccess-Datei mit folgendem Inhalt anlegen, um den Zugriff auf Bilder, etc. von ausserhalb zu gestatten.

Order Deny,Allow
Allow From All
Satisfy Any

Hinweis
Es empfiehlt sich sehr, das Ganze nicht im Live-System zu testen, da auch nur kleine Syntax-Probleme den kompletten Seitenaufbau verhindern können und das hier geschilderte Vorgehen nur mit WordPress getestet wurde.