Kategorie: OXID

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.

share

bequemes Module entfernen für OXID eShop – ocb_cleartmp erweitert

ocb_cleartmp erweitert
Wir haben soeben das Modul aus dem OXID Kochbuch um eine weitere, etwas versteckte Option ergänzt.
Beim Entwickeln ist es immer wieder notwendig, alle Moduleinträge zu löschen. Unter anderem deswegen, weil OXID, sofern es bereits Blöcke für ein Modul kennt, keine weiteren hinzu nimmt, wenn diese über die metadata.php ergänzt werden.

Um es dieses manuelle Löschen zu beschleunigen und da das ocb_cleartmp-Modul auf jeder unserer Entwicklungsshops zum Pflichtumfang gehört, haben wir das Modul um diese Option ergänzt. Sobald man den Entwicklermodus aktiviert, erscheit die zusätzliche Auswahl im Dropdown (siehe Bild).

Edit:
Das Modul steht kostenfrei auf GitHub zur Verfügung unter https://github.com/OXIDCookbook/ocb_cleartmp

share

OXID Modulentwicklung – Hidden Feature: Reihenfolge der Block-Erweiterungen festlegen

Wenn in einem OXID-Shop mehrere Module aktiv sind, ist es gut möglich, dass zwei oder mehr Module den gleichen Template-Block überschreiben. Dabei kann es zu ungewollten Verschiebungen in der Reihenfolge der darzustellenden Elemente kommen. Praktischerweise wird in der Datenbanktabelle „oxtplblocks“ als „oxpos“ bereits eine Priorität für die Reihenfolge mitgespeichert. Diese ist jedoch für jeden Block standardmäßig auf „1“ gesetzt. Leider bietet das OXIDwiki derzeit keine Hinweise darauf, wie dieser Wert korrekt festzulegen ist.

Natürlich ließe sich der Wert direkt in der Datenbank anpassen. Eine viel angenehmere Möglichkeit bietet OXID jedoch, indem in der „metadata.php“ des jeweiligen Moduls einfach beim Block eine „position“ mit angegeben wird. Hier ein einfaches Beispiel:

In der Metadata von Modul 1:


'blocks' => array(
    array(
        'template' => 'page/checkout/basket.tpl',
        'block'    => 'basket_btn_next_bottom',
        'file'     => '/views/blocks/MODUEL_EINS_basket_next.tpl',
        'position' => '2'
    ),
),

In der Metadata von Modul 2:


'blocks' => array(
    array(
        'template' => 'page/checkout/basket.tpl',
        'block'    => 'basket_btn_next_bottom',
        'file'     => '/views/blocks/MODUL_ZWEI_basket_next.tpl',
        'position' => '3'
    ),
),

Nun wird auch definitiv erst der Block von Modul 1 und anschließend der Block von Modul 2 eingebunden.

share

OXID Modul „Categoryorder“: Artikel einfach und schnell sortieren per Drag & Drop

Kennen Sie das? Sie haben in Ihrem Shop-Backend in mühevoller Kleinarbeit bestimmte Artikel einer Kategorie zugeordnet und in die richtige Reihenfolge gebracht. Nach einiger Zeit kommt ein neuer Artikel hinzu, der nun an Position XY rücken soll. Bis zuletzt hieß es dann: Alle Artikel wieder löschen, Reihenfolge neu festlegen. Das neue OXID Modul „Categoryorder“ löst nun genau dieses Problem.

Mit diesem Modul können Sie problemlos und schnell die neue Artikelreihenfolge einer Kategorie festlegen. Nach der Installation des Moduls in Ihrem OXID eShop, finden Sie im Backend unter Artikel verwalten > Kategorien > Sortierung einen neuen Button „Drag&Drop Artikelsortierung“. Hier öffnet sich ein Popup-Fenster mit einer Liste aller Artikel, die dieser Kategorie zugeordnet sind. Nun kann man die Artikel ganz einfach mit Drag&Drop neu sortieren. Das Sortieren wurde mit den Funktionen „sortable“ und „sortstop“ von jQuery UI realisiert.

 

Category_order

Nachdem Sie einen Artikel neu positioniert haben, ruft die Funktion „sortstop“ ein AJAX request auf, der die neue Sortierung in der Datenbank speichert. Das heißt, das Speichern der neuen Reihenfolge erfolgt automatisch im Hintergrund, sodass der Benutzer davon nichts mitbekommt. Nach dem Sortieren kann man das Popup-Fenster einfach schließen und das Ergebnis im Frontend des Shops begutachten.

Das Modul steht bei GitHub kostenfrei zur Verfügung – auch auf oxmod.org haben wir es in den OXID Modulkatalog aufgenommen.